Call Center RPA: Was es automatisiert und wo es versagt

Was Call-Center-RPA wirklich ist

Ich habe die letzten Jahre damit verbracht, KI-Agenten zu bauen, die auf echten Support-Warteschlangen laufen, und das Erste, was ich sagen möchte, ist: RPA hat sich seinen Ruf ehrlich verdient. Es leistet etwas Reales.

Robotergestützte Prozessautomatisierung ist, in den eigenen Worten der Anbieter, Software-Roboter, die menschliches Handeln nachahmen in digitalen Systemen, um "sich wiederholende, regelbasierte Aufgaben wie Dateneingabe, Dateiverschiebung oder Transaktionsverarbeitung" auszuführen. Der Bot macht buchstäblich das, was ein Mitarbeiter mit Maus und Tastatur tun würde, klickt sich durch dieselben Bildschirme, nur schneller und ohne sich zu langweilen. Automation Anywhere sieht das genauso: RPA ist die "Arme und Beine" der Automatisierung, die zuverlässige Ausführung strukturierter, wiederholbarer Schritte.

Der Grund, warum es überhaupt zu einem Call Center passt, ist, dass ein großer Teil der Contact-Center-Arbeit tatsächlich kodifizierbar und repetitiv ist. Wenn eine Schichtleitung den Morgen damit verbringt, Ticketfelder in ein Abrechnungstool zu kopieren, ist das eine Regel, die man aufschreiben kann, und alles, was man als Regel aufschreiben kann, kann ein Bot ausführen.

Es gibt zwei Varianten, die man kennen sollte, weil sie unterschiedlichen Aufgaben im Tagesgeschäft entsprechen:

• Unbeaufsichtigtes RPA läuft eigenständig, nach Zeitplan oder Auslöser, ohne dass jemand zuschaut. Automation Anywhere setzt es für Back-Office-Prozesse wie Massendateneingabe und Systemintegrationen ein. Man denke an nächtliche Batch-Arbeit.
• Beaufsichtigtes RPA begleitet einen aktiven Mitarbeiter und schaltet sich mitten im Anruf ein, um ein Formular auszufüllen oder einen Datensatz abzurufen. Der Anbieter nennt dies ausdrücklich die Kategorie für Kundenservice- und IT-Helpdesk-Arbeit, mit einem Menschen im Prozess. Das ist der klassische "Agenten-Desktop"-Bot.

Keines von beiden versteht irgendetwas. Das ist keine Kritik, das ist die Konstruktion. RPA ist von Natur aus deterministisch, genau deshalb ist es zuverlässig und überprüfbar, und genau deshalb fällt es in dem Moment um, in dem die Arbeit aufhört, deterministisch zu sein.

Was Call-Center-RPA gut automatisiert

Hier zeigt RPA wirklich, was es kann. Die meisten davon sind unglamouröse Aufgaben, die still und leise den Tag eines Mitarbeiters auffressen, und sie einem Bot zu übergeben, ist ein echter Gewinn.

Automation Anywhere listet genau diese Punkte unter seinen Kundenservice-Anwendungsfällen auf: automatisierte Anfragebearbeitung, Ticketing und Weiterleitung sowie Onboarding-Dateneingabe. Und die Ergebnisse sind real, wenn der Prozess stabil ist. Ihre Fallstudie zur City of Seattle ist konkret und überzeugend: Die Stadt arbeitete einen Rückstau von über 6.000 Anträgen für Versorgungsprogramme ab, automatisierte 700 tägliche Anfragen zu gesperrten Passwörtern und sparte über 30 Stunden im Monat, alles mit regelbasiertem RPA, bevor überhaupt eine KI-Schicht hinzukam.

Wenn dein Call Center einen Stapel dieser repetitiven Back-Office-Aufgaben hat, ist RPA eine legitime Antwort und fügt sich ohne großes Drama neben den Rest deines Kundenservice-Workflows ein. Das ist der Teil der Geschichte, den RPA-Anbieter gut erzählen, und sie liegen damit nicht falsch.

Wo Call-Center-RPA versagt

Jetzt zu dem Teil, den die Broschüre ausspart. Das gesamte Modell von RPA, ein Bot, der so tut, als wäre er ein Mensch, der auf einen Bildschirm klickt, ist auch seine Bruchstelle. Ich habe Teams beobachtet, die versucht haben, damit die tatsächliche Support-Warteschlange zu tragen, und es versagt tendenziell auf drei vorhersehbare Arten.

Es ist störanfällig. Der Bot zielt auf bestimmte Schaltflächen und Felder auf einer Seite. Ändere das Layout, benenne ein Feld um oder bringe ein UI-Update heraus, und die Automatisierung reißt ab. Praktiker in r/rpa sagen es unverblümt:

"UI automation is brittle, so we built an AI-based solution... that makes UI-based automation on websites extremely easy."

r/rpa, on constant UI changes breaking automations

Die Wartung frisst dich bei lebendigem Leib. Jeder störanfällige Bot ist ein Bot, den jemand betreuen muss. Das ist die versteckte Rechnung, und die Zahlen bestätigen es: In der globalen Deloitte-Umfrage zählen nur Organisationen mit 51 oder mehr laufenden Automatisierungen als "Scaler", und die meisten Programme bleiben deutlich darunter stecken. Ein Drittel der Teams, die Automation-as-a-Service nutzen, lagert speziell das Management und die Wartung ihrer Bots aus, weil sie am Leben zu halten selbst schon ein Job ist. Wie es ein r/automation-Thread formulierte: Ohne ernsthaftes Engineering dahinter "wird der Wartungsaufwand einen mittel- bis langfristig bei lebendigem Leib fressen".

Es kann nicht mit Sprache, Ausnahmen oder Ermessen umgehen. Das ist der große Punkt für ein Call Center, denn genau das ist die eigentliche Arbeit. In dem Moment, in dem ein Kunde eine Frage umformuliert, ein unerwartetes Dokument anhängt oder auf einen Grenzfall ohne Regel stößt, hat der Bot nichts in der Hand. Sogar die eigenen Anbieter von RPA geben das zu: Ohne KI kann RPA "nur mit strukturierten Daten effektiv arbeiten... das begrenzt die Wirksamkeit von RPA und schiebt mehr Ausnahmen an menschliche Mitarbeiter zurück". Der Konsens der Community ist derselbe, und erfrischend fair dabei:

"RPA thrives in rules based end to end process so it's more reliable for structured tasks, while agents thrive on processes having lots of nuances... Not everything needs an LLM to perform rules based decisions."

r/rpa, "RPA vs AI agents vs Agentic Process Automation"

Dieses letzte Zitat ist die ehrliche Einordnung. RPA ist nicht schlecht, es ist eng begrenzt. Und eine Support-Warteschlange besteht größtenteils aus nuanciertem, gesprächsbasiertem Material, das außerhalb seiner Spur liegt, weshalb noch mehr RPA an Tickets zu schrauben selten etwas bei der Ticket-Automatisierung bewegt.

RPA vs. KI-Agenten: Wer macht was

Die unnütze Version dieser Debatte ist "RPA gegen KI, wer gewinnt". Die nützliche Version ist: Sie erledigen unterschiedliche Aufgaben, und die guten Aufstellungen nutzen beides. Hier ist die Arbeitsteilung, die ich vorschlagen würde.

Der KI-Agent liest die eingehende Nachricht, findet heraus, was der Kunde tatsächlich will, und entscheidet über den nächsten Schritt. Der RPA-Bot, falls überhaupt noch einer gebraucht wird, übernimmt die deterministische Ausführung: sich ins ERP einloggen, Daten verschieben, den festen Regeln folgen. Der Mensch kümmert sich um die echten Ausnahmen und behält das Ganze im Blick. UiPath beschreibt die gleiche Aufteilung: Agenten analysieren und entscheiden, RPA setzt diese Entscheidungen zuverlässig um, und Menschen sorgen für Aufsicht.

Deshalb hat sich die Rahmung leise von "Wird KI RPA ersetzen" zu "KI oben, RPA darunter" verschoben, und deshalb spricht die Rechnung zu den Kosten von KI gegenüber Menschen zunehmend dafür, den Agenten auf das Gespräch zu setzen. Die Kategorie ist in drei Schritten gereift.

Zuerst kam die schlichte Aufgabenautomatisierung (das RPA der 2010er-Jahre, das jeder vor Augen hat). Dann die intelligente Automatisierung, die RPA mit maschinellem Lernen und Sprachmodellen kombinierte, sodass es unstrukturierte Daten lesen konnte wie E-Mails und Dokumente. Jetzt die agentische KI, bei der der Agent das Verstehen und Entscheiden übernimmt und RPA zur Ausführungsebene wird, die er aufruft. Gartner verzeichnete allein in der zweiten Hälfte von 2024 einen Anstieg der Kundenanfragen um 750% zu agentischer Automatisierung, was zeigt, wohin die Nachfrage geht.

Für eine Support-Leitung ist die praktische Lesart einfach. Wenn du entscheidest, wie eine bestimmte Aufgabe automatisiert werden soll, frage dich, um welche Art von Aufgabe es sich handelt. Nutze das Tool unten, um das zu überprüfen.

Wo eesel ins Bild passt

Das ist die Ebene, an der ich tatsächlich arbeite: die gesprächsbasierte, für die RPA nie gebaut wurde. eesel AI ist ein KI-Agent für den Helpdesk, der das eingehende Ticket oder den Chat liest, die Antwort aus deinem eigenen Wissen zieht und es löst, oder eine Antwort entwirft, die ein Mitarbeiter verschickt. Das ist die "KI entscheidet"-Hälfte des Bildes, und als Teil von KI im Kundenservice fügt es sich in den Helpdesk ein, den du bereits betreibst, statt dich zu bitten, irgendetwas neu aufzubauen.

Ein paar Dinge machen das anders, als RPA einfach auf deine Tickets anzusetzen:

• Es lernt aus deiner eigenen Historie. eesel lernt aus deinen vergangenen Tickets, deinem Hilfecenter und deinen Makros, sodass es vom ersten Tag an in deinem eigenen Ton antwortet, statt für jedes Szenario eine geschriebene Regel zu benötigen. Das ist das Gegenteil des Wartungs-Laufbands, auf das dich RPA-Skripte setzen.
• Du kannst simulieren, bevor es live geht. Das kommt aus eigener schmerzhafter Erfahrung. Wir haben gesehen, wie selbstbewusst klingende Bots still und leise falsche Antworten gegeben haben, deshalb führt eesel eine Simulation gegen deine historischen Tickets durch und zeigt dir die Lösungsrate und die genauen Antworten, bevor es mit einem echten Kunden in Berührung kommt. Du siehst, wie es sich verhalten wird, und schaltest es dann hoch.
• Es weiß, wann es aufhören muss. Das Einzige, was uns Käufer am häufigsten sagen, dass sie es wollen, ist nicht die vollständige Automatisierung, sondern Kontrolle. Wie es eine Support-Leitung eines DTC-Unternehmens uns gegenüber formulierte: "Ich brauche eine KI, die nur die Tickets bearbeitet, bei denen sie sich sicher ist, und alle anderen in Ruhe lässt." eesel führt konfidenzbasierte Eskalation und Übergabe durch, löst also, was es sicher weiß, und übergibt den Rest sauber.

Wenn der Prozess wirklich deterministisch ist, wehrt sich eesel auch nicht dagegen: Es löst als Teil der Ticketlösung dieselbe Art von Aktionen aus, die RPA ausführen würde (taggen, zuweisen, Status aktualisieren, eine API ansprechen). Das Gridwise-Team, das auf Zendesk läuft, sah, wie eesel im ersten Monat 73% seiner Tier-1-Anfragen löste, und merkte an, dass die Plattform "sogar Automatisierungen für Ticket-Tagging, Zuweisung und Statusaktualisierungen enthält". Das ist die ganze Idee: KI im Gespräch, deterministische Aktionen bei der Ausführung.

Es beantwortet auch die Frage "Warum nicht einfach selbst bauen", die sich viele engineering-lastige Call Center stellen. Das Team von GENERAL BYTES fasste zusammen, warum sie gekauft statt gebaut haben: "Wir hätten versuchen können, unsere eigene LLM-Anwendung zu schreiben, wollten aber unsere Zeit nicht dort investieren. Wir wollten etwas, das wir nicht warten müssen." Dieser Wartungspunkt ist derselbe Grund, warum RPA-Skripte teuer werden, nur eine Ebene höher.

Wie du wirklich anfängst

Wenn du gerade Call-Center-RPA abwägst, ist hier die Reihenfolge, der ich folgen würde, statt alles auf einmal zu automatisieren.

1. Liste deine Aufgaben auf und sortiere sie. Teile die Warteschlange in deterministische Back-Office-Arbeit (Dateneingabe, Berichtsabrufe, Statusaktualisierungen) und gesprächsbasierte Arbeit (alles, wo ein Mensch liest und interpretiert). Der erste Bereich ist der Platz für regelbasierte Automatisierung; der zweite ist eine Aufgabe für KI-Kundenservice-Software.
2. Automatisiere das Stabile und Langweilige mit Regeln. Für wirklich feste Prozesse reicht ein regelbasierter Bot oder die im Helpdesk integrierte Workflow-Automatisierung, und das ist günstiger als ein KI-Agent. Geh nur mit dem Wissen hinein, dass du es warten musst, wenn sich die Bildschirme ändern.
3. Setze einen KI-Agenten auf das Gespräch. Für Tickets und Chats, die Verständnis erfordern, nutze ein KI-Ticketingsystem, das die Absicht liest und löst. Das ist die Ebene, die tatsächlich deine Lösungs- und Tier-1-Ablenkungszahlen bewegt, und wo die echten Einsparungen bei den Support-Kosten sichtbar werden.
4. Simuliere, dann rolle schrittweise aus. Teste vor dem Livegang an echten historischen Tickets, starte die KI bei den Ticket-Typen, bei denen sie am sichersten ist, und weite von dort aus aus. Schalte nicht am ersten Tag alles auf automatisch.

Der Fehler, den ich am häufigsten sehe, ist, das als ein großes Automatisierungsprojekt zu behandeln. Das ist es nicht. Es sind zwei verschiedene Aufgaben, und die Teams, die gewinnen, nutzen für jede das richtige Werkzeug.

Teste eesel für dein Call Center

Wenn deine Warteschlange größtenteils aus der gesprächsbasierten Ebene besteht, ist genau dafür eesel AI gemacht. Es ist ein KI-Agent, der sich in Minuten in deinen bestehenden Helpdesk einfügt, aus deinen vergangenen Tickets und deiner Wissensdatenbank lernt und die vorderste Linie löst, während er den Rest sauber an dein Team übergibt. Der Teil, der die Leute meist überzeugt: Du kannst es an vergangenen Tickets simulieren und die echte Lösungsrate sehen, bevor auch nur ein einziger Kunde damit spricht, sodass kein Vertrauensvorschuss nötig ist.

Es ist kostenlos zu testen, und du kannst es auf deinen Helpdesk richten, ohne etwas neu aufzubauen. Das ist das ganze Angebot: Behalte RPA für die Verrohrung, falls du es hast, und lass einen KI-Agenten die Gespräche übernehmen, für die es nie gebaut wurde.