KI-Support-Anbieter wechseln, ohne Kunden zu stören

Warum der KI-Anbieterwechsel ein Übergabeproblem ist

Ich baue bei eesel KI-Agenten und werde oft in Gespräche über den Wechsel zu einer anderen KI hineingezogen. Fast keines beginnt mit „die KI ist schlecht“. In den Vertriebsgesprächen von eesel in diesem Jahr hatte ein E-Commerce-Betreiber auf Zendesk die native KI ausprobiert, sie als zu teuer und nicht gut genug empfunden und wollte „gestern“ wechseln. Ein Hardware-Support-Team (rund 250 Tickets im Monat, vier Sprachen, ebenfalls auf Zendesk) wurde von seinem KI-Tool weggedrängt, weil der Anbieter sein Geschäftsmodell änderte. Keiner von beiden hatte das Datum gewählt. Jemand anderes hatte es getan.

In diesem Moment überspringen Menschen den sorgfältigen Teil. Wenn die Deadline gestern war oder der Anbieter sie gesetzt hat, wirkt ein harter Cutover wie der schnelle Weg. Meist ist er es nicht, denn kaputt geht nicht die Antwortqualität der neuen KI. Kaputt geht die Übergabe zwischen zwei Systemen, die beide glauben, die Konversation zu besitzen. eesel setzt seit Jahren KI-Agenten in laufenden Support-Queues ein, und wir simulieren jeden Rollout vorab gegen historische Tickets, weil wir gesehen haben, wie ein selbstsicher klingender Bot echten Kunden falsche Antworten gibt. Das meiste, was bei einem Wechsel schiefgeht, ist aber Installationsarbeit: zwei Bots antworten in einem Chat, Tickets werden doppelt erstellt, der Verlauf kam nicht mit.

Deshalb sollten Sie sich diese Umdeutung merken. Sie ziehen keine KI um. Sie verschieben eine Routing-Entscheidung, und das geht Stück für Stück, hin und zurück, solange das alte Setup noch steht. Dieser Leitfaden geht das in der Reihenfolge durch, in der ich es machen würde, wobei die Bordmittel jedes Helpdesks am 20. Oktober 2026 anhand der Herstellerdokumentation geprüft wurden: Bestandsaufnahme, abseits der Produktion bauen und testen, Shadow, Pilot, Hochfahren, dazu laufende Chats, Ihr Team, Rollback-Auslöser und Vertragsdaten.

Zwei Nachbarbeiträge decken Teile ab, die ich nicht wiederhole. Wenn Sie noch entscheiden, ob Sie eine KI eines Drittanbieters auf die integrierte KI Ihres Helpdesks setzen, lesen Sie KI-Schicht vs. integrierte KI. Wenn Sie die Abläufe eines Piloten Woche für Woche wollen, finden Sie sie unter KI-Support-Pilot durchführen.

Schritt 1: Bestand aufnehmen, was die alte KI tut und was mitkommt

Schreiben Sie zuerst alles auf, was die alte KI tut, auch das, woran sich niemand mehr erinnert. Sortieren Sie die Liste dann in zwei Stapel: was in Ihrem Helpdesk liegt (und per Export mitkommt oder einfach bleibt) und was im KI-Anbieter liegt (und neu aufgebaut werden muss). Die ehrliche Zusammenfassung des zweiten Stapels lautet: Ihr Wissen ist portabel, Ihre Konfiguration nicht.

Hier ist die Sortierung, mit der ich anfangen würde, samt dem, was die Dokumentation jedes Helpdesks zum Herausholen sagt.

Die letzte Zeile wird am häufigsten vergessen. Wenn Sie die Zahlen der alten KI nicht erfassen, bevor sich etwas ändert, beurteilen Sie die neue am Ende anhand einer Erinnerung. Ziehen Sie die letzten 8 bis 12 Wochen für die Tickettypen, die Sie umziehen wollen: Lösungsquote (so gezählt, wie Ihr alter Anbieter zählt), Übergabequote, erneuter Kontakt innerhalb von sieben Tagen, erste Antwortzeit und CSAT. Anbieter definieren „gelöst“ unterschiedlich, weshalb ich den Leitfaden zur KI-Lösungsquote und die Liste der Kundenservice-KPIs lesen würde, bevor Sie Definitionen wählen.

Eine weitere Inventur-Gewohnheit, die sich auszahlt: Schreiben Sie das Verhalten der alten KI als einfache Regeln auf: was sie ablehnt, wann sie übergibt, welchen Ton sie nutzt, welche Themen sie nie anfasst. Diese Sätze werden zu den Anweisungen der neuen KI, und sie sind der Teil einer Konfiguration, der tatsächlich übertragbar ist. Wenn Ihre Wissensdatenbank vor der Nutzung durch eine neue KI ohnehin aufgeräumt werden muss, ist ein Audit der Wissensdatenbank die günstigste Woche, die Sie investieren können.

Schritt 2: Die neue KI bauen und testen, ohne die Produktion anzufassen

Bauen Sie die neue KI abseits und testen Sie sie dort, wo sie keinen Kunden erreichen kann. Jeder große Helpdesk bietet dafür einen Ort, und die meisten berechnen nichts dafür.

• Zendesk: Tests in einer Sandbox verbrauchen keine automatisierten Lösungen, ebenso wenig das Test-Widget oder der Konversationssimulator, Tests in der Produktion können es dagegen. Zendesk empfiehlt außerdem Tester, die die Abläufe nicht gebaut haben. Der Leitfaden Sandbox vs. Produktion behandelt die Einrichtung.
• Freshdesk: Der Email AI Agent hat einen Tab Evaluate, in dem Sie ein Testset von Hand aufbauen, Beispiel-E-Mails generieren oder gelöste historische Tickets importieren können. Freshdesk empfiehlt vor dem Einsatz mindestens 20 repräsentative Anfragen, und die Vorschau berührt keine laufenden Konversationen. Siehe auch Freshdesk-Sandbox einrichten.
• Gorgias: Testkonversationen im Playground werden nicht berechnet und senden keine echten Nachrichten an Käufer.
• HubSpot: Der Customer Agent hat Batch-Tests, bei denen Sie jede Antwort als gut oder schlecht bewerten.

Diese Tools testen die jeweils eigene KI des Anbieters, die KI des neuen Anbieters wird also im Tool des neuen Anbieters getestet. Ich würde ein gemeinsames Testset ergänzen, das beide KIs beantworten: etwa 50 echte Tickets aus dem Bereich, den Sie zuerst umziehen, nach Typ gelabelt, mit den schwierigen Fällen darunter (der verärgerte Kunde, die Frage, die Ihre Doku falsch beantwortet, die Anfrage, die an einen Menschen gehen sollte). Wenn die neue und die alte KI dieselben 50 beantworten, sind Unterschiede keine Meinungen mehr. Der Leitfaden Tests für KI-Support-Agenten enthält eine vollständige Testabfolge, und adversariales Testen liefert fiese Tickets zum Ausleihen.

Hier verdient auch die Simulation von eesel ihren Platz. Sie bitten sie im Chat, eine Simulation auf Ihren letzten Tickets auszuführen. Sie spielt sie nach, bewertet ihre Antworten gegen das, was Ihr Team tatsächlich gesendet hat, listet die Lücken auf und schlägt Änderungen an den Anweisungen vor. Sie prognostiziert weder eine Lösungsquote noch Kosten, und einem Tool, das das täte, bevor ein einziger Kunde eine Antwort gesehen hat, würde ich nicht trauen. Sie sagt Ihnen aber an einem Nachmittag, welche Tickettypen bereit sind.

Schritt 3: In Phasen umstellen, erst Shadow, dann Pilot, dann Hochfahren

Jetzt der Teil, in dem sich fast jedes Rollout-Playbook einig ist: Stellen Sie in Phasen um, statt ein Datum zu wählen. Die alte KI beantwortet weiter alles, was die neue noch nicht verdient hat, und der Anteil steigt schrittweise.

Ein Anteil von 5 bis 10 % eines Tickettyps ist aus gutem Grund meine Wahl: groß genug, um Muster zu zeigen, klein genug, dass eine falsche Antwort eine Handvoll Kunden erreicht statt die Hälfte Ihrer Queue. Und eine Regel hält die Zahlen lesbar: Ändern Sie jeweils nur eine Sache und notieren Sie das Datum, denn ein breiterer Anteil und eine neue Anweisung am selben Nachmittag bedeuten, dass Sie nicht sagen können, was das Ergebnis bewegt hat.

Wie Sie einen Anteil schicken, hängt vom Helpdesk ab. Das geben Ihnen die jeweiligen Dokumentationen der Anbieter.

Der Zendesk-Dialog oben zeigt die Einschränkung, die alles prägt: ein KI-Agent pro Kanal. Wenn die alte KI die von Zendesk ist und die neue eine Drittanbieter-Schicht, teilen Sie nach Kanal oder nach einem Tag oder einer Queue auf, nach denen die Drittanbieter-Schicht filtert, denn die eigenen Steuerungen von Zendesk gelten nur für Zendesks eigene KI. Wählen Sie eine Aufteilungsregel, die beide Seiten sehen können (ein Kanal, ein Tag, eine Queue, eine Kundenliste), und schreiben Sie sie in den Plan.

Den Kalender von Luxedo würde ich kopieren, obwohl dort keine andere KI ersetzt wurde. Der Projektorhersteller Luxedo verband im Juli 2026 Gorgias mit eesel, baute im August Wissen und Anweisungen auf und schaltete den Ticket-Trigger in der letzten Augustwoche ein. eesel hinterlässt eine interne Notiz mit einem Antwortentwurf und einer Zusammenfassung, und ein Mensch sendet sie. Zwischen dem 8. August und dem 8. September bereitete es 21 Tickets vor. Niemand wurde von irgendetwas überrascht, und genau darum geht es bei einem Hochfahren.

Hier ist ein Planer für Ihre eigene Version. Geben Sie Ihr Startdatum und die Phasenlängen sowie das Verlängerungsdatum und die Kündigungsfrist des alten Vertrags ein. Er legt den Kalender aus und zeigt, ob Ihre Kündigungsfrist vor oder nach dem Go-/No-go des Piloten liegt, was viele überrascht.

Schritt 4: Doppelte Tickets stoppen, wenn ein Drittanbieter-Bot beteiligt ist

Wenn entweder die alte oder die neue KI ein Drittanbieter-Bot auf Zendesk ist, gibt es eine Regeländerung, die Sie nicht überspringen können. Laut Zendesks eigener Ankündigung erzwingt es ab dem 4. Mai 2026 KI-Agenten-Tickets für alle vom Bot bearbeiteten Konversationen, nicht nur für eskalierte, und KI-Agenten-Tickets werden zum exklusiven Mechanismus der Ticketerstellung für Konversationen, die von KI-Agenten und Drittanbieter-Bots bearbeitet werden. Wenn Ihr Bot zusätzlich so eingestellt ist, eigene Tickets für reine Bot-Chats zu erstellen, bekommen Sie jetzt zwei Tickets für eine Konversation.

Die Ankündigung verlangt drei Dinge, und ich würde sie als Checkliste für den alten wie den neuen Bot behandeln:

1. Ticketerstellung prüfen. Suchen Sie in der Bot-Plattform nach „Ticket erstellen“-Aktionen und nach benutzerdefinierten Webhooks, die aus Bot-Ereignissen Tickets machen. Zendesk schlägt die releaseControl-Aktion vor, wenn Sie Metadaten an gelöste Tickets anhängen wollen.
2. Testen und informieren. Probieren Sie die Integration in einer Sandbox aus, bevor die Änderung die Produktion erreicht, und zeigen Sie Ihrem Team das Format der KI-Agenten-Tickets.
3. Den alten Pfad abschalten. Schalten Sie jede manuelle Ticketerstellung ab, die das dupliziert.

Zendesk fügt eine Beruhigung hinzu: Interaktionen mit Drittanbieter-Bots verursachen keine Gebühren für automatisierte Lösungen, diese Tickets schaffen also Transparenz, keine Rechnung. Sie brauchen aber Platz. KI-Agenten-Tickets zählen zu den Speichergrenzen, sie sind für die meisten Nutzer schreibgeschützt, und Trigger und Automatisierungen feuern auf ihnen nicht, bis eine Konversation an einen Menschen eskaliert. So sieht das aus Sicht des Admins aus, aus einem Thread, der wenige Tage vor diesem Text gepostet wurde:

"The main issue is that there appears to be no way to disable Zendesk from creating an AI Agent ticket for EVERY SINGLE interaction an end user has with the bot, not just handoffs."

u/VestedCrayon, r/Zendesk

Eine Antwort im selben Thread bringt den praktischen Vorteil gut auf den Punkt:

"Luckily they’re easy to exclude from reports and views, but definitely annoying to parse through when you need to find something."

u/yogahippie, r/Zendesk

Der Mechanismus darunter ist Zendesks Switchboard, und es zu verstehen verhindert die meisten Überschneidungsfehler. Jede Konversation hat immer genau eine aktive Switchboard-Integration, die anderen stehen in Bereitschaft. Bei einem Parallelbetrieb bedeutet „beide Bots live im selben Kanal“ also, dass ein Bot jede Konversation besitzt und der Standard-Responder entscheidet, wer neue bekommt. Eine scharfe Kante sollten Sie kennen: Wenn Sie eine Switchboard-Integration löschen, die in einer Konversation aktiv war, werden neue Nachrichten der Standardintegration neu zugewiesen, ohne einen passControl-Webhook. Entfernen Sie den alten Bot, nachdem seine offenen Konversationen geschlossen sind, nicht vorher. Der Leitfaden zur Switchboard-Orchestrierung geht tiefer.

In anderen Helpdesks taucht dasselbe Prinzip in anderen Worten auf. Freshdesk lässt jede Ticketquelle einen aktiven KI-Agenten haben und meldet einen Konflikt, wenn Sie einen zweiten zuordnen wollen. Die Lösung ist überall gleich: ein Besitzer pro Konversation, bestimmt durch eine Regel, die Sie aufgeschrieben haben. Duplikate sind außerdem nicht nur Tickets. Gorgias etwa schaltet Article Recommendations ab, sobald AI Agent im Chat live geht, und empfiehlt, eigene Auto-Antwort-Regeln zu überdenken, damit Käufer nicht zwei Nachrichten bekommen. Listen Sie Ihre alten Begrüßungsnachrichten und Auto-Antworten in Schritt 1 auf, damit Sie sie gezielt abschalten können.

Schritt 5: Beide parallel laufen lassen und Gleiches mit Gleichem vergleichen

Während des Piloten und des frühen Hochfahrens sind beide KIs auf verschiedenen Anteilen live. Nutzen Sie das. Der nützlichste Vergleich ist nicht die neue KI gegen das letzte Quartal, sondern die neue KI gegen die alte KI bei denselben Tickettypen in denselben Wochen, weil Saisonalität, ein Produktlaunch oder eine Preisänderung beide Anteile gleich treffen.

Halten Sie beim Hochfahren eine Holdout-Gruppe bei der alten KI, so wie ein Pilot eine reine Mensch-Kontrollqueue behält. Die A/B-Dokumentation von Zendesk setzt die erste Gruppe als Kontrollgruppe, und der Pilot-Leitfaden erklärt, wie Sie sie dimensionieren. Vergleichen Sie dann vier Dinge, für beide Seiten identisch definiert:

• Lösung: Konversationen, die die KI ohne erneuten Kontakt innerhalb von sieben Tagen geschlossen hat, nicht das eigene „gelöst“-Flag des Anbieters.
• Übergabequote und -qualität: wie oft sie übergibt und ob die Person, die übernimmt, nochmal fragen muss.
• Erneuter Kontakt und CSAT: Kunden, die wegen desselben Problems wiederkommen, und wie sie den Austausch bewerten.
• Kosten pro bearbeiteter Konversation: Jeder Anbieter rechnet in einer anderen Einheit ab, rechnen Sie also beide in Kosten pro Konversation um, die Ihr Team sonst beantwortet hätte.

Das Letzte lässt sich leicht falsch machen, weil die Abrechnungseinheiten so verschieden sind: Zendesk rechnet automatisierte Lösungen ab, der Agent von HubSpot läuft auf HubSpot Credits, und Freddy von Freshdesk hat eine eigene Session-Preisgestaltung. Ich würde die aktuelle Preisseite jedes Anbieters prüfen, bevor Sie den Vergleich aufbauen, und mit dem Leitfaden zu CX-KI-Metriken die Definitionen sauber halten.

Schritt 6: Die bereits laufenden Konversationen schützen

Diesen Abschnitt würde ich zweimal lesen. Ein Kunde, der um 14:55 Uhr einen Chat mit der alten KI begonnen hat, sollte um 15:00 Uhr nicht an eine andere KI übergeben werden, nur weil Sie eine Einstellung umgelegt haben. Die Regel: Leiten Sie neue Konversationen an die neue KI und lassen Sie offene dort enden, wo sie begonnen haben.

Das eigene Verhalten der Anbieter stimmt meist mit dieser Regel überein, was hilft:

• HubSpot: Wenn Sie den Customer Agent abschalten, bearbeitet er bestehende Threads weiter, bis die Konversation gelöst ist, bekommt aber keine neuen.
• Freshdesk: Die Bereitstellung wirkt sofort und gilt nur für neue Tickets. Tickets, die vorher eingingen, werden nicht rückwirkend beantwortet.
• Zendesk: Ein Messaging-KI-Agenten-Ticket gilt als laufend, bis vier Tage ohne Antwort vergehen, die KI die Kontrolle abgibt oder (bei Drittanbieter-Bots) der Bot entscheidet, dass es gelöst ist.

Dann gibt es Übergabe und Rückgabe zwischen einer KI und Ihren Leuten, was sich anders verhält, als die meisten Teams annehmen. Im Zendesk-Messaging bleibt ein Agent erster Ansprechpartner, bis das Ticket geschlossen ist. Die Rückgabe passiert erst, wenn das Ticket von Gelöst auf Geschlossen wechselt, und das dauert standardmäßig vier Tage, sodass ein Kunde, der in diesem Fenster zurückkehrt, weiterhin in der alten Konversation mit dem Menschen landet, nicht bei der KI. Sie können die Automatisierung „Ticket 4 Tage nach Gelöst schließen“ auf eine Stunde verkürzen oder auf 28 Tage verlängern, aber halten Sie einen kleinen Puffer, wenn Sie CSAT nutzen, da die Umfrage in dem Moment startet, in dem ein Ticket auf Gelöst gesetzt wird. Beim Cutover zählt das auf besondere Weise: Wer wiederkehrende Kunden beantwortet, bestimmt dieser Timer, nicht Ihre KI-Einstellung.

Gorgias bietet andere Übergabe-Steuerungen: Themen, die immer eskalieren, einen Schalter dafür, ob die KI Kunden per E-Mail oder SMS mitteilt, dass sie übergibt, und im Chat einen Bestätigungsschritt vor der Übergabe. Egal welchen Helpdesk Sie nutzen, stellen Sie sicher, dass die Übergabe der neuen KI den Kontext mitgibt, den ein Mensch braucht, damit sich der Kunde nicht wiederholen muss. Die Checkliste Best Practices für die Übergabe von KI-Agenten und der Zendesk-Übergabeleitfaden zeigen, was eine gute Übergabe enthält.

Wie lang ist der Schweif? Prüfen Sie Ihre eigenen Daten: Wie lange bleiben von der KI bearbeitete Chats offen, bis sie schließen, und was ist Ihre längste realistische Offenzeit? Diese Zahl ist die Dauer, die die alte KI für bestehende Chats eingeschaltet bleiben muss, nachdem die neue alle neuen übernommen hat.

Schritt 7: Ihr Team vor dem ersten Livetag briefen

Ihre Agenten bemerken Probleme zuerst, und sie erfahren am ehesten von einem verärgerten Kunden vom Wechsel, wenn Sie es ihnen nicht sagen. Geben Sie ihnen vor dem Start des Shadow-Modus ein einseitiges Playbook. Meines hat sechs Zeilen:

1. Was sich ändert und wann. Der Phasenkalender in einfachen Worten, mit dem Datum, an dem jeder Tickettyp umzieht.
2. Ihre Rolle dabei. Sie sind die Prüfer. Täglich fünfzehn Minuten die KI-Konversationen von gestern lesen und falsche mit einem Tag markieren.
3. Was sie anders sehen werden. Bei Zendesk sind KI-Agenten-Tickets für die meisten Nutzer schreibgeschützt, und eskalierte kommen als Neu zurück; bei den anderen Helpdesks das Label oder die Notiz, die die neue KI hinterlässt.
4. Was bei einer Übergabe zu tun ist. Wer sie übernimmt, wo der Kontext liegt und was man einem Kunden sagt, der fragt: „Habe ich mit einem Bot gesprochen?“
5. Wie man eine schlechte Antwort meldet. Ein Tag, ein Kanal, am selben Tag beantwortet. Eine Tag-Konvention wie ai_old und ai_new macht den Vergleich aus Schritt 5 möglich; KI-Support-Tagging hat Ideen zur Benennung.
6. Wer pausieren darf und wann. Nennen Sie in jeder Schicht eine Person.

Das Muster, das ich in Vertriebsgesprächen am häufigsten höre: Teams wollen zuerst einen Co-Piloten und später volle Automatisierung, die KI entwirft Antworten für Agenten und wird befördert, sobald Vertrauen besteht. Das passt perfekt zu einem Wechsel, denn der Shadow-Modus ist genau das. Wenn Sie die Prüfroutine in Ihre Support-SOP schreiben und den Prozess für Richtlinienänderungen daran koppeln, wird aus einer neuen Rückgabefrist nicht in Woche drei still eine falsche Antwort der neuen KI.

Rollback-Auslöser, vor dem Start aufgeschrieben

Legen Sie fest, was als Fehlschlag gilt, solange niemand aufgebracht ist. Wer den Auslöser mitten im Vorfall schreibt, redet ihn sich meist aus. Hier ist die Tabelle, mit der ich beginnen würde; die Schwellen sind meine eigenen Startwerte, passen Sie sie also an Ihr Volumen an.

„Rollback“ sollte bedeuten, eine Einstellung umzulegen, nicht etwas neu zu bauen. Darum bleibt die alte KI durch das Rollback-Fenster konfiguriert: Ihr Pausenhebel ist ein Schalter, etwa Kanal abwählen in Zendesk, das tägliche Konversationslimit in Freshdesk, der Kanalschalter in Gorgias oder das Abschalten des Customer Agent in HubSpot. HubSpot hat eine Besonderheit: Ein Customer Agent kann nach der Erstellung nicht gelöscht werden, nur pausiert, der alte ist also noch da, falls Sie ihn brauchen. Protokollieren Sie jede Pause mit Datum und Grund. Eine Pause ist kein gescheiterter Wechsel, sondern das System bei der Arbeit.

Vertragsüberlappung und Kündigungsfenster

Der günstigste Weg zu wechseln ist, einige Wochen für zwei KIs zu zahlen. Das fühlt sich verschwenderisch an und ist immer noch billiger als die Alternative: die alte KI zu Pilotbeginn zu kündigen und in Woche drei zu merken, dass es kein Zurück gibt.

Für die Geldseite würde ich drei Regeln beachten:

• Behalten Sie den alten Plan durch das Rollback-Fenster. Wenn Ihr Vertrag früher endet, fragen Sie für die Überlappung nach monatlicher Laufzeit. Der Planer oben zeigt genau, wie viele Tage Ihnen fehlen würden.
• Lesen Sie Ihr eigenes Bestellformular zur Kündigungsfrist. Automatische Verlängerung und Kündigungsfristen sind Vertragsbedingungen, keine Produktdokumentation, ich kann Ihnen also nicht sagen, welche Ihr Anbieter hat. Ich kann sagen, dass eine Kündigungsfrist von 60 Tagen vor dem Go-/No-go Ihres Piloten liegen kann, und das ist der Fall, um den sich zu verhandeln lohnt.
• Kennen Sie jede Abrechnungseinheit während der Überlappung. Zendesk sagt, dass Konversationen mit Drittanbieter-Bots keine Gebühren für automatisierte Lösungen verursachen, die Überlappung mit einem Drittanbieter-Bot kostet Sie also den Plan dieses Bots, nicht den Preis pro Lösung von Zendesk. Der Agent von HubSpot wird neuen Konversationen nicht mehr zugewiesen, wenn Ihre Credits aufgebraucht sind, ein Abrechnungsereignis, das wie ein Ausfall aussieht.

Exportieren Sie vor jeder Kündigung, was Sie behalten wollen. Fragen Sie den alten Anbieter schriftlich, welche Daten er herausgeben kann (Konversationsprotokolle, Analysen, Konfiguration) und wie lange nach der Kündigung. Schließen Sie dann den Kreis im Planer: Ihr Kündigungsdatum sollte nach dem Go-/No-go des Piloten liegen, innerhalb oder nach dem Rollback-Fenster.

Fehler, die ich vermeiden würde

• Der Wechsel in Ihre geschäftigsten Wochen. Wählen Sie eine ruhige Phase: Norden-Frisia, eine Fährlinie, deren Fahrplan ab Mai voll wird, testete eesel im Februar und dimensionierte den Plan danach nach dem saisonalen Volumen.
• Eine Konversation mitten im Chat verschieben.
• Zwei Dinge gleichzeitig ändern und dann streiten, welches die Zahlen kaputt gemacht hat.
• Die neue KI mit dem letzten Quartal statt mit dem gleichzeitigen Anteil der alten KI vergleichen.
• Zu Pilotbeginn kündigen, weil der Pilot „gut aussieht“.

Wie eesel einen Wechsel handhabt

Ich bin voreingenommen, hier also die schlichte Version, wo eesel passt und wo nicht. eesel ist ein KI-Helpdesk-Teammate, das sich in den Helpdesk einklinkt, den Sie schon haben, ein Wechsel erfordert also nicht, Ihre Tickets irgendwohin zu verschieben. Es liest Ihr Help Center, Ihre Makros und vergangenen Tickets direkt aus dem Helpdesk, deshalb braucht es nichts aus der alten KI exportiert. Das sind die Integrationen, die am häufigsten eingeschaltet werden:

• Zendesk
• Freshdesk
• Gorgias
• HubSpot

Das passt zu den Schritten oben:

• Portabilität: Makros sind das portabelste Gut, das Sie besitzen. Koffer.ch, ein Schweizer Koffergeschäft auf Freshdesk, liest zuerst seine Makros und verwendet ein passendes Wort für Wort, in jeder der vier Sprachen, in der der Kunde geschrieben hat. Jede Antwort ist ein Entwurf, den ein Mensch sendet.
• Training und Tests: Norden-Frisia, eine deutsche Fährlinie, verband Zendesk während einer einwöchigen Testphase im Februar 2025, zog seine Makros und die Tickets der letzten drei Monate herein und schloss binnen Tagen ab. Vor jedem Go-live spielt die Simulation Ihre vergangenen Tickets nach, damit Sie die Lücken zuerst sehen.
• Phasen: Sie können damit beginnen, dass eesel nur bei einer @eesel-Erwähnung in einer internen Notiz aufwacht, dann zu jeder Kundenticket-Nachricht übergehen und es bei Entwürfen halten, während Sie prüfen. Das ist Ihre eingebaute Shadow-Woche.
• Preise während der Überlappung: eesel hat feste monatliche Credit-Pläne, keinen Preis pro Lösung. Ein Ticket oder ein Chat kostet einen Credit, egal wie lange er läuft, es gibt einen kostenlosen Plan mit 100 Credits ohne Karte, und Teammate beginnt bei 299 $ im Monat für 500 Credits, mit allen Integrationen, Agenten und Plätzen inklusive.

Die Grenzen sollten klar benannt werden. eesel importiert keine Abläufe, Intents oder Konversationsprotokolle anderer Anbieter, die nie zu Tickets wurden, Sie bauen diese also als Anweisungen neu auf, was für die meisten Teams weniger Zeit kostet als der ursprüngliche Aufbau. Und wenn Sie nur die KI wollen, die Ihr Helpdesk ohnehin enthält, brauchen Sie gar keine Schicht; die Vergleichsseiten zu Freddy, Gorgias AI Agent und HubSpot Breeze zeigen, wo die Abwägungen liegen.

eesel ausprobieren

Wenn Sie von Zendesk AI agents, Freddy, Gorgias AI Agent, HubSpot Breeze oder einem Drittanbieter-Bot wegwechseln, probieren Sie eesel zuerst auf Ihrer eigenen Queue aus. Verbinden Sie Ihren Helpdesk, lassen Sie es aus Ihren vergangenen Tickets lernen, führen Sie eine Simulation aus und starten Sie dann mit Entwürfen, während Ihre aktuelle KI weiter antwortet. Das ist die Shadow-Woche dieses Leitfadens, und der kostenlose Plan deckt sie ab.