Viele Unternehmen bestehen aus mehreren Organisationen mit unterschiedlichen Prozessen, Sicherheitsanforderungen und Workflows. Sie sollten sich überlegen, ob eine einzige Zendesk-Instanz für Ihre Situation ausreicht oder ob mehrere Instanzen besser wären. In diesem Beitrag werden die Vorteile, Überlegungen und Konsequenzen für die beiden Szenarien gegenübergestellt. Behandelte Themen:

  • Funktionsspezifische Überlegungen
  • Berechtigungsspezifische Fragen
  • Überblick

Funktionsspezifische Überlegungen

Wenn Sie planen eine einzige Zendesk-Instanz für mehrere Teams zu verwenden, sollten Sie die folgenden funktionsspezifischen Überlegungen berücksichtigen: 

  • Globale Einstellungen
  • Business-Regeln
  • Integrationen
  • Authentifizierung und Zugriff
  • Endbenutzerverwaltung
  • Agentenberechtigungen und Ticketzugriff
  • Berichte
  • Web Widget (Classic) und Chat-Widget
  • Guide

Globale Einstellungen

Dieser Abschnitt geht auf die Überlegungen für globale Einstellungen ein. 

  • Abonnement
    Wenn Sie eine einzige Zendesk-Instanz haben, verwenden alle Agenten den gleichen Plan für Zendesk Support, Guide, Talk und Chat. Wenn Sie mit Guide arbeiten, müssen alle Support-Agenten auch Guide-Agenten sein. Wenn aber nur ein einziges Team Guide braucht, ist dies ein Kostenfaktor, den Sie berücksichtigen sollten.

  • Agentensignaturen
    Nativ gibt es nur eine einzige globale Agentensignatur pro Zendesk-Instanz. Als Workaround können Sie die Auslöser für jedes Team ändern und die Signatur im Auslöser bzw. in Liquid Markup-Bedingungen definieren.
  • E-Mail-Vorlage
    Nativ gibt es nur eine einzige E-Mail-Vorlage pro Zendesk-Instanz. Als Workaround können Sie alle Business-Regeln anpassen. In Business-Regeln werden HTML, CSS und Liquid Markup unterstützt. Weitere Informationen finden Sie unter Überblick über die Verwendung von Liquid Markup in Zendesk Support.

  • Willkommens-/Bestätigungs-E-Mails
    Nativ gibt es nur eine einzige Willkommens-/Bestätigungs-E-Mail für Endbenutzer. Sie verwendet den unter „Einstellungen“ > „Konto“ angegebenen Domänennamen.

  • Subdomäne
    Alle Agenten verwenden dieselbe Subdomäne. Es ist nicht möglich, den Subdomänennamen zu ändern, z. B. in einen Teamnamen.

  • Können alle Anfragen einreichen?
    Eine Zendesk-Instanz ist entweder für alle Benutzer geöffnet oder für alle Benutzer geschlossen. Wenn die Zendesk-Instanz offen ist, kann jeder Benutzer Anfragen einreichen, sich bei Guide anmelden und Tickets über das Widget einreichen. Wenn die Zendesk-Instanz geschlossen ist, muss ein Endbenutzer ein vorhandener Benutzer in Zendesk Support sein, um Anfragen einreichen oder auf Guide zugreifen zu können. Weitere Informationen finden Sie unter Festlegen, wie Endbenutzer auf Zendesk Support zugreifen und sich anmelden.

  • Kontoname
    • Es gibt nur einen einzigen Kontonamen. Weitere Informationen finden Sie unter How do I change my account name in Zendesk Support? (Englisch).
    • Der Kontoname erscheint in E-Mails, wenn Sie  formatierte Platzhalter verwenden. Er ist in Teil der gesendeten E-Mail und für Endbenutzer sichtbar. Um dies zu verhindern, müssen Sie statt formatierten Platzhaltern Rich-Content-Platzhalter verwenden, die Rich-Text unterstützen. Dadurch geht jedoch das schönere Aussehen von formatierten Platzhaltern verloren.
    • Der Kontoname erscheint auch auf der Anmeldeseite und kann nicht bearbeitet werden.
  • Benutzer können mehreren Organisationen angehören
    Wenn Sie für alle Teams eine einzige Zendesk-Instanz verwenden, wird diese globale Einstellung für die gesamte Instanz entweder aktiviert oder deaktiviert.

  • Zufriedenheitsumfrage
    Zufriedenheitsumfragen werden zwar für die gesamte Support-Instanz aktiviert oder deaktiviert, aber Sie können Business-Regeln so anpassen, dass sie für bestimmte Gruppen nicht ausgeführt werden. Anhand von Platzhaltern kann für jedes Ticket ein Zufriedenheitslink generiert werden. Weitere Informationen finden Sie unter Verwenden von Platzhaltern für die Kundenzufriedenheitsbewertung.

  • Datenexport
    Ticket-, Benutzer- und Organisationsdaten werden für das gesamte Konto exportiert. Mit der Core-API von Zendesk können Sie spezifischere Daten abrufen.

  • Stichwörter
    Wenn eine einzige Instanz von mehreren Teams genutzt wird, sollten Stichwörter nicht in mehreren Workflows oder für mehrere Ressourcen verwendet werden.

Business-Regeln

Dieser Abschnitt geht auf die Überlegungen für Business-Regeln ein.

  • Auslöser, Automatisierungen, Ansichten und SLAs
    • Business-Regeln werden für alle Tickets ausgeführt, können aber mithilfe von Bedingungen mühelos auf bestimmte Gruppen oder Marken eingegrenzt werden. Weitere Informationen finden Sie unter Verwenden von Gruppen in Business-Regeln. Administratoren haben globale Berechtigungen und können Regeln für alle Gruppen erstellen – nicht nur für die Gruppen, denen sie angehören. Es besteht also die Gefahr, dass der Administrator für ein Team Regeländerungen vornimmt, die sich auf die Tickets und Workflows eines anderen Teams auswirken. 
    • Wenn mehrere Teams dieselbe Zendesk-Instanz verwenden, steigt die Anzahl von Regeln schnell an. Um die daraus resultierende Komplexität effektiv zu bewältigen, ist eine Strategie für Change-Management und teamübergreifende Zusammenarbeit erforderlich. Dadurch erhöht sich auch das Risiko, dass Tickets an die falschen Gruppen weitergeleitet werden, was wiederum negative Auswirkungen auf SLAs haben kann.
    • Sie sollten sich auch überlegen, wie Sie mit vertraulichen oder sensiblen Informationen umgehen, die für Agenten sichtbar sind – und wer keinen Zugriff darauf haben sollte. Es gibt keine native Methode, Business-Regeln nach Gruppe zu organisieren.
    • Um Business-Regeln zu organisieren und zu gruppieren, können Sie Auslöser und Automatisierungen erstellen, deren einzige Funktion darin besteht, anhand eines Namens die Kategorisierung von Regeln nach Team zu ermöglichen.

  • Makros
    Der Zugriff auf Makros kann allen Agenten gewährt werden oder nur Agenten in bestimmten Gruppen. Weitere Informationen finden Sie unter Erstellen persönlicher Makros für Tickets.

  • Ticketfelder und Ticketformulare
    • Ticketfelder und Ticketformulare gelten global für die gesamte Instanz und sind für alle Teams sichtbar. Wenn für bestimmte Teams oder Endbenutzer eigene Formulare verwendet werden sollen, müssen Sie angepasste Ticketformulare erstellen.
    • In der Agentenoberfläche können bestimmte Felder durch eine App ein- und ausgeblendet werden, und zwar je nach dem Agenten, der das Ticket öffnet. Sie können auch das in diesem Beitrag zum Beschränken von Ticketformularen beschriebene Rezept implementieren.
    • Durch Anpassung des Help-Center-Codes können bearbeitbare Felder, die nicht erforderlich sind, im Anfrageformular für Endbenutzer ausgeblendet werden.

Integrationen

Dieser Abschnitt geht auf die Überlegungen für Integrationen ein.

  • Jira
    Version 3 der Zendesk-Jira-Integration basiert auf einem 1:1-Modell, d. h., Sie können nicht mehrere JIRA-Integrationen mit einem einzelnen Zendesk Support-Konto verknüpfen.

  • Angepasste Integrationen
    Wenn Sie mehrere Support-Instanzen haben, muss jede angepasste Integration separat eingerichtet und konfiguriert werden. Um beispielsweise Datenexporte durchzuführen oder eine Verbindung zu einer Benutzerdatenbank herzustellen, sind bei jeder Support-Instanz auf beiden Seiten Entwicklungs- und Konfigurationsmaßnahmen erforderlich.

  • Apps (ZAF)
    Apps müssen in jeder Support-Instanz installiert und konfiguriert werden. Wenn die nativen Optionen nicht granular genug sind für Ihre Anforderungen, können Sie eine eigene App codieren, die die App ausgehend von der Benutzergruppe ein- oder ausblendet. Es ist nativ möglich, den Zugriff auf eine App für jede Gruppe oder angepasste Rolle getrennt festzulegen. Weitere Informationen finden Sie unter Beschränken der Sichtbarkeit einer App nach Gruppe.

Authentifizierung und Zugriff

Dieser Abschnitt geht auf die Überlegungen im Bezug auf Authentifizierung und Zugriff ein.

  • Standardauthentifizierung
    Wenn Sie mehrere Zendesk-Instanzen verwenden, hat jede separate Logins (Benutzernamen und Kennwörter). Für jede Zendesk-Instanz, die die native Zendesk-Authentifizierung nutzt, muss sich jeder Agent und Endbenutzer einen eigenen Login merken.

  • API-Zugriff
    API-Token gelten global, d. h. jeder Benutzer mit einem API-Token kann auf alle Ressourcen und Daten im Konto zugreifen.

  • OAuth
    Der Gültigkeitsbereich von OAuth-Token kann so eingegrenzt werden, dass nur der Zugriff auf bestimmte Ressourcen möglich ist. Es ist aber nicht möglich, den Gültigkeitsbereich auf Agentengruppen zu beschränken.

  • Single-Sign-On (SSO)
    • Der native SSO gilt für die gesamte Instanz (sowohl Agenten- als auch Endbenutzerkonfigurationen). Agenten und Endbenutzer der einzelnen Teams müssen beim SSO Identity Provider konfiguriert werden.
    • Es gibt Workarounds, wenn Benutzer die Möglichkeit haben sollen, zwischen unterschiedlichen Authentifizierungsmethoden (Zendesk-Authentifizierung und SSO) zu wählen, aber dieses Funktionsmerkmal muss vom Kunden implementiert werden. Weitere Informationen finden Sie unter Auswählen der besten Authentifizierungsoption für mein Konto.

Endbenutzerverwaltung

Dieser Abschnitt geht auf die Überlegungen im Bezug auf die Benutzerverwaltung ein.

  • Organisations- und Benutzerfelder
    Organisations- und Benutzerfelder gelten global für die gesamte Instanz, d. h., alle Agenten können sie sehen und möglicherweise bearbeiten. Wie Ticketfelder können auch Organisations-/Benutzerfelder durch eine angepasste App ein- und ausblendet werden, und zwar abhängig vom Agenten, der das Ticket öffnet.

  • Organisationsverwaltung
    • Organisationen gelten global für die gesamte Instanz. Es ist nicht möglich, Organisationen oder Anzeigeberechtigungen für Organisationen nach Agentengruppe zu segmentieren.
    • Was das Teilen von Organisationstickets betrifft, so gelten die Zugriffsberechtigungen global für alle Tickets in einer Organisation. Wenn diese Option aktiviert ist, wirkt sie sich auf die Tickets aller Teams aus, die mit Support und Guide arbeiten.
    • Organisationsnamen müssen eindeutig sein. Benutzer können zwar mehreren Organisationen angehören, aber es kann nicht mehrere Organisationen mit dem gleichen Namen geben, auch wenn diese von unterschiedlichen Teams verwendet werden sollen.

  • Endbenutzerberechtigungen und -zugriff
    • Alle Endbenutzer gelten global über die gesamte Instanz hinweg. Es ist nicht möglich, einem Endbenutzer die Berechtigung zu geben, Anfragen nur bei einem bestimmten Team in einer Zendesk-Instanz einzureichen, aber nicht bei einem anderen Team.
    • Nur eine primäre Methode zur Authentifizierung von Endbenutzern wird nativ unterstützt. Endbenutzer können sich bei allen Help-Center-Instanzen anmelden. Es gibt zwar Workflows, um dieses Verhalten zu umgehen, aber diese erfordern einigen Entwicklungsaufwand auf Kundenseite. 

Agentenberechtigungen und Ticketzugriff

  • Agentenberechtigungen zum Bearbeiten von Endbenutzern
    Je nach Plan gibt es unterschiedliche Überlegungen:
    • Angepasste Agentenrollen: Wenn Ihr Plan angepasste Rollen enthält, können Sie einer bestimmten Agentengruppe die Bearbeitung von Benutzerprofilen gestatten, andere Gruppen aber nicht. Agenten können das Profil aller Endbenutzer sehen. Es gibt Randfälle, in denen ein Agent keinen Zugriff auf ein Ticket in einer anderen Gruppe hat, aber Endbenutzer bearbeiten kann. In diesem Fall hat der Agent auch die Möglichkeit, die Identität eines Endbenutzers anzunehmen, und kann so ALLE vom Endbenutzer eingereichten Tickets sehen.
    • Agentenrolle: Bei Plänen ohne angepasste Agentenrollen können nur Agenten mit Zugriff auf alle Tickets Endbenutzer hinzufügen, bearbeiten und ihre Identität annehmen.
    • Spezielle Anwendungsfälle, in denen Agenten in einem bestimmten Team als Endbenutzer in einem anderem Team gelten: Da Agenten keine Tickets über das Help Center einreichen können, können sie auch keine Endbenutzerformulare verwenden. Unabhängig von den Gruppenberechtigungen haben Agenten Zugriff auf alle Tickets, bei denen sie der Anfragende sind. Dies bedeutet, dass sie auf die für den Anfragenden bestimmte interne Kommunikation zugreifen können.

  • Gruppenmanagement und Ticketzugriff
    • Gruppen gelten global für die gesamte Instanz. Es ist möglich, Gruppen zu erstellen, um mehrere Teams zu verwalten und den Zugriff auf Tickets nach Gruppen einzuschränken.
    • Bei Enterprise-Plänen können Sie private Ticketgruppen erstellen. Private Ticketgruppen bieten detailliertere Kontrolle über die Sichtbarkeit und den Zugriff auf Tickets auf Grundlage der Gruppenzuweisung. Agenten, die keine Ansichtsberechtigung haben, sehen private Tickets auch nicht.
    • Bei Enterprise-Plänen können Sie außerdem angepasste Agentenrollen verwenden, um den Zugriff von Agenten auf private Ticketgruppen zu steuern. Dazu gehört auch die Möglichkeit, Tickets privaten Gruppen zuzuweisen.

Berichte

Dieser Abschnitt geht auf die Überlegungen für Berichte ein.

  • Berichte
    • Bei Verwendung einer einzigen Zendesk-Instanz sind alle Berichte an einem zentralen Ort konsolidiert. Alle Benutzer, die Zugriff auf Berichte haben, haben auch Zugriff auf alle Ticket-, Benutzer- und Organisationsdaten.
    • Bei anderen Plänen richtet sich der Zugriff auf Berichte nach dem Ticketzugriff. Agenten können Berichte nur sehen, wenn sie auf alle Tickets zugreifen können.
    • Die vordefinierten Berichte-Dashboards beziehen sich global auf alle Support-Daten. Wenn also Berichte nach Gruppe oder nach einem anderen Attribut auf Ticketebene (angepasstes Ticketfeld, Ticketmarke usw.) erstellt werden sollen, sind angepasste Berichte erforderlich.

  • Native Berichte
    Die in Zendesk Support (nicht in Explore) angezeigten nativen Registerkarten „Übersicht“, „Leaderboard“, „Wissensdatenbank“, „Community“, „Suchen“ und „Talk“ beziehen sich global auf die gesamte Instanz.

Web Widget (Classic) und Chat-Widget

Dieser Abschnitt geht auf die Überlegungen im Bezug auf das Web Widget (Classic) und das Chat-Widget ein. Sie treffen nicht unbedingt auf das Messaging Web Widget zu.

  • Nativ unterstützte Anpassungen und das Erscheinungsbild (Farbe, Position, Schaltflächentext) gelten global. Mit der Widget-API ist es zwar möglich, das Widget teamspezifisch anzupassen, aber dafür ist Entwicklungsaufwand auf Kundenseite erforderlich.
  • Wenn für jedes Team andere Ticketfelder erscheinen sollen, müssen Ticketformulare verwendet werden.
  • Die Help-Center-Suchfunktion im Widget durchsucht die gesamte Wissensdatenbank (es gibt nur eine). Mit etwas Entwicklungsarbeit ist es theoretisch möglich, die Suchergebnisse anzupassen.
  • Die Chatfunktion im Widget ist entweder für alle Teams aktiviert oder für alle Teams deaktiviert; dies muss berücksichtigt werden, wenn nur ein einziges Team mit Chat arbeitet. Durch Anpassungen über die Widget-API und  Chat-API lässt sich diese Einstellung aufheben.

Guide

Dieser Abschnitt geht auf die Überlegungen für Zendesk Guide ein.

  • Berechtigungen für Agenten
    • Wenn mehrere Teams mit einer einzigen Instanz von Zendesk Guide arbeiten, ist eine Kollaborationsstrategie erforderlich. Agenten in einem Team, die Guide-Manager sind, können beispielsweise Inhalte für andere Teams verwalten und Designs bearbeiten, auch wenn Sie Multibrand verwenden.
    • Die Berechtigungen zum Erstellen und Bearbeiten von Beiträgen sind eine Mischung aus Einstellungen in Zendesk Support und Einstellungen auf Abschnittsebene in Zendesk Guide. Standardmäßig sind alle Zendesk Support-Administratoren auch Guide-Manager.
    • Bei einem Plan mit angepassten Rollen können Sie eine angepasste Rolle erstellen und ihr die Guide-Manager-Berichtigung zuweisen. Bei den anderen Plänen können Sie die Berechtigung (Guide-Manager oder Guide-Betrachter) auf der Profilseite des Agenten festlegen. Weitere Informationen finden Sie unter Überblick über die Benutzerrollen in Guide und Festlegen von Berechtigungen.
    • Agenten können zwar in Zendesk Support als Guide-Betrachter definiert sein, aber in Guide dennoch die Möglichkeit haben, Beiträge in allen Abschnitten zu erstellen und zu bearbeiten, für die die Berechtigungsgruppe „Agenten und Manager“ ausgewählt ist.
  • Endbenutzererlebnis
    • Bei Verwendung einer einzigen Zendesk-Instanz können sich alle Endbenutzer bei allen Help Centern anmelden. Wenn mehrere Teams eine einzige Zendesk Support-Instanz für Tickets verwenden und es Endbenutzer gibt, die mit allen diesen Teams zu tun haben, melden sich diese Endbenutzer für alle Teams jeweils mit dem gleichen Login an (bei Verwendung separater Support-Instanzen wäre das anders).
    • Wenn es nur eine einzige Support-Instanz gibt, sehen Endbenutzer alle ihre Tickets an einem Ort. Dies gilt aber nicht, wenn sie Tickets für unterschiedliche Marken eingereicht haben.
    • Um zu bestimmen, wer welche Inhalte in allen mit einer einzigen Support-Instanz verknüpften Help Centern sehen kann, sind Benutzersegmente und eine Berechtigungsstrategie erforderlich.
    • Wenn Agenten in einem bestimmten Team gleichzeitig auch Endbenutzer in einem anderen Team sind, ergibt sich für sie kein nahtloses Help-Center-Erlebnis, da sie zum Einreichen und Anzeigen von Anfragen zu Zendesk Support umgeleitet werden.

Berechtigungsspezifische Fragen

Bevor Sie eine endgültige Entscheidung treffen, sollten Sie die folgenden berechtigungsspezifischen Fragen beantworten:

Sollen alle Agenten Zugriff auf alle Tickets haben?

Wenn mehrere Teams eine einzige Support-Instanz verwenden, berücksichtigen Sie die folgenden Überlegungen, bevor Sie entscheiden, ob Agenten auf alle Tickets zugreifen sollen oder nicht.

Zugriff auf alle Tickets zulassen:

  • Wenn Agenten Zugriff auf alle Tickets haben, wie komplex/skalierbar wäre es, anhand von Business-Regeln (Ansichten, Auslösern, Automatisierungen, SLAs, E-Mail-Vorlagen) für jedes Team einen eigenen Ticketweiterleitungspfad einzurichten, da Business-Regeln global für die gesamte Instanz gelten? 
  • Wenn beispielsweise zwei Teams (Support und Vertrieb) eine Zendesk-Instanz gemeinsam verwenden, sind für jedes Team ein Weiterleitungsauslöser sowie separate Auslöser für jede automatische Antwort/Kommentaraktualisierung erforderlich, um das Endbenutzererlebnis teamspezifisch anzupassen.
  • Es ergibt sich ein höheres Risiko, dass ein Ticket falsch weitergeleitet wird, was die SLAs anbetrifft.

Zugriff auf alle Tickets beschränken:

  • Um den Zugriff zu beschränken, müssen Gruppen oder angepasste Rollen eingerichtet werden.
  • Die Weiterleitung von Tickets muss sorgfältig gemanagt werden, damit Tickets nicht versehentlich an eine Gruppe weitergeleitet werden, die das Ticket nicht sehen sollte.
  • Agenten haben nur begrenzt Einblick in andere frühere oder aktuelle Anfragen. Zusammen mit dem Ticketzugriff wird möglicherweise auch der Zugriff auf Berichte beschränkt.
  • Wenn Agenten mit eingeschränkten Rechten die Identität von Endbenutzern annehmen können, haben sie möglicherweise über den Bereich Meine Aktivitäten im Help Center Zugriff auf Tickets außerhalb ihrer Gruppe. Dies hängt von der jeweiligen Konfiguration ab.

Gibt es eine zentrale oder existierende Strategie zur Benutzerverwaltung?

Punkte, die für Agenten und Endbenutzer berücksichtigt werden sollten:

  • Zendesk-Authentifizierung: Benutzer, die in beiden Instanzen Agenten sind, haben zwei verschiedene Logins.
  • Wenn SSO verwendet wird, muss Zendesk für beide Instanzen als Service Provider konfiguriert werden. Wenn Sie angepasste Benutzerdaten übertragen, müssen Sie in beiden Instanzen Benutzer- bzw. Organisationsfelder erstellen. Alle angepassten Benutzerfelder, Organisationen und Rollen haben eine eindeutige ID und erfordern die Einrichtung eindeutiger Assertions für SAML/JWT.

Zusätzliche Überlegungen für Endbenutzer:

  • Sollen Endbenutzer Zugriff auf die Help-Center-Inhalte beider Teams haben (wenn z. B. HR und Support die gleiche Instanz verwenden)?
  • Sollen Endbenutzer Zugriff auf alle Inhalte für HR und Support haben?  

Überblick

Abschließend eine kurze Zusammenfassung der Vorteile und Überlegungen für die beiden Szenarien (eine einzige Instanz oder mehrere Instanzen):

Vorteile bei Verwendung einer einzigen Zendesk Support-Instanz:

  • Nahtloses Benutzererlebnis.
  • Nahtloses Reporting.
  • Agentenspezifische Kosten: Für die Agenten in beiden Teams ist nur jeweils eine Lizenz erforderlich.
  • Die abteilungsübergreifende Eskalation oder Verfolgung von Anfragen ist einfacher, wenn es eine einzige Support-Instanz verwendet wird.
  • Nahtlose Benutzerverwaltung und -authentifizierung:
    • „Single Source of Truth“ für Benutzer.
    • 360°-Ansicht des Kunden.

Zu berücksichtigende Aspekte:

  • Bei bestimmten Plänen ist die Beschränkung des Zugriffs auf Tickets ein komplexer Vorgang.
  • Für Agenten, die gleichzeitig auch Endbenutzer in einem anderen Team sind, ergibt sich kein nahtloses Benutzererlebnis.
  • Definierte Change-Management-Prozess (und -Strategie) erforderlich.
  • Die Weiterleitung von Tickets und Business-Regeln sind komplexer.
  • Viele anpassbare Funktionsmerkmale von Zendesk Support werden global konfiguriert (Authentifizierung, E-Mail-Vorlage, Kontoname, Willkommens-E-Mails).

Vorteile bei Verwendung mehrerer Zendesk-Instanzen:

  • Die Kompartimentierung ist einfacher.
  • Flexibilität, Änderungen vorzunehmen, die sich nicht auf andere Teams auswirken.
  • Unabhängige und komplett anpassbare Self-Service- und Wissens-Workflows (KCS, Answer Bot, Team Publishing).
  • Komplett anpassbares Endbenutzererlebnis für jedes Team (gutes Endbenutzererlebnis für Agenten, die gleichzeitig auch Endbenutzer in einem anderen Team sind).
  • Teamspezifische Kontrolle von Ticketzugriff und Sicherheit.

Zu berücksichtigende Aspekte:

  • Zusätzliche Kosten für den Aufwand, der mit der Konfiguration und Analyse mehrere Instanzen verbunden ist.

  • Separate Konfiguration von SSO, Apps und Integrationen für jede Instanz erforderlich.

  • Endbenutzer müssen an unterschiedliche Stellen gehen, um Anfragen einzureichen oder Self-Service in Anspruch zu nehmen.

  • Die Zusammenarbeit zwischen Agenten wird komplexer, da zum Austausch von Tickets zwischen Support-Instanzen die Funktion zum Teilen von Tickets eingerichtet werden muss.

  • Die Funktion zum Verhindern von Agentenkollisionen funktioniert nicht über zwei separate Support-Instanzen hinweg.

  • Die Funktion zum Teilen von Tickets ermöglicht zwar die instanzübergreifende Zusammenarbeit, aber die Aktualisierung von Tickets erfolgt nicht synchron zwischen den beiden Support-Instanzen.

  • Bei bestimmten Plänen kann die Steuerung des Ticketzugriffs und der Sicherheit nach Teams in einer einzigen Instanz erfolgen, indem private Ticketgruppen erstellt werden.

Powered by Zendesk