Um zu CCaaS zu migrieren, ohne Anrufe zu verlieren, leiten Sie Ihre alten Nummern zuerst auf neue Nummern auf der Cloud-Plattform weiter und portieren Sie sie erst ganz zum Schluss. Alles vor der Portierung lässt sich mit einer Konfigurationsänderung rückgängig machen. Eine abgeschlossene Portierung nicht, und eine Portierung in den USA dauert 2 to 4 weeks, sobald die Unterlagen korrekt sind. Erfassen Sie also den Bestand, bauen Sie alles neu auf, testen Sie mit zusätzlichen Nummern und starten Sie einen Pilotbetrieb mit einer Warteschlange, während die meisten Anrufe noch über das alte System laufen.
Die meisten Pläne lassen die Support-Seite aus: Der Helpdesk zieht nicht um, aber seine Verbindungen zur Telefonie schon. Der KI-Helpdesk-Teamkollege von eesel arbeitet im Helpdesk und beantwortet deshalb während der Umstellung weiterhin Tickets.
Für wen dieser Leitfaden gedacht ist (und was Sie zuerst brauchen)
Dieser Leitfaden richtet sich an Support- oder Betriebsverantwortliche, die eine telefonische Kundenservice-Hotline von einer lokalen Telefonanlage oder einem älteren Callcenter-Technologie-Stack auf eine Cloud-Lösung umstellen (CCaaS, Contact Center as a Service): Amazon Connect, Genesys Cloud, Talkdesk, Five9, Zendesk Talk, Aircall, Twilio Flex und andere. Wenn Sie noch eine Plattform auswählen, finden Sie in meiner Übersicht über Callcenter-Software die engere Auswahl. Wenn Sie Freshdesk nutzen, ist das integrierte Freshdesk Contact Center eine weitere Option, und Dialpad sowie die Aircall-Alternativen decken die schlankeren Lösungen ab. In diesem Beitrag geht es um den Umzug selbst.
Ich bin Engineer bei eesel und verbringe den größten Teil meiner Woche mit Integrationen, also viel Zeit in den Helpdesk- und Telefonie-APIs anderer Unternehmen. Dabei sehe ich immer dasselbe Muster: Die Telefonie bekommt einen Projektplan, und für die Verbindungen vom Telefonsystem zum Helpdesk gibt es einen einzelnen Posten mit der Bezeichnung „Integrationen“. Diese Verbindungen sind die Stellen, an denen eine Umstellung unbemerkt schiefgeht.
Wenn Sie auch einen KI-Agenten einsetzen, bietet die eesel CLI Ihren Entwicklern während des Umzugs einen skriptfähigen Nebenzugang: Ein KI-Coding-Agent wie Claude Code kann freigegebenes Wissen hochladen (exportierte Hilfeartikel, Makros, die neuen IVR-Skripte) und dem Agenten dann Testfragen stellen, um seine Antworten zu prüfen, bevor etwas live geht. Die Verbindung zum Helpdesk selbst muss weiterhin eine Person mit Administratorzugriff genehmigen.
Halten Sie vor Schritt 1 Folgendes bereit:
- Eine Kopie der Telefonrechnung oder des Customer Service Record (CSR) für jeden Anbieter. Die Portierungsunterlagen müssen exakt damit übereinstimmen.
- Eine verantwortliche Person für das Anbieterkonto, die unterschreiben darf. AWS verlangt eine handschriftliche Unterschrift auf der LOA (Letter of Authorization, Vollmacht) und gibt an, dass die meisten Anbieter elektronische Unterschriften ablehnen.
- Administratorzugriff auf Ihren Helpdesk und Ihr CRM, denn Sie werden beide neu verbinden.
- Ihre Anrufberichte der letzten 90 Tage (Volumen nach Stunde, Abbruchquote, Bearbeitungszeit) als Ausgangsbasis für den Vergleich mit der neuen Plattform.
Warum migrieren gerade so viele Contact Center?
Für viele Teams ist die Migration keine freiwillige Entscheidung. Bei den großen lokalen Contact-Center-Produkten läuft der Herstellersupport aus, und das britische Kupfertelefonnetz wird abgeschaltet. Hier sind die Termine von den Seiten der Hersteller und Regulierungsbehörden selbst:
| Produkt | Meilenstein | Datum |
|---|---|---|
| Genesys PureConnect | Ende von Wartung und Support | 31. Juli 2025 |
| Microsoft Skype for Business Server 2015 und 2019 | Supportende | 14. Oktober 2025 |
| Avaya Aura Call Center Elite 10.1.x | Ende des Herstellersupports | 1. Januar 2026 |
| Cisco UCCE, PCCE, UCCX, CVP 12.5 und 12.6 | Ende der Software-Wartungsreleases | 31. Dezember 2026 |
| Britisches PSTN von BT (Kupfertelefonnetz), laut Ofcom | Geplante Abschaltung | 31. Januar 2027 |
| Cisco UCCE, PCCE, UCCX, CVP 12.5 und 12.6 | Letzter Supporttermin | 31. Dezember 2027 |
| Mitel MiContact Center Business | Ende des Verkaufs von Erweiterungen | 31. Dezember 2027 |
| Genesys Engage on-prem | Ende der lokalen Lösung | 31. Dezember 2028 |
Wenn eine solche Frist Sie zum Umzug drängt, planen Sie von diesem Datum aus rückwärts und beginnen Sie früh mit der Anbieterseite. AWS gibt an, dass Portierungsanträge bereits "several months before pending go-live dates" offen sein müssen, weil Anbieter Portierungen an Feiertagen und während Wartungsarbeiten blockieren.
Welchen einen Schritt können Sie nicht rückgängig machen?
Die Rufnummernportierung. Jeder andere Schritt einer CCaaS-Migration ist eine Konfiguration, die Sie zurückändern können. Bei der Portierung wechselt die Nummer zu einem neuen Anbieter, und AWS stellt klar, dass nach Abschluss "the gaining carrier has sole control of the phone number." Für den Rückweg brauchen Sie eine neue LOA, neue Unterlagen und eine neue Portierung.
Das verändert die Reihenfolge, in der Sie die Arbeit angehen sollten. Die Frage lautet nicht: „An welchem Tag stellen wir um?“ Sie lautet: „Wie lange können wir beide Systeme parallel betreiben, bevor wir den unumkehrbaren Schritt gehen?“ AWS und Salesforce geben dieselbe Antwort darauf, wie Sie sich diese Zeit verschaffen: zuerst weiterleiten.
Die Voice-Checkliste von Salesforce warnt, dass die Portierung "is highly regulated, can't be rushed," und empfiehlt drei Schritte: eine neue Nummer für Tests und den Produktivbetrieb reservieren, Anrufe von der ursprünglichen Nummer dorthin weiterleiten, bis die Tests abgeschlossen sind, und dann die ursprüngliche Nummer portieren. Der Migrationsleitfaden von AWS beschreibt dieselbe Weiterleitungsphase als Möglichkeit für "rapid rollback (which depends on a relatively simple change to call forwarding rules) without any dependencies on a carrier."
Weiterleitung ist nicht kostenlos, lassen Sie sie also nicht monatelang aktiv. AWS weist darauf hin, dass Sie währenddessen für den eingehenden Anruf auf der alten Nummer, die ausgehende Weiterleitung und den eingehenden Anruf auf der neuen Nummer zahlen und jeder Anruf eine ausgehende Leitung belegt. Ich betrachte Weiterleitung als Absicherung für ein paar Wochen, nicht als Dauerlösung.
Schritt 1: Erfassen Sie, was das alte System tut
Die meisten Überraschungen bei einer Migration entstehen durch etwas, das das alte System getan hat, aber niemand dokumentiert hat. Es ist dieselbe Lektion, die Teams beim Helpdesk-Wechsel lernen. Listen Sie alles auf, bevor Sie etwas entwerfen:
| Bereich | Was Sie festhalten sollten |
|---|---|
| Nummern | Jede Durchwahlnummer (DID), gebührenfreie und SMS-fähige Nummer, welcher Anbieter sie jeweils verwaltet und in welcher Warteschlange sie klingelt |
| Anrufabläufe | IVR-Menüs, Zeitpläne für Geschäftszeiten und Feiertage, Überlaufregeln, Voicemail-Postfächer |
| Routing | Warteschlangen, Skills, Prioritäten, wer Weiterleitungen von wem annehmen kann |
| Integrationen | Anrufprotokollierung im Helpdesk, automatische CRM-Anzeigen, Zahlungsleitungen, jeder IVR-Schritt, der ein Konto abfragt |
| Aufzeichnungen | Wo sie gespeichert sind, Aufbewahrungsregeln, wer sie für die Qualitätssicherung abrufen kann |
| Berichte | Welche Berichte die Führungsebene wöchentlich liest und wie jede Kennzahl berechnet wird |
| Geräte und Netzwerk | Tischtelefone, Headsets, Mitarbeiter im Homeoffice, VPN-Konfiguration |
Zwei Punkte verdienen besondere Aufmerksamkeit. Der erste ist SMS. Genesys warnt, dass SMS bei einer portierten Nummer "will not be automatically transferred along with voice service. In fact, the SMS services will likely be disrupted." Wenn Sie Bestellnachrichten oder Terminerinnerungen von einer Supportnummer aus senden, markieren Sie das jetzt. Der zweite Punkt ist jeder IVR-Schritt, der ein internes System aufruft, etwa eine Datenbankabfrage bei „Geben Sie Ihre Kontonummer ein“. Diese Logik muss auf der neuen Plattform neu aufgebaut werden und wird leicht übersehen, weil sie in einem Ablauf steckt, den seit Jahren niemand geöffnet hat.
Schritt 2: Entwerfen Sie die neue Konfiguration (neu aufbauen, nicht kopieren)
Anrufabläufe lassen sich nicht zwischen Plattformen übertragen. Ein Amazon-Connect-Berater hat es auf Hacker News klar formuliert:
"when someone designs a call center with Amazon Connect, they use a GUI flowchart tool and create "contact flows". You can export the flow to JSON. But it isn't portable to other environments without some remapping."
Da Sie ohnehin neu aufbauen, vereinfachen Sie. AWS selbst empfiehlt mit "don't limit yourself", sich nicht auf die unveränderte Übernahme des alten Callcenters zu beschränken, und Salesforce empfiehlt, mit seinen Standard-Kontaktabläufen zu beginnen und darauf aufzubauen. Ein siebenstufiges IVR, das 2014 sinnvoll war, lässt sich meist auf drei Optionen und einen Rückruf reduzieren. Wenn Sie Zendesk nutzen, zeigt Ihnen mein Leitfaden zum Zendesk Talk IVR ein schlankes Telefonmenü.
Ein Teil dessen, was das alte IVR erledigt hat, ist heute eine Aufgabe für einen KI-Telefonempfang, der einfache Fragen beantworten kann, bevor ein Anrufer überhaupt eine Warteschlange erreicht.
Zwei Designentscheidungen, die Sie in diesem Schritt treffen sollten:
- Wie Alt und Neu nebeneinander bestehen. Mitarbeiter wechseln in der Regel in Gruppen, und AWS merkt an, dass die Migrationsphase "might take several months," während Teams auf unterschiedlichen Plattformen Anrufe untereinander weiterleiten. AWS empfiehlt dedizierte Weiterleitungsnummern zwischen den Plattformen, damit Sie plattformübergreifende Weiterleitungen separat messen können.
- Was mit alten Aufzeichnungen geschieht. AWS nennt zwei Optionen: Aufzeichnungen und Berichte migrieren (prüfen Sie zuerst das Audioformat) oder sie an Ort und Stelle archivieren, bis ihre Mindestaufbewahrungsfrist abgelaufen ist. Archivierung ist oft günstiger, aber jemand muss für den Zugriff auf das alte Archiv verantwortlich sein.
Rechnen Sie damit, dass die neue Plattform fundierte Administrationskenntnisse erfordert. Wenn Sie gleichzeitig Zendesk verlassen, deckt mein Zendesk-Migrationsleitfaden die Ticket-Seite ab. Ein leitender Telefonieingenieur schrieb in seiner Bewertung von Genesys Cloud CX auf G2:
"Genesys Cloud CX is extremely capable, but that capability comes with complexity. There are many situations where something that appears relatively straightforward ends up requiring Architect customization, Data Actions, APIs, or external automation."
Justin H., leitender Telefonieingenieur, G2-Bewertung
Das ist eine treffende Einschätzung der meisten CCaaS-Plattformen für Großunternehmen, einschließlich Genesys. Planen Sie Entwicklungszeit für den Neuaufbau ein und vermeiden Sie es, sich in eine Sackgasse zu manövrieren: Die Vendor-Lock-in-Fallen, die bei KI-Tools gelten, gelten auch bei Telefonieplattformen.
Schritt 3: Verbinden Sie die Helpdesk-Seite neu
Das ist der Schritt, den die meisten Pläne auf eine einzige Zeile reduzieren, und hier würde ich mehr Zeit investieren, als Sie vermutlich erwarten. Das Telefonsystem zieht um. Ihr Helpdesk, Ihr Hilfecenter, Ihre Makros, Ihr CRM und Ihr KI-Agent bleiben, wo sie sind. Die Telefonie zieht um; die Verbindungen zwischen Telefonie und Helpdesk müssen neu aufgebaut werden. Jede einzelne davon muss erneut getestet werden.
Prüfen Sie insbesondere drei Verbindungen:
- Anruf-zu-Ticket-Protokollierung. Erstellt oder aktualisiert jeder Anruf ein Ticket im Helpdesk, dem die Aufzeichnung und der Anrufer zugeordnet sind? Wenn Sie zu einem Telefonie-Tool wechseln, das sich mit Ihrem Helpdesk verbindet, wie CloudTalk und Zendesk, testen Sie bei einem echten Anruf, wie das Ticket aussieht.
- Automatische Anruferanzeige. Sieht der Mitarbeiter den Kundendatensatz, wenn das Telefon klingelt? Das hängt oft davon ab, ob das Format der Anruferkennung mit dem CRM übereinstimmt, und dieses Format unterscheidet sich je nach Anbieter.
- Berichte. Bearbeitungszeit und Abbruchquote werden auf jeder Plattform anders berechnet. Ein G2-Rezensent von Genesys Cloud empfand benutzerdefinierte Berichte als "difficult to navigate." Stimmen Sie die neuen Definitionen vor dem Produktivstart mit der Führungsebene ab, sonst sieht Ihr erster Monatsbericht nach einer Katastrophe aus, die gar keine ist.
Prüfen Sie anschließend, was Ihre Helpdesk-Automatisierung mit Anruftickets macht. Das ist ein Detail, das übersehen wird: Gut betriebene KI-Konfigurationen lassen Telefontickets oft bewusst aus. Lesson Pro, eine Gruppe von Unterrichtsmarken mit zwei Zendesk-Konten, lässt eesel bei 1,900 Tickets pro Monat Notizen und Entwürfe hinterlegen, lässt Voicemails aber unberührt. Luxedo, das Gorgias nutzt, lässt seinen Agenten Anruftickets, Spam und Umfragen überspringen, damit dafür nichts ausgegeben wird. Wenn Ihre neue Telefonieplattform Anruftickets anders benennt oder mit anderen Tags versieht als die alte, greifen diese Regeln unbemerkt nicht mehr, und plötzlich entwirft die KI Antworten auf Voicemail-Transkripte. Prüfen Sie die Trigger, Ansichten und Automatisierungen, die nach Anruftickets filtern.
Der Vorteil ist, dass der E-Mail- und Chat-Support überhaupt nicht von der Telefonieplattform abhängt. Ein KI-Agent, der im Helpdesk arbeitet, läuft während der gesamten Migration weiter. smava, ein deutsches Kreditvergleichsunternehmen, setzt eesel in einer Zendesk-Instanz für zwei Marken ein: 27,000 bearbeitete Tickets in einem Monat, 14,600 kategorisiert und 15,300 Antwortentwürfe vorbereitet. Einer solchen Warteschlange ist es egal, bei welchem Anbieter die Telefonie läuft.
SamCart ist ein ähnlicher Fall auf Freshdesk: Ein Agent bearbeitet Freshdesk-Tickets und ein anderer betreibt den Website-Chat, sodass der schriftliche Support seine eigenen Bahnen hat.
Schritt 4: Testen Sie mit zusätzlichen Nummern
Bauen Sie die neue Konfiguration mit temporären Nummern auf und testen Sie sie, bevor ein Kundenanruf sie erreicht. Die AWS-Checkliste für den Produktivstart verlangt, dass jede betroffene Service-Hotline mit einer temporären Telefonnummer "successfully run UAT scripts" hat.
Richten Sie Ihr Testskript zuerst auf Fehlerfälle aus und dann auf den Normalfall:
| Test | Was passieren sollte |
|---|---|
| Normaler Anruf während der Geschäftszeiten | Richtiges IVR, richtige Warteschlange, Ticket im Helpdesk erstellt |
| Anruf außerhalb der Geschäftszeiten oder an einem Feiertag | Korrekte Ansage zur Schließzeit, Voicemail oder Rückruf |
| Alle Mitarbeiter beschäftigt | Warteansage, dann Überlauf oder Rückruf |
| Weiterleitung an ein Team, das noch auf dem alten System arbeitet | Anruf wird verbunden, der Anrufer muss sich nicht wiederholen |
| Anrufer drückt Tasten im IVR | Tastatureingabe (DTMF) wird in jedem Menü erkannt |
| Helpdesk oder CRM ist ausgefallen | Mitarbeiter kann den Anruf weiterhin annehmen |
| Ein Mitarbeiter wählt 911 über ein Softphone | Verbindung ohne Vorwahl, und die Benachrichtigung wird ausgelöst (siehe unten) |
Prüfen Sie außerdem Ihre Kapazitätsgrenzen, bevor Sie in größerem Umfang testen. AWS gibt an, dass neue Instanzen mit Kontingenten von nur "10 concurrent calls or 5 phone numbers" starten können. Beantragen Sie Erhöhungen deshalb frühzeitig. Und testen Sie an den tatsächlichen Arbeitsplätzen der Mitarbeiter: AWS empfiehlt kabelgebundene USB-Headsets statt Bluetooth sowie kabelgebundenes Ethernet und rät dazu, vor Beginn der Migration Budget für Dongles einzuplanen.
Schritt 5: Starten Sie einen Pilotbetrieb mit einer Warteschlange per Weiterleitung
Wählen Sie eine Warteschlange mit geringem Risiko (allgemeine Anfragen, eine interne IT-Hotline, eine kleine Region; mein Beitrag Callcenter vs. Service Desk erklärt, warum IT-Hotlines anders funktionieren) und leiten Sie deren Nummer auf die neue Plattform weiter. Lassen Sie die Leitungen mit hohem Volumen und hohem Risiko, etwa die Abrechnung, auf dem alten System, bis der Pilotbetrieb reibungslos läuft.
Legen Sie vor dem Start Ihre Rückfallkriterien in Zahlen fest. Die AWS-Checkliste für den Produktivstart fordert Sie auf, angenommene Anrufe, Abbruchquote, durchschnittliche Bearbeitungszeit und Warteschlangenlänge in Echtzeit zu beobachten und eine Konferenzschaltung offenzuhalten, "until go-live (or rollback) activities have been completed." Ich würde etwas festhalten wie: „Wenn die Abbruchquote eine Stunde lang mehr als doppelt so hoch ist wie der Ausgangswert der letzten 90 Tage, stellen wir die Weiterleitung zurück“, und vereinbaren, wer diese Entscheidung treffen darf.
Ziehen Sie dann die übrigen Warteschlangen gruppenweise um. AWS weist darauf hin, dass die Phase mit zwei Plattformen kostspielig ist und dass mit ihrer Dauer auch "the risk of human errors such as making changes on the wrong platform." steigt. Gehen Sie stetig vor, nicht langsam.
Schritt 6: Portieren Sie die Nummern
Sobald jede Warteschlange mit weitergeleiteten Nummern reibungslos gelaufen ist, portieren Sie die ursprünglichen Nummern. Das sagen die wichtigsten Plattformen zum Zeitrahmen:
| Plattform | Zeitrahmen für die Portierung (laut eigener Dokumentation) | Worauf Sie achten sollten |
|---|---|---|
| Amazon Connect | 2 bis 4 Wochen in den USA und Kanada, 2 bis 6 Monate anderswo | US-Anträge können frühestens 30 Tage vor dem Portierungstermin eingereicht werden |
| Genesys Cloud | 2 bis 3 Wochen vorher einreichen; die Terminbestätigung kann bis zu 10 Tage dauern | SMS zieht nicht mit der Sprachtelefonie um |
| Talkdesk | 2 bis 4 Wochen nach Genehmigung der Unterlagen | Sie können den Portierungstermin nicht auswählen |
| Zendesk Talk | 1 bis 4 Wochen in den USA und Kanada, 6+ Wochen anderswo | Testkonten können keine Nummern portieren |
| Aircall | Je nach Land unterschiedlich, z. B. 7 Werktage in Frankreich, bis zu 45 Tage in Deutschland | Rufnummernblöcke müssen gemeinsam portiert werden |
Die gesetzlichen Vorgaben sehen kürzere Fristen vor als alle diese Angaben. In den USA verlangt die FCC eine einfache Portierung innerhalb eines Werktags und eine nicht einfache innerhalb von vier Werktagen. Aber der Rufnummernblock eines Contact Centers auf einem Trunk ist selten „einfach“, und die Wochen in der Tabelle entfallen auf Unterlagen, Validierung und Terminplanung rund um die eigentliche Umschaltung.
Portierungen scheitern an den Unterlagen. AWS nennt die vier häufigsten Ablehnungsgründe: einen offenen Saldo oder eine nicht bezahlte Portierungsgebühr, einen Namen oder eine Adresse, die nicht mit dem CSR übereinstimmen, eine nicht portierbare Nummer und fehlende Angaben wie eine Unterschrift. Eine abgelehnte LOA "resets the porting timelines." AWS verlangt außerdem, dass die LOA innerhalb der letzten 15 Tage datiert wurde. Unterschreiben Sie sie also nicht schon einen Monat vorher.
Zwei weitere Regeln, die oft überraschen:
- Kündigen Sie den alten Anbieter nicht zu früh. Die FCC rät, die Portierung beim neuen Anbieter zu starten, bevor der alte Dienst gekündigt wird, und Aircall warnt, dass Nummern auf einem gekündigten Konto dauerhaft verloren gehen können.
- Kennen Sie Ihre Stornierungsfrist. AWS benötigt 5 Werktage Vorlauf für eine Stornierung oder Terminänderung, und sobald die Nummer die neue RespOrg erreicht, gilt "the port is complete."
Für den Portierungstag selbst warnt AWS, dass eine Portierung "can be disruptive", weil Routen bei verschiedenen Anbietern aktualisiert werden, auch bei unbeteiligten, und dass "in rare cases it can take several hours", bis sich alles stabilisiert. Portieren Sie an einem ruhigen Werktagmorgen, lassen Sie Mitarbeiter in beiden Systemen angemeldet, beobachten Sie, wie der Anrufverkehr auf der alten Plattform abnimmt, und führen Sie Testanrufe für jeden Ablauf durch.
Schritt 7: Stabilisieren Sie den Betrieb und schalten Sie dann das alte System ab
Nehmen Sie die alte Telefonanlage nicht am Tag nach der Portierung außer Betrieb. Lassen Sie sie über einen vollständigen Abrechnungszyklus und mindestens eine arbeitsreiche Phase hinweg laufen, damit Sie Berichte (und Ihre Callcenter-ROI-Zahlen) vergleichen und bei Streitfällen alte Aufzeichnungen abrufen können. Informieren Sie die Finanzabteilung darüber, dass sich die Kosten überschneiden: AWS merkt an, dass die eigene Abrechnung steigt und die Kosten für das Altsystem erst sinken, nachdem das neue Contact Center live gegangen ist.
AWS weist auch auf eine nichttechnische Lücke hin: "user training, process changes, and service desk changes are often overlooked until the project is close to completion." Bevor Sie das alte System abschalten, stellen Sie sicher, dass Ihre interne IT oder Ihr Service Desk weiß, wer für die neue Plattform verantwortlich ist und wie sich dafür eine Störung melden lässt. AWS empfiehlt, eine Teststörung zu melden und sie durch den gesamten Prozess zu verfolgen.
Was ist mit 911 und Mitarbeitern im Homeoffice?
Das ist in den USA eine gesetzliche Anforderung, kein nettes Extra. Nach Kari's Law muss jedes nach dem 16. Februar 2020 installierte Mehrleitungstelefonsystem, einschließlich Ihrer neuen Cloud-Konfiguration, Nutzern ermöglichen, 911 direkt ohne eine Vorwahl wie „9“ zu wählen, und eine Benachrichtigung (mit Rückrufnummer und Standort) an eine Person senden, die sie voraussichtlich wahrnimmt.
Für Mitarbeiter im Homeoffice sind die Standortregeln strenger. Nach 47 CFR 9.16 müssen außerhalb des Betriebsgeländes verwendete Geräte, soweit technisch möglich, automatisch einen für Rettungskräfte nutzbaren Standort (eine validierte Straßenadresse) bereitstellen, andernfalls einen Standort, den der Nutzer manuell aktualisiert. Praktisch verstehe ich das so: Erfassen Sie die Adresse jedes Mitarbeiters im Homeoffice, geben Sie ihm eine einfache Möglichkeit, sie bei einem Umzug zu aktualisieren, und testen Sie den 911-Anrufweg nach dem Testverfahren Ihres örtlichen Rettungsdienstes. Fragen Sie Ihren CCaaS-Anbieter vor dem Produktivstart, wie sein Softphone damit umgeht, nicht erst danach.
Checkliste für die Umstellungsbereitschaft
Haken Sie jeden Punkt ab, sobald er erledigt ist. Wenn Sie nicht alle abhaken können, ist es noch nicht Zeit für die Portierung.
Bevor Sie die Portierung beantragen
Wie lange dauert eine CCaaS-Migration?
Für ein Team in einem einzigen Land mit einem Anbieter sind zwei bis drei Monate eine realistische Planung: ein paar Wochen für Bestandsaufnahme und Entwurf, ein paar Wochen für Neuaufbau und Tests, ein Pilotbetrieb und dann die 2 to 4 weeks für die Portierungsunterlagen, die parallel laufen. Mehrere Länder verlängern den Zeitraum, da AWS für Portierungen außerhalb der USA und Kanadas zwei bis sechs Monate angibt und mehr als 10 Rufnummernblöcke oder 10 Standorte als "a project" behandelt, bei dem das zuständige Account-Team einbezogen werden muss.
Auf der Helpdesk-Seite kann es deutlich schneller gehen, und genau deshalb sollten Sie sie getrennt halten. Ein KI-Agent, der im Helpdesk arbeitet, wartet nicht auf die Telefonie. Luxedo verband eesel im Juli mit Gorgias, baute im August das Wissen und die Anweisungen auf und aktivierte den Trigger in der letzten Augustwoche, alles auf Gorgias. Mein Zeitplan für die Einführung von KI-Support erklärt, warum die meisten Teams zwischen zwei und acht Wochen brauchen.
Testen Sie eesel, während Ihre Telefonie umzieht
Eine CCaaS-Migration bedeutet für ein Support-Team ein paar stressige Monate: Mitarbeiter lernen ein neues Softphone kennen, die Pilotwarteschlange läuft noch nicht rund, und die Führungsebene will wissen, warum sich die Berichte geändert haben. Das ist ein schlechter Zeitpunkt, um zusätzlich E-Mail- und Chat-Anfragen auflaufen zu lassen. Der KI-Helpdesk-Teamkollege von eesel kommt in Ihren bestehenden Helpdesk (Zendesk, Freshdesk, Gorgias und weitere), lernt aus Ihrem Hilfecenter, Ihren Makros und früheren Tickets (derselben Wissensdatenbank, die Ihre Telefonmitarbeiter nutzen) und entwirft Antworten oder beantwortet Anfragen, damit die schriftliche Warteschlange ruhig bleibt, während die Telefonie umzieht. Sie können seinen Einsatz mit früheren Tickets simulieren, bevor er jemandem antwortet, und die Tarife beginnen laut Preisseite bei $299 pro Monat für 500 Tickets.
Testen Sie eesel kostenlos mit 100 Credits oder buchen Sie eine Demo, wenn Sie Unterstützung dabei möchten, den Einsatz rund um Ihre Umstellung zu planen.