In meinen Projekten merke ich immer wieder, wie stark die Erwartungen an Voicebots gestiegen sind. Viele Unternehmen gehen mit dem Anspruch hinein, innerhalb weniger Wochen einen vollwertigen KI-gestützten Service aufzubauen. Die Realität sieht anders aus. Voicebots leisten heute viel, aber sie brauchen eine saubere Grundlage, klare Ziele und Kunden die Bereitschaft, am Anfang etwas mehr Energie zu investieren.
In meinem Webinar im Rahmen der 16. Customer Service Woche habe ich zwei Projekte vorgestellt, die gut zeigen, was möglich ist und welche Stolpersteine man kennen sollte. Beide Use Cases kommen aus dem Behördenumfeld, beide hatten dasselbe Ziel: das Service Center entlasten und Standardanfragen automatisieren. Trotzdem verliefen die Projekte sehr unterschiedlich.
Ein Voicebot als erste Anlaufstelle: Was gut funktioniert und was nicht
Im ersten Projekt war die Herausforderung ein sehr hohes Anrufvolumen. Die Mitarbeitenden wurden durchgehend unterbrochen, obwohl sie gleichzeitig Bürger vor Ort betreuten. Ziel war es, eine Entlastung von mindestens 50 % zu erreichen.
Deshalb hat die Behörde entschieden, die komplette öffentliche Rufnummer auf einen Voicebot umzuleiten. Nur wenn der Bot nicht weiterkommt, kann der Bürger einen Rückruf hinterlassen. Diese Rückrufwünsche gehen als E-Mail mit einer Zusammenfassung und einem detaillierten Transkript auf die Mailbox der Mitarbeitenden der Behörde. Die Mitarbeitenden können sich in der freien Zeit darum kümmern.
Der Ansatz klang zunächst einfach. Man wollte die bestehenden FAQ-Texte der Website übernehmen und daraus einen Bot bauen. Wir sind deshalb zunächst mit einem klassischen NLU-Bot (Natural Language Understanding, NLU) gestartet. Der Kunde wollte keine Halluzinationen riskieren und eine klar vorgegebene Customer Journey.
Genau an dieser Stelle haben wir aber gemerkt, wie anspruchsvoll das Thema tatsächlich ist. Webseiten-Inhalte sind nicht für Voicebots geschrieben. Sie sind oft historisch gewachsen, inhaltlich überlappend oder unpräzise. Der Bot braucht dagegen eindeutige Informationen, klar formuliert und sauber getrennt. Die Dialoge wirkten steif und hätten die Anrufenden letztendlich nicht zufriedengestellt.
Der Wechsel auf ein LLM-Bot-Modell (Large Language Modell, LLM) war dann der entscheidende Durchbruch. Die Begeisterung war groß: menschliche Dialoge, Empathie, verschiedene Formulierungen. Der Bot sagte "Oh, das ist ja wunderbar" oder "Das tut mir sehr leid". Der Bot konnte die gleiche Frage auf unterschiedliche Weise beantworten und reagierte menschlicher, ohne die definierten Leitplanken zu verlassen.
Messbare Ergebnisse
Das Ergebnis war klar messbar: Nur noch rund 20 % der ursprünglichen Anrufe landeten als Rückrufwunsch bei den Mitarbeitenden. Die meisten Fälle wurden vom Bot sauber geklärt. Ein sehr schöner Nebeneffekt: die Wiederanrufer sind ebenfalls weggefallen, da der Bot kein “Besetzt” kennt. Die Mitarbeitenden haben viel mehr Zeit für die Bürger vor Ort. Das war genau die Entlastung, die der Kunde sich erhofft hatte.
Bei 15 % der Anrufer legt der Bot auf - meistens nach erfolgreichen Gesprächen. 30-40 % der Bürger legen selbst auf. Hier mussten wir in die Transkripte schauen, um zu bewerten, ob das gut oder schlecht ist.
Unser Learning aus diesem Projekt
Personelle Ressourcen
Schnelle Erfolge sind möglich, aber ohne aktive Mitarbeit auf Kundenseite funktioniert kein Voicebot-Projekt. Die Pflege der Wissensbasis, die Erstellung eines Glossars, das Testing, das saubere Aussprache-Lexikon für Text-to-Speech und die Überarbeitung der Inhalte gehören dazu. Neben einer fachlichen Ressource sollte es eine technische Unterstützung geben, die sich um die APIs kümmert und Kenntnisse in Scripting in JavaScript oder XML hat. Letztendlich müssen noch Ressourcen für das Testing bereitstehen. Für diese Projektgröße braucht es mindestens zwei dedizierte Ansprechpartner auf Kundenseite, besser drei.
LLM-Wissen
Ein weiteres Thema ist das sogenannte Grundwissen des LLMs. Ein Modell bringt immer allgemeine Kenntnisse mit. Es muss aktiv begrenzt werden, damit es nur innerhalb der bereitgestellten Inhalte bleibt. Das gelingt gut, aber nicht zu hundert Prozent. Man muss also testen, korrigieren und im Zweifel nachjustieren.
Natürlichkeit
Wenn der Bürger etwas fragt, "denkt" der Bot - Speech to Text, Text im LLM, Text to Speech. Diese Pausen müssen gefüllt werden. Tippen, "ähm", in unterschiedlicher Lautstärke. Varianz der Hintergrundgeräusche ist wichtig.
Barge-in
Was mittlerweile die meisten Bot-Anbieter auch können, ist das sogenannte Barge-in, also das Unterbrechen des Dialoges. Der Bot muss akzeptieren, dass er unterbrochen wird. Zum Beispiel, wenn der Anrufende die gewünschten Informationen erhalten hat und keine weiteren im Redefluss des Bots benötigt. Nachteilig kann sich auswirken, dass der Bot Umgebungsgeräusche als Unterbrechung werten kann, z. B. wenn der Anrufe auf einem Bahnsteig steht. Aber hier kann man die Empfindlichkeit in dem System einstellen.
Ein zweites Beispiel: Wenn Anrufweiterleitung Teil des Prozesses ist
Im zweiten Projekt ging es ebenfalls um FAQs, aber die Anforderungen waren anders. Der Bot sollte zwar Anfragen beantworten und das Service Center entlasten – Ziel waren ebenfalls 50 %. Aber während der Öffnungszeiten sollten Anfragen trotzdem an Mitarbeitende im Backend oder Contact Center weitergeleitet werden können. Es gab keine Möglichkeit eines Rückrufwunsches. Außerdem musste das bestehende Avaya-System bzgl. der Weiterleitungen vom Bot an den Mitarbeitenden eingebunden werden.
Technische Integration
Die technische Integration war ein wichtiger Punkt. Der Anruf kommt ins Call Center, wird zum Voicebot deflected, und soll bei Bedarf zurück zu einem Mitarbeitenden. Der Routing-Identifier muss mitgegeben und zurückgespiegelt werden - über User-to-User-Information oder SIP-Header-Manipulation. Das Gespräch ist dann auch in dem Call Center im historischen Reporting entsprechend enthalten.
Wir integrierten auch den Call Data Service von Parloa. Die Gesprächszusammenfassung erscheint im Avaya Frontend, bevor der Mitarbeitende das Gespräch annimmt. Damit können die Agenten vorab sehen, worum es im Gespräch geht.
Ergebnisse
Auch hier hatten wir am Anfang das gleiche Muster: Der Kunde wollte die Website-FAQs importieren. Und auch hier hat es nicht funktioniert. Die Inhalte mussten manuell überarbeitet werden.
Es wurden 50 % Weiterleitung erreicht - ein Teilerfolg. Besser wäre keine Weiterleitung, aber die anderen 50 % wurden erfolgreich automatisiert.
Es gab 10 % Aufleger durch den Bot - nach Transkript-Durchsicht ein Erfolg. 40 % Aufleger durch den Kunden - hier muss man genauer hinschauen. Ist es ein Erfolg oder nicht? Da muss man noch einmal in die Transkripte prüfen und sich die Gespräche anschauen. Eine Möglichkeit ist es, abschließend zum Gespräch im Bot eine Zufriedenheitsumfrage durchzuführen.
Learnings aus dem zweiten Projekt
Zeitaufwand
Wir hatten 3 Monate Projektlaufzeit. Das passte gut. Für Design, Konfiguration und technische Tests auf unserer Seite sind ca. 20 Personentage angefallen.
Personelle Ressourcen
Hier hatten wir zu wenig Kundenressourcen. Das führte zu Mehraufwand bei uns, der nicht eingeplant war.
Opt-in
Ein wichtiger Punkt für beide Bots. Der Bürger muss der Aufzeichnung zustimmen. Der Bot zeichnet immer alles auf - das Transkript ist komplett vorhanden. Egal, ob es jetzt nach 7 Tagen oder 30 Tagen wieder gelöscht wird.
Das Opt-in muss abgefragt werden. Der Bürger soll eben auch die Möglichkeit haben zu sagen, „Nein, ich möchte jetzt hier nicht weitermachen.“ Oder er macht weiter - und wie wir im ersten Fall gesehen haben - wünscht einen Rückruf und gibt nur wenig Information von sich.
Hier kann es Sinn machen mit dem NLU, also mit dem strukturierten Ansatz, zu starten, und dann weitergehend erst mit dem LLM-Agentic-Ansatz, damit das Opt-in wirklich kommt und abgewartet wird. Bei einem vollständigen LLM-Start kann man an dieser Funktionalität vorbeischrammen.
Was wir aus beiden Projekten mitnehmen
Voicebots sind heute leistungsfähig. Aber sie sind kein Plug-and-Play-Produkt. Wer erfolgreich sein will, muss drei Dinge ernst nehmen.
Erstens: Inhalte. Ein Bot ist nur so gut wie die Wissensbasis, die man ihm gibt. Webseiten-Texte kann man fast nie übernehmen. Sie müssen überarbeitet und strukturiert werden.
Zweitens: Ressourcen. Ohne fachliche Ansprechpartner beim Kunden, die testen, korrigieren und Inhalte pflegen, wird das Projekt schnell zäh.
Drittens: Erwartungsmanagement. Der Weg führt fast immer durch eine Phase, in der die Qualität noch nicht stimmt. Wenn man dranbleibt, wird es schnell besser. Am Ende hatten beide Projekte hohe Erfolgsquoten und zufriedene Anrufende.
Fazit
Voicebots sind eine echte Entlastung, wenn man sie richtig aufsetzt. Die Technik ist ausgereift, aber sie verlangt eine sorgfältige Einführung. Wenn Inhalte, Tests und die interne Zusammenarbeit stimmen, erreicht man schnell ein Niveau, bei dem ein Großteil der Anfragen automatisiert wird und die Teams mehr Zeit für die Fälle haben, die wirklich menschliche Betreuung brauchen.
