Welchen Plan habe ich?

Bei Support Enterprise-Plänen verfügbar

Dieser Beitrag ist für Support Enterprise-Kunden vorgesehen, die für die Verwaltung mehrerer Marken derzeit eine Hub- und Spoke-Konfiguration verwenden und überlegen, auf Multibrand umzusteigen.

Dieser Beitrag enthält die folgenden Abschnitte:
  • Voraussetzungen für die Migration zu Multibrand
  • H&S und Multibrand im Vergleich
  • Überblick über die Schritte und Einschränkungen der Migration

Voraussetzungen für die Migration zu Multibrand

Wenn Sie darüber nachdenken oder sogar planen, von Hub & Spoke (H&S) auf Multibrand (MB) umzusteigen, lesen Sie bitte diese Hinweise zu den Hindernissen, die einer vollständigen Migration Ihres Kontos zu Multibrand entgegenstehen.

Fragen Sie sich vorab, ob Sie wirklich alle Ihre Spokes verwenden.  Wir haben Kunden, die H&S eingerichtet haben, aber nur den Hub nutzen.  Wenn Ihre Spokes nicht verwendet werden oder keine Tickets mit dem Hub teilen, ist wahrscheinlich keine Migration erforderlich. 

  • Help-Center-Communitys – Sie können Ihre Community-Inhalte mit der Help Center-API migrieren. Weitere Informationen finden Sie in den Themen und Posts in unserer Entwicklerdokumentation.
  • Multibrand oder Hub & Spoke – In einem H&S-Setup kann keine Multibrand-Instanz eingerichtet werden.  Die beiden Produkte schließen sich gegenseitig aus.

Wenn Sie mit den oben genannten Voraussetzungen vertraut sind und mehr über die Migration zu Multibrand wissen möchten, lesen Sie den Beitrag Schritte zur Multibrand-Migration. 

H&S und Multibrand im Vergleich

In diesem Abschnitt wird beschrieben, wie sich das Verhalten eines H&S-Setups nach der Migration zu Multibrand ändern kann.  Wir beabsichtigen, das Multibrand-Verhalten in Bezug auf einige der unten stehenden Punkte zu ändern, haben aber noch keinen konkreten Zeitplan dafür aufgestellt. 

  • Remote-Authentifizierung/Single-Sign-On – Alle Help Center leiten Benutzer zum selben Single-Sign-On-Protokoll und zur selben Datenbank um. Das liegt daran, dass Benutzer einem Konto und nicht einer Marke zugeordnet sind.

  • Zopim-Channel-Branding – Bei per Zopim erstellten Tickets wird das Markenattribut derzeit nicht berücksichtigt. Auch dieses Problem soll mit einer zukünftigen Version behoben werden.  In der Zwischenzeit können Sie das Zopim Multibrand-Setup durch Implementieren eines Teils der Vorschläge verbessern. 

  • Agentensignaturen – Es ist nur eine Signatur pro Agent verfügbar.  Die Agenten können persönliche Makros nutzen, um für jede Marke eine eigene Agentensignatur zu erstellen.

  • Endbenutzer-Markenidentitäten – Derzeit gibt es keine Möglichkeit, Endbenutzer für Kundenlisten nach Markenidentitäten zu segmentieren, da wir nicht nachverfolgen können, welche Ihrer Benutzer mit welchen Ihrer Marken interagiert haben.

  • Agentenberechtigungen – Standardmäßig haben alle Agenten Zugriff auf alle Marken. Sie können Markenansichten für Agenten erstellen. Wenn Sie den Zugriff von Agenten einschränken möchten, weisen Sie Tickets bestimmter Marken mithilfe von Auslösern bestimmten Gruppen zu und schränken Sie die Ticketberechtigungen der Agenten in diesen Gruppen ein.

  • Endbenutzerberechtigungen – Es ist nicht möglich, bestimmte Help Center für einen Teil Ihrer Endbenutzer auszublenden. Dies ist so beabsichtigt; wir arbeiten aber an einer Möglichkeit, segmentierte und privilegierte Dienste auf Grundlage des Benutzertyps zu unterstützen.  Es ist jedoch möglich, den Zugriff auf Inhalte, Benutzerportale und Communities mithilfe von Zendesk-Benutzerstichwörtern und JavaScript zu verhindern.

  • Vorlagen für einzelne E-Mails – Bei der Einführung können Sie nur eine HTML-Vorlage pro Konto erstellen. Wir beabsichtigen, diese Einschränkung in einer zukünftigen Version zu beheben. Bis dahin können Sie eine geteilte HTML-Vorlage erstellen und Makros verwenden, um den Text der Antworten an die jeweilige Marke anzupassen.

  • Ticketformulare – Sie können den Zugriff auf bestimmte Ticketformulare nach Marke beschränken (siehe Erstellen und Anwenden markenspezifischer Ticketformulare). Auf diese Weise können Sie die für Endbenutzer und Agenten verfügbaren Ticketformulare basierend auf der Marke des jeweiligen Help Centers oder Tickets steuern.

  • Integrationen – Wir arbeiten daran, dass der Markenwert in unseren wichtigsten Integrationen (einschließlich Jira und SFDC) berücksichtigt wird. Alle anderen Apps müssen von ihren Inhabern aktualisiert werden.

  • Kennwort zurücksetzen – Wenn ein Endbenutzer ein Kennwort über ein Markenportal zurücksetzen lässt, wird es für alle Marken gleichzeitig zurückgesetzt.  Das Zurücksetzen des Kennworts lässt sich nicht anpassen. Es wird aber eine Liste aller zugehörigen Help Center angezeigt, aus der der Endbenutzer ersehen kann, wo sein Kennwort aktualisiert wurde.

Überblick über die Schritte und Einschränkungen der Migration

Die Schlüsselelemente der Multibrand-Migration sind:

  • Schritte und Zeitablauf

  • Einschränkungen

Typische Schritte und Zeitablauf

  1. Sie konfigurieren Ihre MB-Instanz („Einstellung“, „Kanäle“, „Marken“, Agentenrollen …).
  2. Zendesk migriert ein Muster der Inhalte (Tickets und Help-Center-Beiträge).
  3. Sie vergewissern sich, dass die Inhaltsmuster wie erwartet migriert wurden.
  4. Zendesk migriert alle Inhalte mit Ausnahme noch nicht geschlossener (also in Bearbeitung befindlicher) Tickets.
  5. Sie konfigurieren Ihren Workflow in Ihrer Multibrand-Instanz (Makros, Auslöser, Automatisierungen und Ansichten).
  6. Sie bereiten den abschließenden Migrationsschritt vor, indem Sie Ihre Kunden über die bevorstehende Ausfallzeit informieren (durch Nachrichten im Help Center der Spoke-Instanzen und gegebenenfalls eine Warnung per E-Mail).
  7. Während der Ausfallzeit: Zendesk migriert die verbleibenden Tickets, Sie stellen die Subdomänen um (von Spoke auf Multibrand) und richten das Host-Mapping für jede Marke ein.
Hinweis: Die Dauer der Ausfallzeit hängt direkt von der Anzahl der noch nicht geschlossenen Tickets in jeder Spoke-Instanz ab.  In der Regel können wir 35.000 Tickets pro Stunde migrieren.  Wenn eine Ausfallzeit nicht infrage kommt, können wir die Migration zu Multibrand auch ohne Ausfallzeit durchführen. In diesem Fall müssen Sie aber Ihre Support-E-Mail-Adressen und die URL Ihres Help Centers ändern.

Der zeitliche Ablauf hängt davon ab, welche Zendesk-Ressourcen für diesen Prozess zur Verfügung stehen, wie komplex die Migration Ihres Programms ist und wie schnell Sie Ihre Aufgaben im Rahmen der Migration erledigen.  Wann Ihre Migration abgeschlossen sein wird, können wir erst sagen, wenn wir Ihren Migrationsbedarf erfasst und bewertet haben.

Derzeitige Einschränkungen der Migration
  • Tickets
    • Wir migrieren alle Kommentare, Anhänge und Metadaten (d. h. die aktuellen Werte aller Ticketfelder und Stichwörter).
    • Wir können keine Ereignisse migrieren (d. h. Stichwort „xyz“ wurde von Auslöser 123 am 12. Dezember 2014 hinzugefügt).
    • Die Ticket-ID kann nicht migriert werden, da in der Multibrand-Instanz neue Tickets erstellt werden.
  • Help-Center-Inhalt
    • Wir migrieren Beiträge (und Anhänge). Alle migrierten Beiträge weisen denselben Autor auf (den Kontoinhaber oder eine von Ihnen benannte Person).
    • Das Erstelldatum der Beiträge sowie Kommentare und Abonnements sind nicht verfügbar.  Dasselbe gilt für Abschnittseinstellungen und Community-Inhalte.
    • Vorlagen (d. h. an Ihrem Help Center vorgenommene Anpassungen) können nicht migriert werden.
    • Kategorie- oder Abschnittseinstellungen können nicht migriert werden. Sie müssen sie nach der Migration zurücksetzen.
    • Kategorie-, Abschnitts- und Beitrags-IDs werden bei der Migration geändert. Alle bisherigen externen Links müssen aktualisiert werden.
  • Benutzerinformationen
    • Endbenutzer, Agenten, Gruppen und Organisationen können migriert werden (dies gilt nicht für angepasste Felder, Benutzernotizen und Details zu den oben genannten Informationen).
    • Kennwörter der Endbenutzer können nicht migriert werden.  Wenn sich Ihre Kunden direkt bei Zendesk anmelden (d. h. in Zendesk ein Authentifizierungsprofil haben), müssen sie ihr Kennwort nach Abschluss der Migration zurücksetzen.
    • Agentenrollen werden nicht migriert.
    • Organisation, Sprache, Zeitzone, Details/Notizen und angepasste Felder in den Profilen werden nicht migriert.
  • Workflow
    • Makros können migriert werden.

    • Ihre Ansichten, Auslöser und Automatisierungen können wir nicht migrieren. (Das wäre auch nicht sinnvoll, da Sie alle Ansichten, Auslöser und Automatisierungen überprüfen und für die neu erstellte Marke anpassen müssen.)

    • Dynamische Inhalte sind für die Migration nicht verfügbar.

  • Andere
    • Zufriedenheitsbewertungen: nicht verfügbar.
    • Die Migration von „Einstellungen“ und „Kanälen“ ist nicht möglich (und wäre angesichts der zusätzlichen Marken wenig sinnvoll).
    • Über Lesezeichen zu Beiträgen gelangen Benutzer zur Homepage (also nicht zu dem betreffenden Beitrag) des markenspezifischen Help Centers.
    • Wir arbeiten daran, dass der Markenwert in unseren wichtigsten Integrationen (einschließlich Jira und SFDC) berücksichtigt wird. Alle anderen Apps müssen von ihren Inhabern aktualisiert werden.
Powered by Zendesk