Zendesk-Instanzen zusammenführen oder aufteilen, ohne eine Antwort zu verpassen
Zendeskzu ZendeskMigration

Zendesk-Instanzen zusammenführen oder aufteilen, ohne eine Antwort zu verpassen

Migrieren Sie Zendeskzu Zendeskohne Datenverlust, Ausfallzeiten oder Betriebsunterbrechungen. Ob Sie nach einer Übernahme konsolidieren oder Umgebungen nach Marke, Region oder Compliance-Anforderungen trennen – dieser Datenmigrationsansatz stellt sicher, dass Ihre Agenten weiterarbeiten und Ihre Kunden Antworten erhalten.

Beratungstermin buchen →

Keine Kreditkarte nötig Schnelles Setup

Vertrauen von 40.000+ Unternehmen

Warum Zendesk-Instanzen zusammenführen oder aufteilen?

Organisationen führen Zendesk-Konten nach Fusionen und Übernahmen, internen Konsolidierungen oder zur Reduzierung des Aufwands für die Wartung mehrerer Systeme zusammen.

Teams entscheiden sich für die Zusammenführung Zendesk-Instanzen, wenn:

Sie haben ein anderes Unternehmen übernommen und müssen die Zendesk-Konten zusammenführen, damit die Agenten den gesamten bisherigen Kontext sehen und unter Beibehaltung dieses Kontextes antworten können.

Nach der Konsolidierung Zendesk-Instanzen benötigen die Teams eine gemeinsame Übersicht und einheitliche Reporting-Dashboards für alle Supportfunktionen.

Mehrere Zendesk-Instanzen führen zu doppelten Arbeitsabläufen, redundanten Automatisierungen und Lücken in der Genauigkeit der Berichterstattung.

Durch die Zusammenführung Zendesk-Instanzen eliminieren Teams doppelte Arbeitsabläufe, reduzieren die unkontrollierte Ausbreitung der Automatisierung und zentralisieren das SLA-Management, während gleichzeitig historische Daten erhalten bleiben und Unterbrechungen minimiert werden.

Die Aufteilung Zendesk-Instanzen ist unerlässlich, wenn Marken, Regionen oder Compliance-Vorgaben Unabhängigkeit erfordern.

Teams trennen Zendesk-Instanzen, wenn:

Konflikte zwischen Arbeitsabläufen oder Service-Level-Agreements (SLAs) bestehen zwischen Abteilungen oder geografischen Regionen.

Teams benötigen operative Autonomie, um lokale regulatorische oder Compliance-Anforderungen zu erfüllen.

Für kundenorientierte Support-Erlebnisse ist ein separates Reporting oder Branding erforderlich.

Dieser kontrollierte Migrationsansatz Zendeskreduziert Workflow-Konflikte, falsch weitergeleitete Tickets und Fehler in der Berichterstattung und gibt Abteilungen oder Marken gleichzeitig die nötige Freiheit.

Warum sich eine Migration Zendeskzu Zendeskriskant anfühlt (und wie wir das Risiko beseitigen)

Eine Migration von Zendeskzu Zendeskfühlt sich riskant an, wenn sie ohne Transparenz oder Validierung durchgeführt wird.

Risiko: Verlust kritischer Daten

Die Vorstellung, dass Tickets, Anhänge, private Notizen, Gesprächsaufzeichnungen oder historische Zusammenhänge verloren gehen könnten, lässt Teams zögern. Ein falscher Klick könnte unwiderruflich erscheinen.

So handhabt Help Desk Migration das:

Unser Datenmigrationsservice garantiert die fehlerfreie Migration aller Tickets, Anhänge und Konversationen. Mit Demo-Migrationen können Sie die sichere Übertragung Ihrer echten Daten vor der endgültigen Bestätigung überprüfen. Nichts geht verloren, nichts wird beschädigt.


Risiko: Ausfallzeiten und gestörter Support

Ihre Mitarbeiter arbeiten weiter und Ihre Kunden antworten weiterhin. Supportunterbrechungen sind während der Konsolidierung Zendesk-Instanzen nicht akzeptabel.

So handhabt Help Desk Migration das:

Alle Zendesk-Datenmigrationen laufen im Hintergrund, während Zendeskweiterhin aktiv ist. Während der Delta-Migration können Sie die neuen Aktivitäten migrieren, sodass der Support unterbrechungsfrei weiterläuft und die SLAs erhalten bleiben.


Risiko: Fehlerhafte Arbeitsabläufe, falsch weitergeleitete Tickets und fehlerhafte Zuordnung

Falsche Marken, Formulare, Bearbeiter oder Status können Teams ausbremsen und bei der Konsolidierung Zendesk-Instanzen zu Verwirrung, Missverständnissen und Fehlern in der Berichterstattung führen.

So handhabt Help Desk Migration das:

Der Migrationsassistent unterstützt Sie bei der präzisen Zuordnung von Tickets, Benutzern, benutzerdefinierten Feldern, Makros und Triggern. Sonderfälle wie zusammengeführte Tickets, Folgeaufträge oder gesperrte Benutzer werden automatisch behandelt. Sie validieren jeden Zuordnungsschritt und minimieren so das Risiko.


Risiko: Kosten, Kontinuität der Berichterstattung und historischer Kontext

Eine zu große Datenmenge kann die Kosten erhöhen. Explore-Berichte werden nicht standardmäßig migriert. Anhänge, Screenshots oder Notizen könnten verloren gehen.

So handhabt Help Desk Migration das:

Unser Datenmigrationsservice ermöglicht Ihnen das Filtern von Tickets und Daten, die Wahrung der Berichtsintegrität und die Erfassung aller relevanten historischen Details. Sie behalten die Kontrolle über Umfang und Kosten.

Was einst riskant erschien, wird nun vorhersehbar, sicher und reversibel. Die Mitarbeiter arbeiten weiter, Kunden erhalten weiterhin Antworten, und die Führungsebene gewinnt die Gewissheit, dass der Wechsel von Zendeskzu Zendeskerfolgreich sein wird.

Mit einer Help Desk Migration können Sie nicht raten, sondern die Funktionsfähigkeit live erleben, bevor es darauf ankommt.

Keine Kreditkarte nötig Schnelles Setup

So funktioniert die Migration Zendeskzu Zendesk

Vorbereiten · Kartieren · Testen · Produktivstart · Validieren

Vorbereiten

Ein erfolgreicher Zendesk-zu- Zendesk-Transfer beginnt mit einer detaillierten Vorbereitung:

  • Wählen Sie die Zielinstanz von Zendesk(zusammenführen oder aufteilen) basierend auf den Geschäftsanforderungen aus.
  • Richten Sie Marken, Formulare, Gruppen und SLAs an Ihrer geplanten Architektur aus.
  • Bestätigen Sie den Administratorzugriff auf Quell- und Zielinstanz Zendesk.
  • Den Migrationsumfang festlegen: vollständige Historie oder nur aktuelle und offene Tickets.
  • Erstellen Sie ein Inventar aller benutzerdefinierten Felder, Makros, Trigger und Automatisierungen einschließlich Abhängigkeiten.
  • Identifizieren Sie archivierte Tickets, zusammengeführte Tickets, gesperrte Benutzer und Sonderfälle, die möglicherweise eine individuelle Bearbeitung erfordern.

Karte

Das Mapping definiert genau, wie sich die Daten nach der Migration verhalten:

  • Tickets: Status, Marken, Formulare, Beauftragte.
  • Benutzer und Organisationen: Deduplizierung, Verknüpfungen mehrerer Unternehmen, Umgang mit gesperrten Benutzern.
  • Benutzerdefinierte Felder: Dropdown-Normalisierung, Tag-Verhalten und Umgang mit Feldern in mehreren Formularen.
  • Regeln: Makros werden vollständig migriert; Automatisierungen werden während der Migration deaktiviert und manuell wieder aktiviert.

Prüfen

Tests bestätigen die Genauigkeit und schaffen Vertrauen:

  • Migrieren Sie 20 reale Tickets, einschließlich Sonderfälle wie Tickets mit mehreren Marken, zusammengeführte Benutzer und Folgeaufträge.
  • Überprüfen Sie Konversationen, Anhänge, benutzerdefinierte Felder und Status auf Konsistenz.
  • Verfeinern Sie das Mapping anhand der Ergebnisse und führen Sie die Demo-Migrationen gegebenenfalls erneut aus.
Kostenlose Demo starten

Go-live

Die vollständige Migration wird ausgeführt, während Ihre Zendesk-Quellumgebung weiterhin aktiv bleibt:

  • Die Delta-Migration hilft dabei, die neuen Antworten und Agentenaktualisierungen während der Umstellung zu übertragen.
  • Die Agenten setzen ihre Arbeitsabläufe fort und die Kunden erhalten weiterhin Unterstützung.
  • Die Migration läuft im Hintergrund ab, um die volle Betriebskontinuität zu gewährleisten.

Bestätigen

Dies ist ein kontrollierter Datenmigrationsprozess im Kundenservice, kein riskantes Unterfangen auf eigene Faust:

  • Gleichen Sie die Ticket- und Benutzerzahlen ab, um zu bestätigen, dass alle Daten korrekt migriert wurden.
  • Explore-Berichte müssen neu erstellt werden, da Berichtsdaten nicht standardmäßig migriert werden.
  • Automatisierungen sollten absichtlich wieder aktiviert werden, um unerwartete Auslöser zu vermeiden.
  • Archivieren Sie die Quellinstanz aus Gründen der Compliance oder zur Dokumentation.
  • Dies ist ein kontrollierter Datenmigrationsprozess im Kundenservice, kein riskantes Unterfangen.
Integrationen
Datenzuordnung
Kostenlose Demo-Migration
Vollständige Migration
Ergebnisse überprüfen

Häufige Probleme bei Zendesk-zu- Zendesk-Migration, die wir lösen

Problem 1: Inaktive oder Standardmarken verursachen Fehlleitungen

Problem:

Inaktive Marken auf der Quellinstanz können standardmäßig einer ausgewählten Marke auf dem Zielsystem zugeordnet werden, wodurch Tickets möglicherweise markenübergreifend vermischt werden.

Lösung:

Help Desk Migration Service filtert und ordnet inaktive Marken gemäß Ihren Anforderungen zu, sodass Tickets ohne Verwechslungen bei der richtigen Marke landen.


Problem 2: Dropdown-Felder erzeugen unnötige Tags

Problem:

Dropdown-Felder in mehreren Ticketformularen können nach der Migration unerwünschte Tags erzeugen.

Lösung:

Passen Sie das Mapping an, um irrelevante Felder zu entfernen und optional die automatische Inhaltsverschlagwortung zu deaktivieren. wird die Anzahl der Schlagworte reduziert, während gleichzeitig wichtige Daten erhalten bleiben.


Problem 3: Archivierte Tickets werden in der Ansicht nicht angezeigt

Problem:

Archivierte Tickets sind zwar im System vorhanden, werden aber in der Standardansicht nicht angezeigt, was zu der Befürchtung führt, dass „Tickets verloren gegangen sind“

Lösung:

Alle archivierten Tickets werden in die Datenmigration einbezogen, und wir unterstützen Sie bei deren Bestätigung mittels ID-Suche oder Platzhaltern.


Problem 4: Diskrepanzen zwischen gelösten und geschlossenen Tickets

Problem:

Gelöste Tickets können nach 28 Tagen automatisch geschlossen werden , was sich auf die Statusverfolgung auswirkt.

Lösung:

Wir berücksichtigen das Automatisierungsverhalten Zendeskund ermöglichen die Zuordnung von Ticketstatus, sodass historische Datensätze korrekt bleiben, während Sie die Kontrolle über zukünftige Automatisierungen behalten.


Ausgabe 5: Zeitzonenunterschiede / UTC-Umrechnung

Problem:

Die API verwendet UTC; Ticket-Zeitstempel können nach der Migration um eine Stunde verschoben sein.

Lösung:

Unser Service übernimmt die Normalisierung der Zeitzonen und bietet eine Überprüfung nach der Migration, um sicherzustellen, dass die Zeitstempel mit den lokalen Einstellungen Ihres Teams übereinstimmen.


Problem 6: Einschränkungen von leichten Agenten

Problem:

Light-Agenten können keine geschlossenen Tickets besitzen oder öffentliche Kommentare abgeben, wodurch die Darstellung von Tickets in den Aufgaben eingeschränkt wird.

Lösung:

Wir ordnen Tickets und Kommentare von Lichtagenten im Voraus den entsprechenden Agenten zu, um Lücken in der Verantwortlichkeit zu vermeiden.


Problem 7: IP-Beschränkungen oder Verbindungsfehler

Problem:

Migrationstools können fehlschlagen, wenn Quell- oder Zielinstanzen Zendeskbestimmte IPs einschränken.

Lösung:

Wir unterstützen Sie bei der Einrichtung von IP-Whitelisting und der sicheren Konfiguration, um Ausfälle zu vermeiden.


Problem 8: Zendesk-Suchindex-Inkonsistenzen

Problem:

Die auf Suchanfragen basierenden Ticketzahlen stimmen möglicherweise nicht mit den tatsächlichen Ticketzahlen überein.

Lösung:

Help Desk Migration Wizard überprüft die Zählergebnisse anhand von API-Daten, und wir können Sie bei Bedarf auch bei der Neuindizierung unterstützen.


Ausgabe 9: Benutzerdefinierte Ticketstatus

Problem:

Es können nur benutzerdefinierte oder Standardstatus gleichzeitig zugeordnet werden.

Lösung:

Wir unterstützen den Kunden beim Deaktivieren benutzerdefinierter Status und beim erneuten Verbinden des Kontos, um eine korrekte der Ticketstatus .

Erfolgsgeschichten von Zendesk-zu- Zendesk-Migrationen

UrbanYou konnte nach der Kontozusammenlegung über 200.000 Tickets sichern

Industrie:

Haushaltsdienstleistungen

Ausgabe:

UrbanYou musste nach der Übernahme über 200.000 historische Tickets, Kontakte, Anhänge, Notizen und Wissensdatenbankinhalte von einem alten Zendesk-Konto in ein neu erstelltes Konto übertragen, aber die nativen Tools von Zendeskkonnten nicht genügend Details speichern.

So haben wir das Problem gelöst:

UrbanYou führte eine kostenlose Demo-Migration durch, um die Integrität der Tickets zu überprüfen, und führte anschließend eine vollständig automatisierte Migration durch, wobei Expertenunterstützung jeden Schritt begleitete.

Ergebnis:

Sämtlicher historischer Supportkontext, einschließlich Tickets, Anhänge und Notizen, wurde nahtlos migriert, sodass die Agenten ohne Unterbrechung sofortigen Zugriff auf die Kundenhistorie haben.


„Die Migration unserer Zendesk-Daten mit Help Desk Migration verlief absolut reibungslos.“

Noga Edelstein
Mitbegründer von UrbanYou

Noga Edelstein

Die Roland Corporation hat eine komplexe Instanzkonsolidierung für eine globale Supportplattform durchgeführt

Industrie:

Elektronik & Musikinstrumente

Ausgabe:

Roland musste Kundendienstdaten aus einer regionalen Zendesk-Instanz in eine zentrale globale Instanz konsolidieren, um die Supportabläufe zu vereinheitlichen. Diese Aufgabe umfasste Tickets, Kontakte, Unternehmen, Agenten und Gruppen.

So haben wir das Problem gelöst:

Help Desk Migration wurde eine Kombination aus automatisierten und kundenspezifischen Migrationsprozessen eingesetzt, wobei wichtige Entitäten sorgfältig abgebildet und die Workflow-Struktur über alle Konten hinweg erhalten blieb.

Ergebnis:

Eine anspruchsvolle Zendesk-zu- Zendesk-Konsolidierung wurde erfolgreich abgeschlossen, wobei alle kritischen Daten erhalten blieben und die Kontinuität des Supports gewährleistet wurde.


„Ehrlich gesagt war ich wirklich positiv überrascht, wie schnell das Unternehmen reagiert. Ich habe mich gefragt: Schlafen die überhaupt? Ich habe jedes Mal innerhalb weniger Stunden Antworten auf praktisch jede meiner Fragen erhalten, selbst unter Berücksichtigung der Zeitzonen.“

Paul McCabe,
Vizepräsident für globales Kundenerlebnis bei Roland Corporation

Paul McCabe

Ozonics LLC hat über Nacht eine Migration zu einem funktionsfähigen Zendeskdurchgeführt

Industrie:

Outdoor-/Konsumgüter

Ausgabe:

Ozonics LLC benötigte eine schnelle und zuverlässige Möglichkeit, ihre bestehende Support-Umgebung in Zendeskzu migrieren und sie bis zum nächsten Werktag vollständig betriebsbereit zu haben.

So haben wir das Problem gelöst:

Das Help Desk Migration Team begleitete sie durch eine Demo und die vollständige Migration, sodass Ozonics Zendeskvorkonfigurieren und die Übertragung über Nacht durchführen konnte.

Ergebnis:

Am Morgen war Zendeskmit allen historischen Daten voll funktionsfähig, wodurch Ausfallzeiten und manuelle Dateneingabe entfielen.


„Die Migration verlief planmäßig, wir haben keine Probleme mit den übertragenen Daten festgestellt.“

Stacey Hippen,
Betriebsleiterin bei Ozonics LLC

Stacey Hippen
Teamdiskussion zum Thema Migration

Migration des Hilfezentrums (Wissensdatenbank)

Help Desk Migration überträgt Artikel, Übersetzungen, Hierarchien, Anhänge und Metadaten zwischen ZendeskHelp Centern unter Berücksichtigung der Plattformbeschränkungen. Befolgen Sie die nachstehenden Richtlinien, um eine vollständige und fehlerfreie Migration zu gewährleisten.

Die Migration schlägt fehl, wenn dem API-Benutzer die erforderlichen Berechtigungen fehlen:
  • Für alle Inhalte des Hilfezentrums ist die Rolle eines Guide-Administrators erforderlich.
  • Zugriff auf alle Marken, die migriert werden.
  • Berechtigung zur Verwaltung von Sprachen und Gebietsschemas.
  • Zugriff auf archivierte oder Entwurfsartikel, falls diese migriert werden müssen.

  • Jede Marke muss separat über ihre jeweilige Marken-URL migriert werden.
  • Migrationen mit mehreren Marken werden unterstützt, aber einzeln verfolgt.
  • Wenn Artikel verschiedener Marken denselben Slug oder dieselbe ID haben, werden sie während der Migration umbenannt, um Konflikte zu vermeiden.

Regeln zur Vermeidung von Migrationsfehlern:
  • Die Standardsprache muss in Quell- und Zielsprache übereinstimmen.
  • Nur 1:1-Zuordnung von Gebietsschemas. Mehrere Quellgebietsschemas können nicht einem einzelnen Zielgebietsschema zugeordnet werden.
  • Gelöschte Gebietsschemas im Quellcode können weiterhin in der API vorhanden sein; deren Migration schlägt fehl.
  • Die Gebietsschemanamen Zendesk-Benutzeroberfläche können von den API-Codes abweichen (z. B. fr-fr → Französisch, fr → Französisch (Frankreich)). Überprüfen Sie dies unter Wissensverwaltung → Einstellungen → Spracheinstellungen.
  • Artikel ohne Standardsprache werden übersprungen, es sei denn, sie werden manuell oder über Migrationseinstellungen zugewiesen.
  • Bestimmte Orte können übersprungen werden, falls sie nicht benötigt werden.

  • Entwürfe und veröffentlichte Artikel: Migration erhält den Staat. Entwürfe bleiben Entwürfe; veröffentlichte Artikel bleiben veröffentlicht.
  • Archivierte Artikel: Können nicht migriert werden. Stellen Sie sie zuerst als Entwurf oder veröffentlichte Version wieder her.
  • Ordner & Abschnitte: Artikel ohne Ordner werden in einen Standardordner verschoben. Die Beschränkungen für Abschnitte/Kategorien und die maximale Verschachtelungstiefe bleiben erhalten, sollten aber überprüft werden, um unbemerkte Fehler zu vermeiden.
  • Sortierung und angeheftete Artikel: Die Reihenfolge bleibt nach Möglichkeit erhalten; benutzerdefinierte Positionen müssen möglicherweise nach der Migration angepasst werden.

  • Bilder, Dateien, Tags und Formatierungen werden unverändert übernommen.
  • Eingebettete Videos erfordern, dass unsichere Inhalte in Zendeskaktiviert werden.
  • Links innerhalb von Artikeln werden aktualisiert, wenn die Option „Crosslinks aktualisieren“ aktiviert ist; andernfalls müssen Weiterleitungen manuell konfiguriert werden.

  • Etiketten und Anhänger bleiben erhalten.
  • Benutzerdefinierte Artikelfelder müssen möglicherweise zugeordnet werden; nicht unterstützte Felder werden übersprungen.
  • Autorenangaben: Die ursprünglichen Autoren bleiben erhalten, sofern im Zielsystem Benutzer vorhanden sind; andernfalls wird bei der Migration der API-Benutzer zugewiesen.
  • Das Erstellungs- und Aktualisierungsdatum der Artikel wird, soweit möglich, beibehalten.

  • Update Crosslinks erhält interne Links.
  • Weiterleitungen sind erforderlich, wenn Querverweise deaktiviert sind.
  • Slugs werden automatisch umbenannt, falls Duplikate im Ziel-Hilfecenter vorhanden sind.

  • Die Migration ist idempotent, wenn dieselben Artikel erneut migriert werden: Aktualisierte Artikel überschreiben frühere Versionen.
  • Gelöschte Artikel oder entfernte Übersetzungen in der Quelldatei werden nicht automatisch auch aus dem Ziel entfernt.
  • Stellen Sie eine Liste der Artikel für die selektive Migration bereit. Falls es weniger als 20 Artikel sind, kann dies in einer Demo mit benutzerdefinierten Daten demonstriert werden.

  • Archivierte Artikel (zuerst als Entwurf oder veröffentlicht wiederherstellen).
  • Kanalfelddaten.
  • Spam-Tickets (Registerkarte „Gesperrt“).
  • Bestimmte nicht unterstützte benutzerdefinierte Felder.

  • Neu migrierte Inhalte benötigen möglicherweise einige Zeit, um in den Suchergebnissen angezeigt zu werden.
  • Verzögerungen bei der Indizierung sind normal und nach der Migration zu erwarten.
Was kann nicht migriert werden?
  • Archivierte Artikel: Auch benutzerdefinierte Artikel können nicht migriert werden. Um sie einzubinden, müssen Sie sie zunächst als Entwurf oder veröffentlichte Artikel wiederherstellen.
  • Daten im Kanalfeld: Zendesk erlaubt keine Migration in das Kanalfeld, daher können diese Informationen nicht in das Standardfeld verschoben werden.
  • Spam-Tickets: Tickets im Tab „Gesperrt“ werden nicht migriert.
Ihre Wissensdatenbank ist vollständig strukturiert, durchsuchbar und behält ihre historische Integrität, ohne dass Ihr Team Tausende von Artikeln manuell bearbeiten muss.
Alternativbanner Help Desk Migration

Raten Sie nicht. Validieren Sie Ihre Zendesk-zu- Zendesk-Migration ohne Ausfallzeiten

Zendesk -zu Zendesk -Migration:
Wichtige technische Details

Ja. Alle Tickets werden migriert, auch die von inaktiven Marken. Sie legen fest, welche Marken und Ticketarten einbezogen werden, sodass die Tickets der richtigen Marke oder Abteilung zugeordnet werden.

Zusammengeführte Tickets werden als einzelne Datensätze migriert, wobei der vollständige historische Kontext erhalten bleibt. Folgeaktionen können entweder im Hauptticket zusammengefasst oder in benutzerdefinierten Feldern erfasst werden, je nach Ihren Workflow-Anforderungen.

Nicht zugewiesene Tickets werden automatisch einem Standardbearbeiter zugewiesen. Dadurch wird sichergestellt, dass keine Tickets unbearbeitet bleiben und die Arbeitsabläufe ohne Unterbrechung fortgesetzt werden.

Dropdown-Felder aus mehreren Ticketformularen werden in Tags umgewandelt. Wir minimieren die unnötige Tag-Erstellung und erhalten gleichzeitig alle wichtigen Daten. Die automatische Tag-Erstellung kann bei Bedarf deaktiviert werden.

Ja. Anrufaufzeichnungen werden als MP3-Anhänge gespeichert, während alle eingebetteten Bilder, Videos und Dateien intakt migriert und in der Zielinstanz verwendbar sind.

Alle Makros, Trigger und deren Bedingungen werden migriert. Da das Überspringen von Aktionen zum Fehlschlagen von Triggern führen kann, überprüfen wir vor der Umstellung alles. Sie können nach Bedarf nach aktivem oder inaktivem Status, Kategorie oder Gruppe filtern.

Private Notizen, die von Nicht-Agenten, Anfragenden oder CCs erstellt wurden, werden einem Standardagenten neu zugewiesen. Der ursprüngliche Kontext bleibt erhalten, sodass nichts verloren geht.

Vermeiden Sie Überraschungen, Datenverlust und Ausfallzeiten. Jedes Ticket, jeder Benutzer, jedes Makro und jeder Wissensdatenbankartikel wird zuverlässig migriert. Demo-Migrationen ermöglichen Ihnen eine Vorschau der Ergebnisse, Sonderfälle werden automatisch behandelt und Ihre Arbeitsabläufe bleiben unterbrechungsfrei.

Ja. Jedes Tag, das einem Benutzer oder einer Organisation zugewiesen wird, wird automatisch neuen Tickets hinzugefügt, die für diese erstellt werden.

Zu den Standardrollen gehören Endbenutzer, Agent und Administrator. Mit dem Enterprise-Plan können Sie benutzerdefinierte Rollen erstellen, die den Bedürfnissen Ihres Teams entsprechen.

Dies bedeutet in der Regel, dass der Benutzer, der die Migration durchführt, keine Berechtigung für den Zugriff auf help_center/user_segments . Um dies zu beheben, weisen Sie dem Benutzer die Rolle „Help Center Manager“ zu.

Wissensdatenbankartikel können nur in Ordnern, nicht in Kategorien gespeichert werden. Wenn ein Artikel keinem Ordner im Quellsystem zugeordnet ist, wird er in einen vom Migrationstool erstellten Standardordner migriert.

Automatisierungen werden auf Basis zeitbasierter Ereignisse ausgeführt, während Trigger als Reaktion auf die Erstellung oder Aktualisierung von Tickets ausgeführt werden.

Ja. Tickets werden von allen Marken migriert, auch von deaktivierten. Das Feld „Marke“ wird in der Zuordnung angezeigt. Ist eine Marke inaktiv, erscheint sie nicht in der Zuordnung. Tickets dieser Marke werden der vom Kunden ausgewählten Standardmarke zugeordnet. Möchte ein Kunde nur bestimmte Marken migrieren, ist eine Filterung erforderlich. Im Ziel- Zendeskkönnen Tickets einer bestimmten Marke zugeordnet werden, indem diese in der Ticketzuordnung ausgewählt wird (das Feld „Marke“ wird in der Zuordnung angezeigt).

Ein Ticketformular ist eine Vorlage, die festlegt, welche Felder auf einem Ticket erscheinen, und die Tickets nach Abteilung oder Anfragetyp unterscheidet.
  • Formularzuordnung: Ticketformulare können zwischen Quelle und Ziel zugeordnet werden.
  • Dropdown-Felder: Werte aus Dropdown-Menüs anderer Formulare werden von Zendeskautomatisch als Tags hinzugefügt. Dieses Verhalten kann nicht verhindert werden.
  • Benutzerdefinierte Zuordnung: Nicht benötigte Felder können ausgeschlossen werden, um die Anzahl der Tags zu reduzieren.
  • Tags deaktivieren: Zendeskkann die automatische Tag-Vergabe deaktivieren; inhaltsbasierte Auto-Tags (Guide) können ebenfalls deaktiviert werden, Dropdown-Feld-Tags bleiben jedoch erhalten, sofern sie nicht aus der Zuordnung entfernt werden.

Zusammengeführte Tickets: Werden als separate Tickets migriert. Private Nachrichten, die die Zusammenführung kennzeichnen, werden ebenfalls als private Nachrichten migriert. Folgeaufträge: Werden als einzelnes Ticket migriert. Folgeaufträge mit IDs können optional in eine private Notiz oder ein benutzerdefiniertes Feld migriert werden.

Ja, archivierte Tickets werden standardmäßig migriert. In Zendeskgelten Tickets, die seit 90 Tagen den Status „Geschlossen“ haben, als archiviert.

Nicht zugewiesene Tickets im Ziel Zendeskwerden einem Standardagenten zugewiesen.
  • Tickets behalten nur dann den Status „Neu“, wenn sie nicht zugewiesen sind.
  • Wenn ein neues Ticket dem Standardagenten zugewiesen wird, ändert Zendeskautomatisch dessen Status auf „Offen“.
  • Daher ist der Status „Neu“ von der Migrationszuordnung zu Zendeskausgeschlossen.

Zendeskkönnen Sie benutzerdefinierte Ticketstatus erstellen, die über die Standardstatus (Neu, Offen, Ausstehend, In Bearbeitung, Gelöst, Geschlossen) hinausgehen.
  • Zuordnung: Für die Zuordnung werden entweder Standard- oder benutzerdefinierte Status angezeigt, niemals beide gleichzeitig.
  • Umstellung auf Standardstatus: Um Standardstatus zuzuordnen, deaktivieren Sie benutzerdefinierte Status in Ihrem Konto und stellen Sie die Verbindung erneut her.
  • Ticketverhalten: Tickets mit benutzerdefinierten Status werden als geschlossen behandelt – sie behalten alle Eigenschaften geschlossener Tickets (können nicht bearbeitet werden, bleiben in der Kategorie „Geschlossen“), auch wenn Automatisierungen vorhanden sind, aber ihr Statusname ändert sich nicht.

Ja. Organisationen können auf Wunsch ausgeschlossen werden, vorzugsweise ohne die Nutzer vorher zu informieren.

Ja. Kontakt-Tags (Benutzer- und Organisations-Tags) werden standardmäßig migriert. Alle Tags, die Benutzern oder Organisationen in der Quell Zendesk-Instanz zugeordnet sind, werden in die Zielinstanz übertragen und stehen weiterhin für Workflows, Trigger und Berichte zur Verfügung.

In Zendeskkann ein Ticket nicht zu einem anderen Unternehmen als dem des Anfragenden gehören. Wenn das Quellticket ein anderes Unternehmen als der Kontakt (oder gar kein Kontaktunternehmen) aufweist, können mehrere Unternehmen aus Tickets dem Kontakt zugeordnet und das korrekte Unternehmen im Ticket angezeigt werden.

Gesperrte Benutzer werden extrahiert und als nicht gesperrte Benutzer migriert, da gesperrte Benutzer keine Tickets erstellen können. Falls ein Benutzer auf dem Zielsystem bereits als gesperrt existiert, wird die Sperre aufgehoben und der Benutzer zugeordnet.

Zendesk -Benutzersegmente können nur über eine benutzerdefinierte Tag-Zuordnung für Benutzer und Organisationen migriert werden. Kunden müssen vor oder nach der Migration Benutzersegmente im Zielsystem für die zu migrierenden Kontakte erstellen. Bei der Migration von Artikeln werden Quell- und Zielbenutzersegmente zur Zuordnung angezeigt, funktionieren jedoch nur, wenn sie im Zielsystem korrekt konfiguriert sind.

Wenn ein Agent auf der Quelle zur Gruppe A und auf Zendeskzur Gruppe B gehört, wird der Agent gemäß der Zuordnung der Gruppe zugeordnet, die mit dem Ticket verknüpft ist.

Ja, Tickets können nur dann nach Empfängern (Support-E-Mails) gefiltert werden, wenn die Domain Zendeskist.

Trigger werden automatisch ausgeführt, sobald ihre Bedingungen erfüllt sind. Während der Migration:
  • Automatisierte Zuordnung: Alle Trigger wurden migriert.
  • Überprüfbare Details: Jeder Zustand und jede Aktion wird zur Überprüfung angezeigt.
  • Wichtig: Wird eine Aktion übersprungen, schlägt der Trigger nach der Migration fehl.

Bei der Migration werden Makros mit allen ihren Kernkomponenten übertragen und müssen vollständig zugeordnet werden, um auf dem Zielsystem Zendeskkorrekt zu funktionieren:
  • Verfügbar für — definiert, welche Rollen das Makro verwenden können.
  • Titel – der Name des Makros.
  • Body – der Inhalt oder die Anweisungen, die vom Makro angewendet werden.
  • Aktionen – alle Makroaktionen sind explizit zugeordnet. Wird eine Aktion übersprungen oder nicht zugeordnet, schlägt das Makro nach der Migration fehl.
Alle Makroaktionen, Bedingungen und Abhängigkeiten sind während der Mapping-Phase vollständig sichtbar, sodass Sie diese vor der Live-Schaltung überprüfen und anpassen können.

Ja. Sie können filtern nach:
  • Makros: Aktiv-/Inaktivstatus, Kategorie oder Gruppe. Standardmäßig werden alle Makros migriert.
  • Auslöser: Aktiv-/Inaktiv-Status oder Kategorie. Standardmäßig werden alle Auslöser migriert.
Elvira Azymova
AUTOR

Elvira Azymova

Vertriebsleiter

Elvira arbeitet seit 2018 in der Datenmigrationsbranche. Sie verfügt über fundierte Kenntnisse und Erfahrung in der Steuerung zentraler Vertriebs- und Serviceprozesse, darunter Leistungsmanagement, Nachfolgeplanung, Karriereentwicklung und die Vermittlung von Vergütungspaketen. Sie zeichnet sich durch ein gutes Gespür für Menschen, strategisches Denken, Neugier, analytisches Denken und eine hohe Handlungsorientierung aus.