KI & Automatisierung

Zara AI Calling-Workflow

Ein KI-Sprachagent kann ein Verkaufsgespräch führen. Das ist eine Demo. Daraus etwas zu machen, worauf ein Unternehmen läuft, heißt zu entscheiden, wann gewählt wird, was bei jedem Ergebnis passiert, wem das Follow-up gehört und wer das Ganze abschalten darf. Genau diesen Workflow habe ich gebaut.

10+ Kampagnen in Produktion · je 25.000+ angesprochene Kunden · 3 Märkte

Zara AI Calling-Workflow: je 25.000+ angesprochene Kunden pro Kampagne, über 10+ Kampagnen und 3 Märkte

Das Problem

Eine Kampagne bedeutete, eine Kundenliste von rund 25.000 Personen abzuarbeiten. Der Vertrieb konnte in dem Zeitfenster, in dem eine Kampagne lief, unmöglich so viele Nummern wählen, und keine Terminplanung änderte daran etwas, denn die Grenze war schlicht, wie viele Anrufe ein Mensch in einer Woche schafft. Wer erreicht wurde, wurde von Hand notiert, und das Follow-up lebte im Gedächtnis oder auf einem Zettel. Die Grenze war nie das Verkaufsargument. Es war das Wählen.

Wofür ich verantwortlich war und wofür nicht

Ein Kollege hat die erste Recherche gemacht, ob ein Sprachagent überhaupt ein Verkaufsgespräch führen kann. Ich habe den Workflow entworfen und gebaut, der aus dieser Fähigkeit ein betriebsfähiges System gemacht hat: wie eine Kampagne startet, wie Anrufe getaktet werden, was bei jedem Ergebnis passiert, wie aus einem Follow-up eine Aufgabe mit klarem Verantwortlichen wird, über beide CRMs hinweg, Propforce und Jarvis, und wie der Fachbereich das Ganze stoppt.

Klar gesagt: Der Agent hat das Telefon bedient. Der Workflow hat entschieden, wann es klingelt und was danach passiert. In der zweiten Hälfte steckt die Ingenieursarbeit.

Wie es abläuft

VORHER VERTRIEB WÄHLT VON HAND ERGEBNIS AUF PAPIER FOLLOW-UP IM KOPF Rund 25.000 Kunden pro Kampagne, gegen ein Team, das einige Hundert Anrufe am Tag schafft. NACHHER PRODUKT- & FACHBEREICH pro Kampagne oder per Trigger aktivierbar. Ohne Deployment. KAMPAGNE Kundensegment WARTESCHLANGE getaktet, mit Retry ZARA AI wählt die Nummer, führt das Gespräch ANRUFSTATUS angenommen, verpasst, abgelehnt, Mailbox NACHFASSEN Transkript analysiert · CRM-Aufgabe erstellt WhatsApp bei verpasst oder Follow-up RÜCKRUF ZURÜCK IN DIE WARTESCHLANGE

Rekonstruiert aus dem System, wie ich es gebaut habe. Kein internes Diagramm und kein Screenshot wird hier wiedergegeben.

Der Ablauf

  • Eine Kampagne wird gegen ein Kundensegment definiert und läuft in eine Warteschlange, statt auf einmal loszufeuern. So wird das Volumen getaktet und Fehlschläge werden wiederholt, statt beim Telefonie-Anbieter abgeladen zu werden.
  • Zara AI, der Sprachagent, führt den Anruf und das Gespräch.
  • Jeder Anruf endet in einem Status, nicht in einer Notiz. Angenommen, verpasst, abgelehnt, Mailbox. An diesem Status verzweigt alles Weitere, und genau das ist der Unterschied zwischen einem Workflow und einem Skript.
  • Angenommene Anrufe werden transkribiert und ausgewertet, nach Absicht und Ergebnis, statt irgendwo abgelegt zu werden, wo sie niemand liest.
  • Aus einem Follow-up wird eine Aufgabe im CRM, zugewiesen und nachverfolgt, am selben Kundendatensatz, mit dem der Vertrieb ohnehin arbeitet.
  • Verpasste Anrufe und Follow-ups gehen über WhatsApp raus, damit der Kunde auch dann etwas hört, wenn der Anruf nicht ankam.
  • Rückrufe werden zurück in die Warteschlange eingeplant, womit das Ganze zu einem Kreislauf wird statt zu einer einmaligen Welle.

Der Schalter, der dem Fachbereich gehört

Produkt- und Fachbereiche konnten das automatische Anrufen selbst aktivieren oder deaktivieren, pro Kampagne oder per Trigger, etwa wenn ein neuer Kunde ins System kommt, ohne Deployment und ohne Entwickler dazwischen.

Das ist die Entscheidung, die ich am entschiedensten verteidigen würde, denn sie ist die, die man leicht überspringt. Eine Automatisierung, die nur die Technik stoppen kann, ist kein Betriebswerkzeug, sondern ein Risiko. Kampagnen werden aus Gründen pausiert, die die Technik nie sieht: ein Feiertag, eine regulatorische Frage, eine Preisänderung, ein Markt, der eine Woche still ist. Wenn das Stoppen der Anrufe ein Release braucht, wird das System nervös benutzt oder still aufgegeben. Die Kontrolle dorthin zu legen, wo die Verantwortung ohnehin lag, hat daraus etwas gemacht, das der Fachbereich betrieben hat, statt etwas, das er geduldet hat.

Wo es lief

In Produktion, bevor ich DubizzleLabs verlassen habe. Mehr als 10 Kampagnen in Saudi-Arabien, den VAE und Pakistan, jede mit 25.000 oder mehr angesprochenen Kunden und einer Laufzeit von einer Woche oder länger.

Um bei dieser Zahl genau zu sein: 25.000+ ist die Größe der Kundenliste, die eine Kampagne angesprochen hat. Es ist keine Zahl abgeschlossener Anrufe, und für die habe ich keinen belegten Wert. Die Aufgabe des Workflows war, eine Liste dieser Größe überhaupt erreichbar zu machen.

Worauf es aufgebaut war

Die Workflow-Dienste liefen auf NestJS und TypeScript über PostgreSQL, mit einer Message Queue, die den Start der Anrufe taktet und Wiederholungen trägt. Sie waren an die CRM-Seite angebunden, Node.js und TypeScript über SQL mit OpenSearch für die Suche im Kundenbestand, sodass ein Anrufergebnis auf dem Datensatz landete, mit dem der Vertrieb ohnehin arbeitete.

Nichts davon lief als Parallelsystem, und das war Absicht. Eine Automatisierung, die ihren eigenen getrennten Stand der Wahrheit führt, erzeugt Abgleicharbeit, die am Ende mehr kostet als das Wählen, das sie eingespart hat.

Was ich daraus mitgenommen habe

Das interessante Problem war nie das Modell. Es war, dass ein menschlicher Arbeitsablauf implizite Schritte hat, die niemand aufschreibt: der Mitarbeiter, der weiß, dass man während der Gebetszeiten nicht anruft, der, der es zweimal versucht, bevor er aufgibt, der, dem auffällt, dass ein Kunde schon in einer anderen Kampagne ist. Den Anruf zu automatisieren ist einfach. Diese ungeschriebenen Regeln zu finden und zu entscheiden, welche das System abbilden muss und welche bei einem Menschen bleiben, ist die eigentliche Arbeit.

Zurück zu allen Projekten