Voice Agents, die bestehen: Erfahrungen aus der praxisnahen Entwicklung

In den meisten Unternehmen werden punktuelle Lösungen im Support-Bereich seit Langem an der Reduzierung von Anrufen gemessen. Das bedeutet, das Anrufvolumen zu senken und direkte Kontakte mit Mitarbeitenden zu minimieren. Doch weniger Kontakte bedeuten nicht automatisch gelöste Anliegen – genau in dieser Lücke leidet das Kundenerlebnis. Um diese Lücke zu schließen, brauchen Support-Teams nicht nur Zugriff auf Daten, sondern auch auf die Systeme, um direkt zu handeln. So können Mitarbeitende Rückerstattungen bearbeiten, Kundinnen und Kunden durch den Kaufprozess führen und bei Bedarf mit vollständigem Kontext an einen Menschen übergeben. Unternehmen können so Kundenanfragen effizienter bearbeiten, die Belastung für Support-Teams senken und gleichzeitig das Erlebnis für beide Seiten verbessern.aktuellen Implementierung bei Revolut, einem Fintech-Unternehmen mit 70 Millionen Kunden weltweit, führte dies zu einer achtfach schnelleren Problemlösung und einer Erfolgsquote von 99,7 % bei Anrufen.

Veränderungen in dieser Größenordnung müssen schrittweise erfolgen, eng an die Unternehmensmission gebunden und durch starke Führung unterstützt. Auf technischer Ebene birgt das Arbeiten in unstrukturierten Umgebungen Risiken, die sorgfältig gesteuert werden müssen. Wenn ein Agent im CRM agieren, Bestellungen im Kassensystem ändern oder Fälle eskalieren kann, ist das Governance-Modell genauso wichtig wie das Modell selbst. Die Frage ist dann nicht mehr, ob Agents echte Aufgaben übernehmen können, sondern welche Mechanismen nötig sind, um sie sicher und wiederholt einzusetzen.

In diesem Beitrag teilen wir unsere Erfahrungen dazu, was Agents erfolgreich macht – vom ersten Einsatz bis zur Skalierung im gesamten Kundenservice eines Unternehmens.

Agents ausliefern vs. Software ausliefern

Bevor wir tiefer in den Aufbau von Agents einsteigen, lohnt sich ein Vergleich zwischen der Einführung von Voice Agents und klassischer Software, wie sie Unternehmen seit Jahrzehnten betreiben. Aus dieser Perspektive lassen sich Agents in zwei Komponenten gliedern: klassische Software und den zentralen Orchestrator.

Software:

Software: Beobachtbarkeit und Steuerung

Core Orchestrator

Kern-Orchestrator-Komponenten sind naturgemäß schwerer vorherzusagen, bestimmen aber maßgeblich die Laufzeitleistung des Agents – sowohl hinsichtlich Antwortqualität als auch wahrgenommener Latenz. Anders als klassische Software arbeiten diese Komponenten mit natürlicher Sprache und Audio, wobei der Eingaberaum praktisch unbegrenzt ist und kleine Änderungen in Formulierung, Kontext, Hintergrundgeräuschen oder Nutzerverhalten zu deutlich unterschiedlichen Ergebnissen führen können. Konventionelle Tests reichen hier nicht aus: Ein Agent kann hunderte Testfälle bestehen und dennoch in der Produktion auf unvorhersehbare Weise scheitern.Versionierung, A/B-Tests, Telefonie und First-Message-Konfiguration. Diese Komponenten verhalten sich nach der Einführung weitgehend stabil und sind dadurch sehr vorhersehbar. Mit soliden Engineering-Praktiken können Unternehmen diese Features schnell ausbauen und ihre Performance anhand von Metriken, Traces und Logs genau überwachen. Latenzverbesserungen in dieser Schicht folgen bekannten Mustern: Caching, Connection Pooling, Infrastruktur-Skalierung und Protokolloptimierung sind bewährte Hebel mit klaren Ergebnissen.

Auch die Latenz in dieser Schicht ist weniger vorhersehbar, da sie von Modell-Inferenzzeiten, auditiven Artefakten, Tool-Call-Ketten und der inhärenten Variabilität generativer Systeme beeinflusst wird. Das Management dieser Komponenten erfordert eine andere Herangehensweise – mit Evaluationsframeworks, Produktionsmonitoring und der Bereitschaft, kontinuierlich anhand echter Gesprächsdaten zu iterieren, statt sich nur auf Annahmen vor dem Rollout zu verlassen.

Dieser Unterschied prägt die Herangehensweise bei der Einführung: Starten Sie mit organisatorisch relevanten, aber risikoarmen Anwendungsfällen und skalieren Sie gezielt, sobald das Vertrauen in das System wächst.

Release-Zyklus

Pfadfinder auswählen

Für Teams, die mit Voice Agents starten, ist die Auswahl der richtigen Pfadfinder eine der wichtigsten frühen Entscheidungen. Dabei geht es weniger um Technologie, als viele erwarten. Teams, die früh Erfolge erzielen und nicht in endlosen POCs steckenbleiben, haben meist eines gemeinsam: Sie können die folgenden Fragen klar beantworten.

Für Teams, die Voice Agents einführen, ist die Auswahl der richtigen Pfadfinder eine der wichtigsten frühen Entscheidungen – und sie hängt weniger von der Technik ab, als viele erwarten. Teams, die früh Erfolge erzielen und nicht in endlosen POCs stecken bleiben, haben meist eines gemeinsam: Sie können folgende Fragen klar beantworten.

• Wie schafft dieser Anwendungsfall messbaren geschäftlichen Mehrwert? Der richtige Startpunkt ist nicht der technisch spannendste Use Case, sondern der, der einen spürbaren Effekt auf ein bereits relevantes Geschäftsziel hat. Das wird an Umsatz, Kosten oder Kundenzufriedenheit gemessen – also an Metriken, für die Führungskräfte ohnehin verantwortlich sind. Ohne diese direkte Verbindung wird es schwer, die nötigen Iterationszyklen zu rechtfertigen, und das Projekt verliert an Schwung, bevor die Technologie sich beweisen kann.
• Ist für Nutzer sofort klar, was der Agent kann und wofür er da ist?Unklare Zuständigkeiten sind eine der häufigsten Ursachen für Abweichungen zwischen Entwicklung und Betrieb. Nutzer, die nicht wissen, was ein Agent leisten kann, testen seine Grenzen auf unvorhergesehene Weise. Ein gut abgegrenzter Agent setzt von Anfang an klare Erwartungen und geht mit Anfragen außerhalb seines Bereichs souverän um.
• Wie sehen gute und schlechte Interaktionen aus – und lassen sie sich in konkrete Bewertungskriterien fassen?Eine gute Interaktion ist nicht nur die, bei der der Agent die Aufgabe erledigt, sondern auch die, bei der sich der Nutzer verstanden fühlt, Eskalationen zum richtigen Zeitpunkt erfolgen und das Ergebnis zum Geschäftsziel passt. Bewertungskriterien lassen sich in zwei Gruppen einteilen: Quantitative Metriken wie Task Completion Rate und Eskalationsrate, die die Plattform erfasst, und transkriptbasierte Kriterien, die eine Analyse des Gesprächs selbst erfordern. Werden diese Kriterien früh definiert, hat das Team ein klares Ziel und eine natürliche Go-Live-Schwelle. Besteht der Agent die Kriterien und sind die Plattformmetriken stabil, kann der Rollout erfolgen. Ohne definierte Kriterien bleibt der Go-Live eine Bauchentscheidung.
• Wie ist das Verhältnis zwischen Performance und Kontrolle – und was ist in dieser Phase wichtiger?Je mehr Autonomie ein Agent erhält, desto natürlicher und flexibler werden die Interaktionen – aber auch das Risiko, außerhalb validierter Grenzen zu agieren, steigt. Mehr Kontrolle durch gezieltes Prompting und strengere Eskalationslogik senkt dieses Risiko, kann den Agent aber starr wirken lassen. Keines der Extreme ist optimal. Wer zu früh zu stark einschränkt, landet bei einer besseren IVR. Wer zu schnell zu viel freigibt, schafft Supportaufwände, die den Nutzen übersteigen. Wo der Regler in jeder Reifephase stehen sollte, beeinflusst Modellkonfiguration, Eskalationslogik und wie viel Wissen im Prompt oder in externen Quellen steckt.

Grundlagen für den initialen Build

Beim Übergang zur Umsetzung können Teams auf Methoden zurückgreifen, die fast so alt sind wie Software selbst. Test Driven Development (TDD) bietet das Gerüst, um Agents während des gesamten Builds an den Kernmetriken auszurichten.

In der Umsetzungsphase können Teams auf Methoden zurückgreifen, die fast so alt sind wie Software selbst. Test Driven Development (TDD) liefert das Gerüst, um Agents während des Builds an den Kernmetriken auszurichten.

Mit einem ersten Testsatz beginnt die Agent-Entwicklung beim Systemprompt. Hier werden Regeln, Tonalität und Vorgehen des Agents festgelegt: Was soll er tun, was nicht, und wie verhält er sich an den Rändern seiner Rolle? Ein gut gestalteter Systemprompt ist ebenso strukturiert wie inhaltlich klar. Klare Abschnitte, zusammengehörige Anweisungen und der Verzicht auf bedingte Formulierungen machen einen spürbaren Unterschied in der Konsistenz des Agentenverhaltens. In dieser Phase greifen wir oft auf den Prompting-Guide zurück.Agent-Tests, die wiederholt spezifische Verhaltensweisen prüfen, die der Agent zeigen soll. Die Erfolgskriterien werden am besten durch die Analyse echter menschlicher Anrufe abgeleitet. Die Tests werden schrittweise aufgebaut: Zunächst mit erwarteten Verhaltensweisen, dann erweitert um neue und um Edge Cases.

Parallel zum Systemprompt werden die Kernkomponenten des Agents konfiguriert: das LLM, das Text-to-Speech (TTS)-Modell und die Stimme. Die Auswahl des LLM ist meist ein Trade-off zwischen Latenz und Performance – schnellere Modelle verzichten oft auf etwas Reasoning, und umgekehrt. Beim TTS hängt die Wahl davon ab, was der Use Case am meisten verlangt: ausdrucksstarke Wiedergabe, geringe Latenz oder Mehrsprachigkeit. Die Stimme ist jedoch ebenso eine Markenentscheidung wie eine technische. Sie prägt, wie ein Unternehmen bei jedem Anruf wahrgenommen wird, und ist damit eine der wenigen Konfigurationsentscheidungen, die genauso zu Brand- und Marketingteams gehören wie zu den Entwicklern. Die Stimmauswahl kann daher parallel zum Rest des Entwicklungsprozesses erfolgen und wird nicht zum Engpass. ElevenAgents bietet Zugang zu über 10.000 Stimmen, und falls keine passt, können Teams eigene Stimmen klonen oder erstellen.

Darüber hinaus lassen sich Agents optional mit einer Wissensdatenbank,

Mit diesen Grundlagen ist der Agent bereit für den Praxistest.Wissensdatenbank,Toolsund Kanal-Konfigurationen erweitert werden. Jede Erweiterung bringt neue Fähigkeiten, aber auch neue Testflächen. Ob Telefonie-Integration, Zugriff auf externe Datenbanken oder Handlungen im Namen des Kunden – diese Entscheidungen sollten vor der Ausweitung gegen die Erfolgskriterien geprüft werden. Werden Tools hinzugefügt, geben Systemprompt und Toolbeschreibung klare Anweisungen, wann und wie sie genutzt werden, damit der Agent sie konsistent und im richtigen Kontext einsetzt.

Auf dem Weg zur Produktionsreife

Mit den in der Grundlagenphase definierten Tests und Bewertungskriterien, die nun gegen einen gebauten Agent laufen, entsteht ein enger Entwicklungszyklus: Weitere Tests hinzufügen, Fehler identifizieren, Systemprompt oder Konfiguration anpassen und erneut testen. Die meisten Fehler in dieser Phase sind keine Modellfehler, sondern Promptfehler. Eine Anweisung, die isoliert klar schien, ist im Gesprächsverlauf doch mehrdeutig. Edge Cases treten auf, die im ersten Testsatz nicht abgedeckt waren. Jeder davon wird zu einem neuen Next-Turn-Test, der direkt aus dem Gespräch erstellt werden kann. Die Frage, wann man aufhört zu iterieren, hat eine klare Antwort: Wenn der Agent die Bewertungskriterien konsistent über mehrere Durchläufe erfüllt und Plattformmetriken wie Task Completion Rate und Eskalationsrate sich im akzeptablen Bereich stabilisiert haben. Deshalb ist die Definition dieser Kriterien vor dem Build so wichtig. Ohne sie bleibt die Produktionsreife eine Ermessensfrage.

In der Praxis stellen die meisten Teams fest, dass eine kleine Zahl wiederkehrender Fehlerquellen für die Mehrheit der Probleme verantwortlich ist. Am häufigsten sind Prompt-Mehrdeutigkeiten, bei denen der Agent widersprüchliche oder unklare Anweisungen erhält und sich unvorhersehbar verhält; Tool-Fehlbedienung, bei der Tools im falschen Kontext genutzt oder nicht genutzt werden; und Eskalations-Drift, bei der der Agent zu früh eskaliert oder Gespräche zu lange hält. Jede dieser Ursachen lässt sich auf Prompt-Ebene beheben – durch Präzisierung der Anweisung, ein explizites Beispiel oder Anpassung des Eskalationsschwellwerts. Das Risiko besteht darin, sie vor dem Go-Live nicht zu erkennen.

Der häufigste Fehler ist, eine bestandene Testsuite als Garantie zu sehen statt als Signal. Eine Suite, die nur den Happy Path abdeckt, wird leicht bestanden und sagt wenig aus. Abdeckung von Ablehnungen, Gesprächswechseln, mehrdeutigen Eingaben und Tool-lastigen Interaktionen verleiht den Ergebnissen Gewicht. Ebenso übersehen Teams, die auf Simulationstests verzichten und nur Turn-Level-Tests nutzen, Fehler, die erst im vollständigen Gespräch auftreten – etwa Kontextverlust oder Fehler, die sich im Verlauf aufschaukeln. Sobald wiederkehrende Fehlerquellen behoben sind und der Agent auch seltene Edge Cases souverän, wenn auch nicht perfekt, behandelt, nimmt der Mehrwert weiterer Iterationen im Staging ab. Dann liefern echte Gespräche die wertvolleren Signale.

Go-Live bedeutet nicht, dass die Iteration endet. Es verschiebt den Lernfokus von synthetischen Tests zu Produktions-Transkripten. Die Bewertungskriterien, die den Go-Live definiert haben, werden zum Maßstab für die Live-Performance – und der Zyklus beginnt von vorn.

Feedback-Loops, Evaluation und der richtige Zeitpunkt zum Stoppen

Sobald Tests definiert und aktiv sind, werden Lücken in der Pipeline schnell sichtbar. Durch

Die wichtigste Disziplin in dieser Phase ist, Änderungen zu validieren statt sie als gegeben anzunehmen. Ein Fix, der ein Problem löst, kann unbemerkt ein anderes verursachen. ElevenAgents unterstützt Versionierung, sodass Teams neue Iterationen zunächst mit einem kleinen Nutzeranteil testen können, bevor sie breit ausgerollt werden. So lässt sich sicherstellen, dass Verbesserungen tatsächlich zu besseren Ergebnissen führen und nicht nur Fehler verschieben.

Was schiefgehen kannVersionierung, sodass Teams neue Iterationen zunächst mit einem kleinen Nutzeranteil testen können, bevor sie breit ausgerollt werden. So lässt sich sicherstellen, dass Verbesserungen tatsächlich Verbesserungen sind – und nicht nur das Fehlerbild verschieben.

Der folgenschwerste Fehler in dieser Phase ist, auf gestaffelte Rollouts zu verzichten und Änderungen direkt an alle Nutzer auszurollen. Ohne gestaffelte Rollouts fehlt die Möglichkeit, die Auswirkungen einzelner Änderungen zu isolieren – und bei großem Volumen ist es nahezu unmöglich, die Ursachen für Verbesserungen oder Rückschritte in den Plattformmetriken zu erkennen. Die gesamte Nutzerbasis als Testumgebung zu nutzen, ist nicht nur riskant, sondern nimmt die nötige Transparenz für fundierte Entscheidungen.

Neben der Rollout-Strategie gibt es zwei weitere Fehlerquellen. Erstens: Überreaktion auf aktuelle Fehler. Wenn ein prominentes Gespräch schiefgeht, besteht die Versuchung, sofort und breit zu patchen – aber reaktive Prompt-Änderungen ohne vollständigen Testlauf führen oft zu Rückschritten bei zuvor stabilen Verhaltensweisen. Jede Änderung, auch kleine, sollte als neue Iteration behandelt und getestet werden. Zweitens: Evaluation Drift. Mit der Zeit kann das Team unbewusst die Anforderungen für bestandene Tests senken, besonders unter Zeitdruck. Die zu Beginn definierten Bewertungskriterien sollten der Anker bleiben. Wenn sie zu streng erscheinen, ist eine bewusste Anpassung sinnvoll – nicht das schleichende Absenken der Standards.

Skalieren mit Vertrauen

Mehr Traffic ist eine Vertrauensentscheidung, keine Frage des Timings. Das Signal zur Skalierung ist, wenn der Agent die Bewertungskriterien konsistent über mehrere Testläufe erfüllt, die Plattformmetriken stabil sind und gestaffelte Rollouts keine signifikanten Rückschritte gegenüber der Kontrollgruppe zeigen.

Eine häufige Frage ist, wie viel Traffic für belastbare Aussagen nötig ist. Batches mit weniger als 100 Anrufen pro Branch sind zu variabel für eine zuverlässige Bewertung. Eine 60%-Erfolgsquote bei 25 Anrufen und bei 100 Anrufen bedeuten ein sehr unterschiedliches Vertrauensniveau. Neben der Anzahl sollte das Batch auch groß genug sein, um die gesamte Bandbreite realistischer Eingaben abzudecken – inklusive Edge Cases, seltener Intentionen und Fehler, die erst bei Volumen auftreten.

Mehr Traffic verstärkt sowohl das, was funktioniert, als auch das, was nicht funktioniert. Zu skalieren, bevor Kernfehlerquellen behoben sind, schafft Supportaufwände, die schwer rückgängig zu machen sind.

Wiederholen und verfeinern

Zu wissen, wann man aufhören sollte, ist genauso wichtig wie zu wissen, was zu beheben ist. Iteration bringt abnehmenden Mehrwert, und das richtige Signal für eine Pause ist, wenn der Agent die zu Beginn definierten Bewertungskriterien konsistent erfüllt. Ab diesem Punkt überwiegt das Risiko weiterer Änderungen den Nutzen.

Wie „konsistente Erfüllung der Kriterien“ aussieht, hängt vom Kontext ab. Teams mit eingeschränktem Datenzugang oder unvollständigen Integrationen erreichen oft Eskalationsraten um 50 %, bis diese Hürden gelöst sind. Wo der Datenzugang stark ist, liegen die besten Deployments meist bei über 80 % Task Completion und unter 20 % Eskalation. Wichtiger als jede einzelne Zahl ist die Stabilität: Konsistente Leistung über mehrere Wochen Produktions-Traffic ohne signifikante Rückschritte in den Testläufen ist das eigentliche Signal. Wenn der Mehrwert der nächsten Iteration geringer ist als das Risiko eines Rückschritts, ist es Zeit zu stoppen.

Das bedeutet nicht, dass die Arbeit abgeschlossen ist. Bei neuen Anforderungen beginnt der Prozess von vorn. Die Scoping-Fragen aus dem ersten Build bleiben auch beim zweiten relevant. Der Unterschied: Teams, die in die zweite Runde gehen, haben bereits eine Testsuite, eine Bewertungsbasis und operative Erfahrung – ein Vorteil, den der erste Zyklus erst aufbauen musste. Dieser kumulierte Vorteil trennt Unternehmen, die nachhaltigen Nutzen aus Voice Agents ziehen, von denen, die in Proof-of-Concepts steckenbleiben.

Fazit

Die Teams, die wir beobachten, schließen die Lücke zwischen Deflection und Lösung, indem sie vor dem Build definieren, wie „gut“ aussieht, Disziplin im Iterationszyklus wahren und jede Auslieferung als Basis für die nächste betrachten. Konversationale Agents sind keine Einmal-Deployments – echte Gespräche bringen Edge Cases hervor, die keine Testsuite vollständig abdeckt, und die Arbeit an Verbesserungen endet nicht mit dem Go-Live.

ElevenAgents ist auf diese Realität ausgelegt. Agent-Testing, Gesprächsanalyse und gestaffelte Rollouts sind das Fundament, das aus einem Proof-of-Concept ein System macht, das Kundenprobleme tatsächlich löst – nicht nur abwehrt. Diese Lücke zu schließen, lohnt sich.

ElevenAgents ist auf diese Realität ausgelegt. Agent-Tests, Gesprächsanalyse und gestaffelte Rollouts sind das Fundament, das aus einem Proof-of-Concept ein System macht, das Kundenanliegen wirklich löst – nicht nur abwehrt. Das ist die Lücke, die es zu schließen gilt.