Ein KI-Aufnahmesystem bauen, das sich nicht wie ein Chatbot anfühlt

Die meisten Projekte für „AI-Aufnahme und Fallmanagement“ beginnen mit demselben Impuls: einen Chatbot auf die Aufnahmeseite zu setzen, damit Menschen mit ihm sprechen statt ein Formular auszufüllen. Dieser Impuls ist meist falsch oder zumindest unvollständig. Ein Chat-Widget, das man an einen bestehenden Aufnahmeprozess andockt, beseitigt die Reibung im Prozess nicht — es legt nur eine freundlicher wirkende Schicht über dieselbe Reibung und schafft einen neuen Fehlerfall: eine Unterhaltung, die ins Leere läuft, weil das System dahinter mit dem, was die Person gerade gesagt hat, eigentlich nichts anfangen kann.

Ein Aufnahmesystem, das funktioniert, wird nicht daran gemessen, ob es ein Chatfenster hat. Entscheidend ist, was mit den Informationen geschieht, nachdem jemand sie abgeschickt hat — ob sie strukturiert, weitergeleitet und in einen offenen Fall überführt werden, bei dem die richtige Person hinschaut, ohne dass jemand die Hälfte davon von Hand neu eintippen muss. Dafür ist Chat-UI nur am Rand relevant; entscheidend ist die Pipeline dahinter.

Was bei einer typischen chatbotartigen Aufnahme schiefläuft

Das Fehlerbild ist in Kanzleien, medizinischen Empfangsbereichen, Recruiting-Teams und Immobilienbüros erstaunlich ähnlich — überall dort, wo Aufnahme bedeutet, Informationen von einer Person zu erfassen, die kein System ist, unter Zeitdruck und oft zum ersten Mal. Wiederholt gehen ein paar Dinge schief:

• Starre Entscheidungsbäume, die sich als Gespräch ausgeben. Der Bot stellt eine feste Abfolge von Fragen, egal was die Person bereits gesagt hat. Jemand schildert seine Situation in der ersten Nachricht, und drei Fragen später fragt der Bot dasselbe noch einmal, weil der Ablauf nicht dafür gebaut wurde, Freitext zu verstehen, sondern nur ein Skript abzuarbeiten.
• Kein Gedächtnis über die Sitzung hinweg. Die Person muss sich wiederholen, wenn sie geht und später zurückkommt oder wenn das Gespräch an einen Menschen übergeben wird. Nichts aus dem vorherigen Austausch wandert in den Falldatensatz über.
• Kein echter Eskalationspfad. Der Bot beantwortet alles nur mit allgemeiner Beruhigung oder endet in einer Sackgasse mit „bitte rufen Sie uns an“ — und dann muss die Person verbal bei einem Menschen neu anfangen, der keinen Einblick in das bereits Gesagte hat.
• Nicht mit dem führenden System verbunden. Das Chat-Protokoll liegt in einem eigenen Dashboard des Widgets. Jemand aus dem Team muss es trotzdem lesen und den Fall, die Mandantenakte oder den CRM-Datensatz manuell anlegen. Die „Automatisierung“ hat dem Kunden einen Anruf erspart und dem Team dieselbe Datenerfassung eingebrockt wie immer.

Das hat eigentlich nichts damit zu tun, dass das AI-Modell ungeeignet wäre. Es ist ein Architekturproblem: Das Gespräch wurde als Produkt behandelt, dabei ist das eigentliche Produkt der strukturierte Falldatensatz am anderen Ende.

Was „sich nicht wie ein Chatbot anfühlt“ wirklich bedeutet

Die Aufnahmesysteme, die im produktiven Einsatz bestehen, teilen meist ein paar Designentscheidungen, die nichts damit zu tun haben, den Bot menschlicher klingen zu lassen, und alles damit, den zugrunde liegenden Prozess robuster zu machen.

Eingaben kanalunabhängig erfassen

Menschen wählen nicht durchgängig denselben Kanal. Dieselbe Aufnahme muss ein Webformular, eine E-Mail, ein hochgeladenes Dokument und manchmal ein Telefonprotokoll verarbeiten können — und überall dieselben strukturierten Felder extrahieren, unabhängig davon, woher sie kommen. Wenn die Extraktionsschicht einmal gebaut und von einem einzelnen Kanal entkoppelt wird, vermeidet das drei getrennte Parsing-Pfade, die sich sonst gegenseitig aus dem Takt bringen.

Strukturierte Extraktion statt Skriptgespräch

Statt jemanden durch ein starres Frage-Antwort-Schema zu führen, liest eine sauber gebaute Aufnahme das aus, was tatsächlich eingereicht wurde — eine Freitextbeschreibung, ein Dokument, ein Formular mit einigen leeren Feldern — und extrahiert mit ausreichender Sicherheit, was sie kann, markiert Fehlendes oder Unklares und fragt nur gezielt die Lücken nach. Das ist eine kleinere, präzisere Nachfrage, als das ganze Gespräch neu zu starten, und es respektiert, dass die Person den Großteil der Antwort beim ersten Mal bereits geliefert hat.

Kontext über die gesamte Interaktion hinweg erhalten

Alles, was zuvor gesagt oder eingereicht wurde, bleibt mit dem Fall verknüpft — egal, ob der nächste Schritt eine weitere automatisierte Nachfrage ist oder ein Mensch übernimmt. Wer den Fall öffnet, sollte den vollständigen Kontext sofort sehen und nicht ein Protokoll, das er selbst lesen und manuell zusammenfassen muss.

Eine schnelle, klar definierte Übergabe an einen Menschen

Nicht jede Aufnahme sollte vollständig automatisiert sein, und so zu tun, als wäre das anders, lässt viele dieser Systeme Vertrauen verlieren. Das bessere Muster setzt klare Schwellenwerte: bestimmte Fallarten, bestimmte Konfidenzlevel oder bestimmte Warnsignale in den eingereichten Informationen gehen direkt an eine Person, inklusive bereits vorbereiteter strukturierter Zusammenfassung. Die Aufgabe der Automatisierung ist es, den Fall schneller und besser vorbereitet an die richtige Person zu bringen — nicht, menschliche Beteiligung komplett zu vermeiden.

Die Architektur, die tatsächlich ausgeliefert wird

In der Produktion sieht ein Aufnahmesystem, das diesen Anspruch erfüllt, meist weniger wie ein Chatbot aus und mehr wie eine Pipeline mit einer Gesprächsoberfläche als einem von mehreren Einstiegspunkten:

1. Erfassung über mehrere Kanäle. Webformular, E-Mail-Posteingang, Dokumenten-Upload und — wo relevant — eine Chat- oder Sprachoberfläche speisen alle in dieselbe Aufnahmeschicht ein.
2. Extraktion und Klassifizierung. Ein AI-Schritt liest die eingereichten Inhalte — strukturiert oder unstrukturiert — und extrahiert die Felder, die das Fallmanagementsystem benötigt: Falltyp, relevante Daten, beteiligte Parteien, Dringlichkeitssignale, fehlende Unterlagen.
3. Routing auf Basis von Sicherheit. Fälle mit hoher Sicherheit und klarer Einordnung laufen automatisch weiter — ein Fall wird angelegt, eine Bestätigung wird versendet und er landet in der richtigen Warteschlange. Fälle mit geringer Sicherheit oder ungewöhnliche Fälle werden markiert, damit ein Mensch sie prüft, bevor irgendetwas weitergeht.
4. Fallanlage, nicht nur ein Protokoll. Das Ergebnis ist ein strukturierter Datensatz in dem System, mit dem das Team tatsächlich arbeitet — der Fallmanagement-Plattform, dem CRM, dem Praxisverwaltungstool — und nicht ein Chatprotokoll, das jemand später per Hand übertragen muss.
5. Eine Prüfkette. Was eingereicht wurde, was extrahiert wurde, welcher Sicherheitsgrad zugewiesen wurde und was als Nächstes passiert ist, wird alles protokolliert. Das ist wichtig für die Qualitätskontrolle und, in regulierten Bereichen, für die Compliance.

Das ist das Muster, auf das wir uns in unserer AI-Intake- und Fallmanagement-Arbeit fokussieren: Das dialog- oder formularbasierte Frontend ist nur der Erfassungsmechanismus. Das eigentliche System ist die Pipeline, die eine Einreichung in einen korrekt klassifizierten, korrekt weitergeleiteten Fall verwandelt — ohne dass in der Übersetzung etwas verloren geht.

Wo die Dokumentenverarbeitung einzuordnen ist

Intake endet selten beim Text. In den meisten realen Intake-Prozessen gehören Dokumente vom ersten Kontakt an dazu: Ausweise, frühere Unterlagen, Verträge, medizinische oder versicherungsbezogene Dokumente, Fotos von einer Immobilie oder einem Vorfall. Ein System, das nur getippte Antworten verarbeitet und „Bitte laden Sie Ihre Dokumente hoch“ als separaten, losgelösten Schritt behandelt, löst nur die halbe Aufgabe.

Das nützlichere Muster extrahiert zum Zeitpunkt des Intakes strukturierte Daten aus diesen Dokumenten — derselbe Extraktionsschritt, der eine freie Beschreibung liest, liest auch ein hochgeladenes PDF oder Bild, zieht die relevanten Felder heraus und hängt sie an denselben Fall datensatz an. Das ist ein deutlich anderer Ablauf, als jemanden erst ein Formular ausfüllen zu lassen und dann separat einen Scan des Ausweises per E-Mail anzufordern, nur damit das Team beides später manuell zusammenführen muss.

Typische Fehlerbilder, auf die man achten sollte

Ein paar Fehler tauchen oft genug auf, dass man sie direkt benennen sollte. Ein Ablauf, der davon ausgeht, dass jede Einreichung sauber und eindeutig ist, ist einer davon — echter Intake ist chaotisch, und das System braucht einen klar definierten Pfad für „bei diesem Fall bin ich mir nicht sicher“, statt einfach zu raten und trotzdem weiterzumachen. Die Chat-Oberfläche als das ganze Projekt zu behandeln und die Fallmanagement-Integration nur als Nebensache zu sehen, ist ein weiterer — so enden Teams mit einem schicken Frontend und derselben manuellen Backoffice-Arbeit wie zuvor. Und die Prüfkette wegzulassen ist ein Fehler, der erst auffällt, wenn jemand Monate später erklären muss, warum ein bestimmter Fall genau so weitergeleitet wurde.

Was man messen sollte

Statt ein Intake-System danach zu bewerten, wie natürlich sich das Gespräch anfühlt, sind die sinnvolleren Kennzahlen operativ: wie lange es von der ersten Einreichung bis zu einem offenen, korrekt zugewiesenen Fall dauert; welcher Anteil der Fälle automatisch mit hoher Sicherheit klassifiziert wird versus zur menschlichen Prüfung weitergeleitet wird; und wie oft ein menschlicher Prüfer die automatisierte Klassifizierung korrigiert oder überstimmt. Diese Zahlen zeigen Ihnen, ob das System tatsächlich Arbeit reduziert, und sie zeigen Ihnen, wo Sie die Extraktions- und Routing-Logik im Zeitverlauf nachschärfen sollten.

Intake richtig aufsetzen

Das Ziel eines AI-Intake-Systems war nie, Small Talk überzeugend zu führen — es geht darum, genaue und vollständige Falldaten schneller in die richtigen Hände zu bringen, als es ein Formular und ein Posteingang allein schaffen. Das heißt, die dialogbasierte Ebene als einen von mehreren Eingangskanälen zu behandeln, den eigentlichen Engineering-Aufwand in Extraktion, Klassifizierung und Routing zu investieren und klar festzulegen, wo die Automatisierung an einen Menschen übergeben soll.

Wenn Sie prüfen, was ein Neuaufbau Ihres Intakes für Ihr Team konkret bedeuten würde, ist der ASTACKRA Project Planner ein schneller Weg, Ihren aktuellen Prozess zu beschreiben und eine fundierte Empfehlung zu erhalten, oder Sie können sich direkt melden, um zu besprechen, wo Ihr Intake-Prozess heute Zeit verliert.