Ein 90-Tage-Plan für die Einführung von Voice-KI im Unternehmen

Was der 90-Tage-Plan liefern soll

In einem Unternehmen mit 50 bis 100 Beschäftigten sollte das erste Voice-KI-Release ein einziges betriebliches Ergebnis belegen, nicht jede Warteschlange abdecken. Wählen Sie einen Workflow mit genug Volumen zum Lernen, klaren Richtlinien und einem sinnvollen Rückweg zum Menschen: Terminänderungen, Bestellstatus, Qualifizierung oder ein anderes klar begrenztes Anliegen. An Tag 90 stehen ein Workflow im Produktivbetrieb, eine Baseline, ein freigegebener Umfang, getestete Integrationen, eine messbare Übergabe und eine verantwortliche Person.

Benennen Sie zu Beginn vier Verantwortliche: einen Sponsor aus der Geschäftsleitung für Prioritäten und Risiken, die Betriebsleitung für den Workflow, eine zuständige Person für die Systeme, also Telefonie und CRM-Zugriff, und eine Prüfinstanz aus Qualitätssicherung oder Compliance für Abnahme und Nachvollziehbarkeit. Für das Ergebnis im Tagesgeschäft bleibt die Betriebsleitung verantwortlich. Eine Projektleitung kann die Arbeit koordinieren. Sie sollte aber nicht zur Ersatzverantwortlichen werden, sobald der Agent eine Ausnahme erzeugt.

Nutzen Sie die folgenden Meilensteine als Arbeitsvereinbarung. Die Zeiträume dienen der Planung. Sie sind kein Grund, eine unfertige Stufe freizugeben. Ist ein Quellsystem, eine Richtlinienentscheidung oder der Weg zum Menschen noch nicht bereit, halten Sie die nächste Phase an und dokumentieren die Abhängigkeit.

Zuerst die Grenzen festlegen

Schreiben Sie auf, was der Agent beantworten, lesen und ändern darf und was er nie entscheidet. Dazu gehören Geschäftszeiten, Sprachen, Identitätsprüfung, Wiederholungsregeln, Einwilligung zur Aufzeichnung, sensible Themen und der Punkt, an dem ein Mensch übernimmt. Eine Grenze nützt nur, wenn das Team sie in einem echten Gespräch erkennt. Ergänzen Sie Beispiele für erlaubte und unzulässige Anliegen, die maßgebliche Quelle für jede Antwort und den genauen Zustand, der belegt, dass eine Aktion abgeschlossen ist.

Ein Nachweispaket aufbauen

Führen Sie für den Workflow ein einziges versioniertes Paket: Beschreibung des Umfangs, Diagramm des Gesprächsablaufs, Quellen der Richtlinien, Datenfelder, Übersicht der Verantwortlichen, Kennzahlenkatalog, Testfälle, Freigaben, Störungsprotokoll und Release-Historie. Verknüpfen Sie jede wichtige Anforderung mit einem Test oder einem Prüfnachweis. Das ist belastbarer als eine Demo-Aufnahme. Und eine Entscheidung an Tag 90 bleibt auch für neue Leute im Betrieb, in der Prüfung oder in der IT nachvollziehbar.

Tage 1 bis 15: Gespräche erfassen

Beginnen Sie mit Anrufaufzeichnungen, Transkripten, Abschlusscodes, Gründen für Wiederholungskontakte, Notizen der Teamleitung, freigegebenem Wissen und den CRM-Feldern, mit denen Ihr Team arbeitet. Ziehen Sie Stichproben aus Routineanrufen und Ausnahmen, verteilt über die gewählte Warteschlange, Zeitfenster, Sprachen und Anrufertypen. Achten Sie auf die Worte der Anrufer, nicht nur auf die Kategorien im Reporting. Ein Anliegen kann als mehrere Fragen ankommen, und hinter einer Formulierung kann ein Anliegen stecken, für das jemand anderes zuständig ist.

Bilden Sie den Weg von der Begrüßung bis zum Ergebnis ab. Markieren Sie Identitätsprüfung, Abfragen, Aktionen mit verbindlicher Zusage und Übergaben. Notieren Sie für jeden Zweig das erwartete Ergebnis, den Beleg dafür und die Person oder Warteschlange, die den nächsten Schritt verantwortet. Erfassen Sie als Baseline Lösungsquote, Übergabequote, Wartezeit, Wiederholungskontakte, erledigte Aktionen und die bestehende Qualitätsprüfung. Ohne Baseline und ohne Nenner ist eine spätere Verbesserung nur ein gutes Gefühl.

Aus Beobachtungen eine brauchbare Stichprobe machen

Legen Sie eine kleine Anrufbibliothek mit typischen, schwierigen und unklaren Beispielen an. Kennzeichnen Sie das tatsächliche Anliegen des Anrufers, die geltende Richtlinie, den richtigen Abschlusscode, den erwarteten Systemzustand und ob ein Mensch übernehmen sollte. Entfernen oder schützen Sie sensible Daten nach den freigegebenen Regeln Ihres Teams. Es geht nicht um einen perfekten Datensatz. Es geht darum, die wiederkehrenden Entscheidungen des Workflows so sichtbar zu machen, dass sie sich testen lassen.

Verantwortlich: Betriebsleitung, mit Teamleitung und Qualitätsprüfung. Ergebnis: Übersicht der Anliegen, Gesprächsablauf, Datenbestand, Baseline, Anrufbibliothek und Liste der Themen außerhalb des Umfangs. Abschlussprüfung: Das Team kann den Workflow in einem Satz erklären, für jede Antwort die maßgebliche Quelle nennen und für jede Ausnahme die zuständige Person benennen.

Tage 16 bis 30: aus Richtlinien einen Workflow machen

Übersetzen Sie die Übersicht in eine Workflow-Vereinbarung: Begrüßung, Identifizierung des Anrufers, Bestätigung des Anliegens, Wissensabfrage, Aktion, Bestätigung, Zusammenfassung und nächster Schritt. Bauen Sie auf echten Formulierungen und Unterbrechungen auf, nicht auf einem perfekten Skript. Planen Sie Stille, Akzente, Korrekturen, Momente wie „Das habe ich doch schon erklärt“, geänderte Anliegen, mehrere Anliegen in einem Anruf und Anrufer ein, die sofort einen Menschen verlangen.

Legen Sie für jede Tool-Aktion Eingabe, Berechtigung, Erfolgsantwort, Timeout und Fehlerweg fest. Halten Sie fest, ob die Aktion nur liest, sich rückgängig machen lässt oder eine Zusage ist, die eine Bestätigung braucht. Halten Sie die erste Integrationsrunde klein: eine Telefonie-Route, ein Datensatz im CRM oder Helpdesk und das nötige Minimum an freigegebenem Wissen. DRING unterstützt integrierte Voice-Workflows, die aus einem Gespräch ein strukturiertes Ergebnis machen. Welches Ergebnis maßgeblich ist, entscheidet aber Ihr Unternehmen.

Integrationen erst nach Prüfung freigeben

Bevor der Agent ein Tool nutzen darf, prüfen Sie vier Dinge: Die maßgebliche Datenquelle ist benannt, die Berechtigung ist auf das Minimum für den Workflow beschränkt, die Antwort lässt sich validieren, und ein Fehler ist für einen Menschen sichtbar. Bestätigen Sie Feldzuordnungen, Pflichtkennungen, Verhalten bei Dubletten, Timeout-Grenzen, Audit-Ereignisse und die Zuständigkeit für den Abgleich. Beginnen Sie, wo immer möglich, mit Lesezugriff. Schreibzugriff kommt erst dazu, wenn ein Test belegt, dass ein Wiederholungsversuch keine zweite Buchung, kein zweites Ticket und keine zweite Zusage erzeugen kann.

Die Übergabe als vollwertigen Weg planen

Legen Sie fest, was eine Live-Übergabe auslöst: Unsicherheit trotz Nachfrage, ein sensibles Anliegen, eine gescheiterte Systemaktion, ein Anrufer, der einen Menschen verlangt, oder eine Entscheidung außerhalb der Richtlinie. Der Agent erklärt den nächsten Schritt, gibt eine knappe Zusammenfassung und die Kennungen an den Menschen weiter und sichert den Vorgang, wenn die Warteschlange nicht erreichbar ist. Vereinbaren Sie den Ausweichweg: Rückrufaufgabe, Ticket, SMS-Bestätigung oder dokumentierter Abschluss.

Beschreiben Sie den Inhalt der Übergabe als verbindliche Vereinbarung. Er trennt Angaben des Anrufers von Systemergebnissen und enthält Stand der Identitätsprüfung, Anliegen, versuchte Aktionen, relevante Datensatz-Kennungen, Dringlichkeit, Sprache, Stand von Einwilligung oder Widerspruch, Grund der Eskalation und die nächste zuständige Person. Legen Sie fest, was als erfolgreiche Übergabe gilt, wie lange ein Anrufer warten darf und was passiert, wenn niemand die Übergabe annimmt. Eine Übergabe, die den Kontext verliert oder eine Aufgabe ohne Zuständigkeit erzeugt, ist kein abgeschlossener Workflow.

Tage 31 bis 45: den Live-Weg anbinden

Richten Sie Rufnummer, SIP-Trunk oder Route über die virtuelle Telefonanlage, Rufnummernanzeige, Geschäftszeiten, Mailbox, Warteschlangenregeln und einen Ausweichweg für den Notfall ein. Testen Sie den kompletten Telefonie-Weg vom Eingang bis zur Übergabe, auch falsche Weiterleitung, besetzte Warteschlangen, abgebrochene Anrufe, nicht passende Rufnummernanzeige, das Verhalten außerhalb der Geschäftszeiten und einen Menschen, der nicht erreichbar ist. Auch ein ausgefeiltes Gespräch scheitert, wenn die Weiterleitung falsch ist oder bei der Übergabe der Kontext verloren geht.

Binden Sie CRM oder Helpdesk an. Beginnen Sie mit Lesezugriff. Schreibzugriff kommt erst dazu, wenn Feld, Berechtigung, Validierung und Audit-Eintrag geklärt sind. Entscheiden Sie, wie Anrufer zugeordnet werden, wie Dubletten behandelt werden und wie Wiederholungsversuche vermeiden, dass zwei Tickets oder Buchungen entstehen. Protokollieren Sie Ergebnis, nächsten Schritt, Fehlergrund, Status der Quelle und zuständige Person dort, wo Ihr Betriebsteam ohnehin arbeitet. Testen Sie einen erfolgreichen Schreibvorgang und einen Teilausfall, etwa eine erledigte Aktion ohne Zusammenfassung.

Die Menschen rund um die Leitung vorbereiten

Change Management beginnt vor dem ersten Pilotanruf. Sagen Sie Mitarbeitern und Teamleitungen, welche Arbeit sich verlagert, welche Entscheidungen beim Menschen bleiben, wie sich ein falscher Datensatz korrigieren lässt und wo sie einen Fehler melden können, ohne eine Schuldzuweisung fürchten zu müssen. Geben Sie dem übernehmenden Team Beispiele für Übergabe-Zusammenfassungen und eine kleine Übungswarteschlange. Bitten Sie erfahrene Mitarbeiter um Formulierungen und Grenzfälle, und zeigen Sie, wie aus ihrem Feedback ein Test oder eine dokumentierte Richtlinienentscheidung wird. So gehört die Akzeptanz im Team zur Startbereitschaft und ist keine Ankündigung nach dem Start.

Verantwortlich: IT, mit Validierung durch Betrieb, Teamleitung und Qualitätsprüfung. Ergebnis: angebundene Route, Berechtigungen, Zuordnung der Ereignisse, Probe der Übergabe, Briefing fürs Team und Wiederherstellungsverfahren. Abschlussprüfung: Ein Testanruf erzeugt das erwartete Telefonie-Ereignis, den erwarteten CRM-Stand, die Zusammenfassung und den Übergabe-Eintrag ohne manuelle Nacharbeit, und eine namentlich benannte Person kann die Route pausieren.

Tage 46 bis 60: Verhalten und Ergebnisse testen

Stellen Sie einen Testsatz aus typischen, schwierigen und gezielt herausfordernden Gesprächen zusammen. Trennen Sie dabei Routineanrufe, Grenzfälle, Tool-Fehler, Übergaben und Anliegen, bei denen Richtlinien berührt sind. Decken Sie falsche Nummern, fehlende Datensätze, schlechte Tonqualität, Stille, Unterbrechungen, widersprüchliches Wissen, verärgerte Anrufer, nicht vertrauenswürdigen Text in abgerufenen Daten, API-Timeouts, doppelte Anfragen, Unterschiede in Sprache oder Akzent, geänderte Anliegen und jeden Übergabe-Auslöser ab. Testen Sie, was der Agent sagt, und den Systemzustand, der danach entsteht.

Halten Sie für jeden Testfall fest: erwartetes Anliegen, erlaubte Antwort, nötiger Hinweis oder nötige Bestätigung, erwarteter Tool-Aufruf, erwarteter Stand des Datensatzes, Entscheidung zur Übergabe und Schweregrad bei einem Fehler. Nutzen Sie für jedes Release einen kleinen Regressionssatz und für Meilenstein-Entscheidungen einen breiteren Evaluierungssatz. Auch ein natürlich klingender Anruf kann den falschen Status schreiben oder die Eskalation verzögern. Der Qualitäts- und Evaluierungsprozess von DRING arbeitet mit simulierten Gesprächen, Regressionstests, menschlicher Prüfung und stufenweisem Rollout. Legen Sie die Bestehenskriterien vorher fest, und behalten Sie fehlgeschlagene Szenarien im Regressionssatz.

Gespräch und Ergebnis bewerten

Bewerten Sie Verständnis des Anliegens, Richtlinientreue, Erledigung der Aufgabe, Datengenauigkeit, Erhalt des Kontexts, Latenz und Treffsicherheit der Übergabe. Prüfer sollten einen Testfall als bestanden, nicht bestanden oder prüfbedürftig markieren können, jeweils mit Begründung. Trennen Sie kritische Fehler von Schönheitsfehlern. Eine unbefugte Offenlegung, eine falsche Aktualisierung im Datensatz, eine falsche Bestätigung oder eine verpasste Übergabe aus Sicherheitsgründen darf nicht im Durchschnitt vieler flüssiger Routineanrufe verschwinden. Speichern Sie zu jeder Evaluierung die Release-Version und das Testergebnis.

Das Verhalten bei Fehlern vereinbaren

Wählen Sie für jede Fehlerart genau eine Reaktion: nachfragen, eine begrenzte Aktion wiederholen, sicher ablehnen, eine Folgeaufgabe anlegen oder übergeben. Der Agent rät nicht bei Richtlinien, erfindet keinen Datensatz und behauptet nicht, eine Aktion sei gelungen, wenn sie es nicht ist. Die Qualitätsprüfung zeichnet diese Grenzen ab. Die IT bestätigt, dass die Logs Fehler sichtbar machen. Führen Sie nach jeder Änderung an Prompts, Wissen, Berechtigungen, Weiterleitung, Telefonie oder Datenzuordnung den kompletten Regressionssatz erneut aus. Schon eine geänderte Formulierung kann eine Tool- oder Übergabe-Entscheidung verändern.

Verantwortlich: Qualitätssicherung. Ergebnis: versionierter Testsatz, Bewertungsbogen, Fehlersystematik, Regressionsergebnisse und unterschriebene Entscheidung zur Startbereitschaft. Prüfpunkt an Tag 60: kein offener kritischer Fehler im Pfad innerhalb des Umfangs, für jede Tool-Aktion ein beobachtetes Erfolgs- und Fehlerergebnis, und das übernehmende Team hat Übergabe und Rollback-Weg geprobt.

Tage 61 bis 75: eine eng begrenzte Pilotphase starten

Geben Sie dem Workflow einen kleinen Teil des Anrufvolumens: eine Warteschlange, eine Region oder ein Zeitfenster. Halten Sie den bestehenden Weg verfügbar, und machen Sie den Weg zum Menschen leicht erreichbar. Briefen Sie das übernehmende Team zu Format der Zusammenfassung, Ablauf der Übernahme, Fehlerkennzeichnung und dazu, wer die Anrufe auf diesem Weg pausieren darf. Die Teamleitungen prüfen täglich Anrufe und gruppieren Probleme nach Ursache, statt den Agenten nach einer holprigen Formulierung umzuschreiben. Geben Sie dem Team eine einzige Warteschlange für Ausnahmen, damit ein gescheiterter Schreibvorgang, ein verpasster Rückruf und eine Richtlinienfrage nicht in getrennten Postfächern verschwinden.

Verfolgen Sie Lösungsquote, angemessene Übergaben, Wiederholungskontakte, Wartezeit, abgebrochene Anrufe, Erfolg der Systemaktionen, Richtlinienausnahmen, Latenz und Kundenfeedback. Trennen Sie betriebliche Ergebnisse von Vorlieben für eine Stimme. Prüfen Sie Stichproben automatisch abgeschlossener Anrufe ebenso wie Übergaben, denn hinter einem automatisch abgeschlossenen Anruf kann ein ungelöstes Anliegen stecken. Gleichen Sie Stichproben mit dem CRM-Stand ab, und fragen Sie das übernehmende Team, ob es mit der Übergabe arbeiten konnte. Pausieren Sie die Pilotphase, sobald eine kritische Grenze bei Richtlinie, Datenschutz, Weiterleitung oder Datenintegrität verletzt ist.

Kriterien für Stopp, Ausweitung und Rollback festlegen

Stopp: Pausieren Sie den betroffenen Pfad bei unbefugter Offenlegung, Aktualisierung des falschen Datensatzes, fälschlich gemeldetem Abschluss, verpasster kritischer Übergabe, fehlender Pflicht-Einwilligung, wiederholtem doppeltem Schreibvorgang oder einer Ausnahme mit hoher Priorität ohne Zuständigkeit. Halten Sie den bisherigen Weg bereit, und dokumentieren Sie Störung, betroffene Anrufe, Release-Version, zuständige Person und die sofortige Eindämmung.

Ausweitung: Erhöhen Sie das Volumen erst, wenn die Betriebsleitung den Vergleich mit der Baseline, die Qualitätsstichprobe, die Systemergebnisse, die Übergabe-Warteschlange und offene Störungen geprüft hat. Die Belege sollten zeigen, dass der Workflow innerhalb der vorab vereinbarten Leitplanken läuft und dass das Team die Ausnahmen personell auffangen kann. Entscheiden Sie über eine Ausweitung nie nur anhand eines Durchschnitts. Schauen Sie sich die Teilbereiche an, in denen sich Arbeit oder Risiko verändern.

Rollback: Kehren Sie zum bisherigen Weg oder Release zurück, wenn sich die Ursache nicht schnell eingrenzen lässt, eine Leitplanke verletzt ist oder das übernehmende Team mit der Ausnahme-Warteschlange nicht mehr mitkommt. Testen Sie vor Beginn der Pilotphase, dass der alte Weg noch funktioniert. Ein Rollback ist erst abgeschlossen, wenn neue Anrufe den bisherigen Weg nehmen, offene Aufgaben eine zuständige Person haben und das Störungsprotokoll die Prüfung der Wiederherstellung und die Folgeentscheidung nennt.

Tage 76 bis 90: mit Belegen ausweiten

Vergleichen Sie die Ergebnisse der Pilotphase mit der Baseline, und schauen Sie sich die Anrufe hinter den Durchschnittswerten an. Suchen Sie nach Abweichungen je Anliegen, Uhrzeit, Sprache, Anrufertyp und Integrationspfad. Ihre Anrufanalyse sollte Transkript, Bewertung, strukturiertes Ergebnis und CRM-Stand verbinden, damit das Team ein Problem bis zum Gespräch oder zum Workflow zurückverfolgen kann. Führen Sie ein Entscheidungsprotokoll: Was hat sich geändert, warum, welcher Beleg stützt die Änderung, und was ist noch unbekannt?

Weiten Sie stufenweise aus, zum Beispiel auf 10 %, 50 % und dann 100 %, mit einer Prüfpause nach jedem Schritt. Nutzen Sie in jeder Stufe denselben Bewertungsbogen, damit sich der Nenner nicht unbemerkt ändert. Legen Sie vor der Erhöhung fest, wer einen Rollback anordnen darf und was ihn auslöst. Jede relevante Korrektur sollte einen Testfall, eine dokumentierte Änderung und ein Regressionsergebnis hervorbringen. Braucht die nächste Warteschlange andere Berechtigungen, Richtlinien, Sprachen oder Eskalationszeiten, behandeln Sie das als neue Entscheidung über den Umfang, statt den ersten Workflow blind zu kopieren.

Legen Sie an Tag 90 einen praktikablen Betriebsrhythmus fest. Während einer aktiven Pilotphase prüfen die Teamleitungen täglich Stichproben und Ausnahmen. Betrieb, Qualitätssicherung und IT sichten wöchentlich die Trends. Liegt eine validierte Änderung vor, bereitet das Team alle zwei Wochen einen Release-Kandidaten in der Agent Factory vor, in der DRING Agenten baut, testet und verbessert. Die Verantwortlichen für Richtlinien, Zugriff, Aufbewahrung und Umfang prüfen den Service monatlich. Dringende Korrekturen für Sicherheit oder Datenintegrität dürfen einen beschleunigten Freigabeweg nehmen. Sie brauchen trotzdem einen Test, eine namentlich benannte Person für die Freigabe, eine Release-Version, ein Beobachtungsfenster und eine Nachprüfung. Der fortlaufende Verbesserungskreislauf der Agent Factory macht aus Belegen im Produktivbetrieb priorisierte Arbeit und ein kontrolliertes Release statt einer unerklärten Prompt-Änderung.

Übertragen Sie diese Disziplin erst dann auf den zweiten Workflow, wenn der erste eine feste Zuständigkeit, einen gepflegten Regressionssatz, einen bekannten Rollback-Weg und genug Kapazität für Prüfungen hat. Das Ziel ist nicht, einen Agenten für immer festzuschreiben. Das Ziel ist eine wiederholbare Methode, mit der Ihr Team Agenten startet und verbessert.

Den Bewertungsbogen vor dem Rollout festlegen

Nutzen Sie einen Kennzahlenkatalog, der Zähler, Nenner, Zeitraum, Quellsystem, Ausschlüsse und zuständige Person benennt. Halten Sie Ergebnis-, Service-, Qualitäts- und Leitplanken-Kennzahlen getrennt. Eine einzige „Automatisierungsquote“ kann einen falschen Schreibvorgang verbergen oder einen Anrufer, der aufgegeben hat. Eine Übergabe dagegen kann bei einem Anliegen außerhalb der Richtlinie genau das richtige Ergebnis sein.

Ergänzen Sie Latenz, Anrufabbrüche, Quote veralteter Antworten, Quote doppelter Aufgaben, Bestätigung von Eskalationen und Kundenfeedback, wo sie eine Entscheidung stützen. Schlüsseln Sie Ergebnisse nach Anliegen, Uhrzeit, Sprache, Anrufertyp, Route und Integrationsergebnis auf. Schauen Sie auf Anzahl und Prozentwert, wenn sich das Volumen ändert. Ein stabiler Prozentwert bei wachsender Ausnahme-Warteschlange kann trotzdem eine Entscheidung über Kapazität oder Weiterleitung erfordern.

Fragen, die vor dem Rollout geklärt sein müssen

Fragen Sie vor der Freigabe für den Produktivbetrieb: Welches Ergebnis messen wir, und welche Quelle belegt es? Welche Anrufe liegen außerhalb des Umfangs? Welche CRM-Felder dürfen gelesen oder beschrieben werden, und wer verantwortet die Datenqualität? Was erfordert eine Identitätsprüfung oder einen Menschen? Was passiert, wenn API, Telefonie-Route, Wissensquelle oder Übergabe ausfallen? Wo werden Aufzeichnungen, Transkripte und Zusammenfassungen aufbewahrt, und wer hat Zugriff? Wer darf die Automatisierung pausieren, ein Release freigeben und eine Störung kommunizieren? Welche Belege braucht es, bevor mehr Anrufe oder eine neue Aktion dazukommen? In welcher Routine prüft das Team die Ausnahmen, und welche Arbeit fällt für dieses Team weg oder kommt hinzu?

Das Ziel ist ein wiederholbarer Weg: einen begrenzten Workflow live bringen, aus den Ergebnissen lernen, den Weg zum Menschen schützen und das nächste Release steuern. An Tag 90 sollte das Team nicht nur wissen, ob der Agent ein Gespräch zu Ende führen kann. Es sollte auch wissen, wer die Ausnahmen verantwortet, welche Belege eine Ausweitung stützen und wie sich die Änderung stoppen oder rückgängig machen lässt, wenn sich die Betriebsbedingungen ändern.