Votre entreprise a peut-être plusieurs organisations, comprenant elles-mêmes plusieurs services avec des processus, des besoins de sécurité et des workflows différents. Nous vous conseillons de vous demander si une instance de Zendesk est suffisante ou si plusieurs instances fonctionneraient mieux. Cet article décrit les avantages, les considérations et les conséquences de l’utilisation de plusieurs instances au lieu d’une seule. Cet article inclut les sujets suivants :

  • Fonctionnalités
  • Portée
  • Récapitulatif

Fonctionnalités

Ce sujet couvre l’impact de l’utilisation d’une seule instance Zendesk pour plusieurs équipes pour les fonctionnalités suivantes : 

  • Paramètres généraux
  • Règles de gestion
  • Intégrations
  • Authentification et accès
  • Gestion des utilisateurs finaux
  • Permissions et accès aux tickets des agents
  • Rapports
  • Web Widget (Classique) et widget Chat
  • Guide

Paramètres généraux

Cette section aborde des considérations portant sur les paramètres généraux. 

  • Abonnement
    Si vous avez une instance Zendesk, tous les agents doivent utiliser la même édition pour Support, Guide, Talk et Chat. Pour Guide en particulier, tous les agents Support doivent être des agents Guide. Si une seule équipe utilise Guide, il s’agit d’une considération économique.

  • Signatures d’agent
    Il n’y a qu’une signature d’agent globale native par Zendesk. Vous pouvez cependant personnaliser des déclencheurs pour chaque équipe, avec la signature dans le déclencheur ou des conditions de balisage Liquid.
  • Modèle d’e-mail
    Il y a un seul modèle d’e-mail natif par Zendesk. Vous pouvez cependant personnaliser toutes les règles de gestion prenant en charge HTML, CSS ou le balisage Liquid. Consultez Liquid et Zendesk Support.

  • E-mails de bienvenue/vérification
    Il y a un seul e-mail de bienvenue/vérification natif qui suit le nom de compte ajouté sous Paramètres > Compte.

  • Sous-domaine
    Vous ne pouvez avoir qu’un seul sous-domaine pour les agents. Il n’est pas possible de personnaliser le sous-domaine des agents en fonction des noms des équipes.

  • Tout le monde peut envoyer des tickets
    Un compte Zendesk doit être ouvert pour tous les utilisateurs ou fermé pour tous les utilisateurs. S’il est ouvert, tout le monde peut envoyer une demande, se connecter à Guide ou envoyer un ticket via le widget. S’il est fermé, l’utilisateur final doit être un utilisateur existant dans Support pour envoyer une demande ou accéder à Guide. Consultez Configuration de la façon dont les utilisateurs finaux accèdent et se connectent à Zendesk Support.

  • Nom du compte
    • Il n’y a qu’un seul nom de compte. Consultez Comment changer le nom de mon compte dans Zendesk Support ?.
    • Le nom du compte est visible dans les e-mails s’ils utilisent des balises formatées. Le nom du compte fait partie de l’e-mail envoyé et est visible par les utilisateurs finaux. Pour éviter cela, vous devez arrêter d’utiliser des balises formatées et utiliser des balises de contenu riche prenant en charge le texte riche. Cependant, cela élimine l’aspect esthétique des balises formatées.
    • Enfin, le nom du compte est visible à la page/l’invite de connexion et ne peut pas être modifié.
  • Autoriser les utilisateurs à appartenir à plusieurs organisations
    Si vous décidez d’utiliser une instance Zendesk pour plusieurs équipes, il y a un paramètre général qui est activé ou désactivé pour l’instance entière.

  • Enquête de satisfaction
    Même si les enquêtes de satisfaction sont activées ou désactivées pour l’instance Support entière, vous pouvez modifier les règles de gestion afin qu’elles ne s’exécutent pas pour certains groupes. Un lien de satisfaction peut être généré pour n’importe quel ticket en utilisant les balises. Consultez Utilisation des balises de notes de satisfaction client.

  • Exportation de données
    Les exportations de données pour les tickets, les utilisateurs et les organisations sont globales pour l’ensemble du compte. Vous pouvez cependant utiliser l’API principale de Zendesk pour récupérer des données plus spécifiques.

  • Marqueurs
    Dans une instance avec plusieurs équipes, il ne faut pas utiliser les MÊMES marqueurs pour plusieurs workflows ou ressources.

Règles de gestion

Cette section aborde des considérations portant sur les règles de gestion.

  • Déclencheurs, automatismes, vues et SLA
    • Les règles de gestion s’exécutent sur tous les tickets, mais il est facile de les restreindre en utilisant des conditions qui recherchent un groupe de tickets ou une marque. Consultez Utilisation des groupes dans les règles de gestion. Les administrateurs sont globaux et peuvent créer des règles pour les groupes qu’ils n’administrent pas. Cela crée le risque que l’administrateur d’une équipe modifie des règles qui affectent les tickets et les workflows d’autres équipes. 
    • Si vous utilisez différentes équipes avec la même instance Zendesk, il y a un nombre croissant de règles à gérer. La complexité accrue nécessite une stratégie de gestion des changements et une collaboration continue entre les équipes. Il y a aussi un risque accru que les tickets soient routés vers les mauvais groupes, ce qui peut avoir un impact sur les SLA.
    • Vous devez aussi considérer les informations confidentielles ou sécurisées pouvant être visibles par des agents qui ne devraient pas y avoir accès. Il n’existe pas de méthode intégrée pour organiser les règles de gestion par groupe.
    • Pour organiser/grouper les règles de gestion, vous pouvez créer des déclencheurs ou des automatismes n’ayant aucune fonction à part un nom qui aide à catégoriser les règles par équipe.

  • Macros
    L’accès aux macros peut être configuré pour tous les agents ou pour les agents de certains groupes. Consultez Création de macros personnelles pour les tickets pour en savoir plus.

  • Champs et formulaires de ticket
    • Les champs et formulaires de ticket sont globaux et s’appliquent à l’instance entière. Toutes les équipes peuvent voir tous les champs et tous les formulaires. Pour avoir des formulaires uniques pour les différentes équipes et pour l’expérience des utilisateurs finaux, il faut des formulaires de ticket personnalisés.
    • Dans l’interface d’agent, une application personnalisée peut masquer ou afficher certains champs en fonction de l’agent qui est en train de consulter le ticket. Vous pouvez aussi appliquer la recette décrite dans l’article portant sur les formulaires de ticket restreints.
    • Vous pouvez personnaliser le code du centre d’aide pour marquer les champs modifiables par l’utilisateur final qui ne sont pas obligatoires dans le formulaire de demande.

Intégrations

Cette section aborde des considérations portant sur les intégrations.

  • JIRA
    La version 3 de l’intégration Zendesk JIRA est individuelle (one-to-one). Vous ne pouvez pas lier plusieurs intégrations JIRA à un compte Zendesk Support.

  • Intégrations personnalisées
    Si vous avez plusieurs instances Support, vous devez configurer chaque intégration personnalisée. Par exemple, l’exécution d’exportations de données ou la connexion à une base de données utilisateur nécessite développement et configuration des deux côtés de chaque instance Support.

  • Applications (framework des applications Zendesk/ZAF)
    Les applications doivent être installées et configurées dans chaque instance Support. Si les options intégrées ne sont pas assez détaillées pour vos besoins, vous pouvez coder une application personnalisée pour vérifier le groupe de l’utilisateur et masquer ou afficher l’application. Il est possible de spécifier l’accès aux applications par groupe ou rôle personnalisé. Consultez Restriction de la visibilité d’une application par groupe.

Authentification et accès

Cette section aborde des considérations portant sur l’authentification et l’accès.

  • Authentification de base
    Avec plusieurs instances Zendesk, les identifiants de connexion (noms d’utilisateur et mots de passe) sont uniques pour chaque instance. Les agents et les utilisateurs finaux doivent gérer et mémoriser deux jeux d’identifiants pour plusieurs instances Zendesk qui utilisent l’authentification Zendesk intégrée.

  • Accès API
    Les tokens API sont globaux, ce qui signifie que tout utilisateur disposant d’un token API peut accéder à toutes les ressources et données du compte.

  • OAuth
    Les tokens OAuth peuvent être restreints pour limiter l’accès à certaines ressources. Cependant, les tokens ne peuvent pas être limités à des groupes d’agents.

  • Connexion unique (SSO)
    • La connexion unique intégrée s’applique à l’instance entière pour les configurations d’agent et d’utilisateur final. Les agents et les utilisateurs finaux de toutes les équipes doivent être configurés dans le fournisseur d’identités de connexion unique.
    • Il est possible d’autoriser les utilisateurs à utiliser des méthodes d’authentification différentes (authentification Zendesk et connexion unique), mais cela doit être configuré côté client. Consultez Having the talk: Am I ready for a more advanced authentication option?.

Gestion des utilisateurs finaux

Cette section aborde des considérations portant sur la gestion des utilisateurs.

  • Champs d’organisation et d’utilisateur
    Les champs d’organisation et d’utilisateur sont globaux pour l’instance entière, ce qui signifie que tous les agents peuvent les voir et potentiellement les modifier. Comme pour les champs de ticket, une application personnalisée peut permettre de masquer ou d’afficher certains champs d’organisation/ d’utilisateur en fonction de l’agent qui les consulte.

  • Gestion des organisations
    • Les organisations sont globales pour l’instance entière. Il est impossible de segmenter les organisations ou les droits de consultation des organisations par groupes d’agents.
    • Pour la fonctionnalité de partage de tickets d’une organisation, les droits d’accès sont globaux pour tous les tickets de l’organisation. Si cette option est activée, elle affecte les tickets de toutes les équipes utilisant Support et Guide.
    • Les noms d’organisations doivent être uniques. Les utilisateurs peuvent appartenir à plusieurs organisations, mais il est impossible d’avoir deux organisations avec le même nom pour différentes équipes.

  • Permissions et accès des utilisateurs finaux
    • Tous les utilisateurs finaux sont globaux pour l’instance entière. Il est impossible d’autoriser un utilisateur final à envoyer des demandes à une équipe dans une instance et de lui interdire de le faire dans une autre.
    • Seule la méthode principale d’authentification des utilisateurs finaux est prise en charge de façon intégrée. Les utilisateurs finaux peuvent se connecter à toutes les instances du centre d’aide. Il existe des workflows qui permettent d’outrepasser ce comportement, mais elles sont très personnalisées et nécessitent un développement côté client. 

Permissions et accès aux tickets des agents

  • Permissions de modification des utilisateurs finaux par les agents
    Il y a plusieurs considérations en fonction du type d’édition :
    • Rôles d’agent personnalisés : si votre édition inclut les rôles personnalisés vous pouvez autoriser un groupe d’agents à modifier les profils des utilisateurs finaux, mais pas un autre. Les agents peuvent consulter les profils de tous les utilisateurs finaux. Il existe des configurations dans lesquelles un agent n’a pas accès à un ticket dans un autre groupe, mais peut y modifier les utilisateurs finaux. Cela inclut la connexion avec l’identité de l’utilisateur final qui permet à l’agent de voir TOUS les tickets de l’utilisateur final.
    • Rôle d’agent : pour les éditions sans rôles d’agent personnalisés, seuls les agents ayant accès à tous les tickets peuvent ajouter des utilisateurs finaux, les modifier ou se connecter avec leur identité.
    • Cas particuliers dans lesquels les agents d’une équipe sont considérés comme des utilisateurs finaux par une autre équipe : les agents ne peuvent pas envoyer de tickets en utilisant le centre d’aide et de ce fait, les formulaires destinés aux utilisateurs finaux ne fonctionnent pas pour les agents. Quelles que soient les permissions de groupe, les agents peuvent accéder aux tickets dont ils sont le demandeur, ce qui signifie qu’ils peuvent accéder aux communications internes pour le demandeur.

  • Gestion des groupes et accès aux tickets
    • Les groupes sont globaux pour l’instance entière. Il est possible de créer des groupes pour gérer plusieurs équipes et limiter l’accès aux tickets par groupe.
    • Avec les éditions Enterprise, vous pouvez créer des groupes de tickets privés. Les groupes de tickets privés offrent un contrôle plus détaillé de la visibilité et de l’accès aux tickets en fonction de l’affectation des groupes en masquant complètement les tickets privés pour les agents qui n’ont pas la permission de les consulter.
    • Et aussi avec les éditions Enterprise, vous pouvez utiliser les rôles d’agent personnalisés pour contrôler l’accès des agents aux groupes de tickets privés, y compris leur capacité à affecter des tickets aux groupes privés.

Rapports

Cette section aborde des considérations portant sur les rapports.

  • Rapports
    • Si vous utilisez une seule instance, les rapports sont centralisés. Toutes les données de ticket, d’utilisateur et d’organisation sont à la disposition de tous les utilisateurs ayant accès aux rapports.
    • Pour les autres éditions, c’est l’accès aux tickets qui contrôle l’accès aux rapports. Les agents doivent avoir accès à tous les tickets pour consulter les rapports.
    • Les tableaux de bord de rapports par défaut sont globaux pour toutes les données Support. Cela signifie que toute segmentation des rapports par groupe ou autre attribut au niveau du ticket (champ de ticket personnalisé, marque du ticket, etc.) doit être créée.

  • Rapports intégrés
    Les rapports intégrés (non Explore) Tout afficher, Tableau des performances, Base de connaissances, Communauté, Recherche et Talk sont des analyses globales pour l’instance entière.

Web Widget (Classique) et widget Chat

Cette section aborde des considérations portant sur le Web Widget (Classique) et le widget Chat. Il est possible qu’elles ne s’appliquent pas au Web Widget de messagerie.

  • L’aspect et les personnalisations intégrées (couleur, emplacement, texte du bouton) sont globaux. Il est possible d’utiliser l’API du widget pour personnaliser le widget par équipe, mais cela nécessite un développement personnalisé.
  • Les formulaires de ticket seraient requis pour avoir une expérience des formulaires/champs personnalisée par équipe.
  • La recherche du centre d’aide dans le widget effectue des recherches dans la totalité de la base de connaissances et dans une seule base de connaissances. Cependant, avec un développement personnalisé, il est possible de personnaliser les résultats de recherche.
  • Chat peut être activé ou désactivé dans le widget, ce qui peut avoir un certain nombre d’implications si une seule équipe utilise Chat. Il est parfois possible d’outrepasser ce paramètre avec des personnalisations de l’API du widget et l’API Chat.

Guide

Cette section aborde des considérations portant sur Guide.

  • Permissions pour les agents
    • Une stratégie collaborative est nécessaire si plusieurs équipes utilisent Guide. Par exemple, les agents d’une équipe qui sont des responsables pourront gérer le contenu et modifier les thèmes pour les autres équipes, même si vous utilisez Multimarque.
    • Les permissions de modification et de création des articles sont un mélange de paramètres Support et de paramètres Guide au niveau des sections. Les administrateurs Zendesk Support sont des responsables Guide par défaut.
    • Si vous utilisez une édition avec des rôles personnalisés, vous pouvez créer un rôle personnalisé et définir la permission de responsable Guide. Si vous utilisez une autre édition, vous pouvez contrôler qui est un responsable ou un lecteur Guide à la page de profil des agents. Consultez Rôles Guide et configuration des permissions.
    • Les agents peuvent être définis comme lecteurs dans Support, mais peuvent toutefois créer et modifier des articles dans toutes les sections configurées pour les responsables et les agents dans les permissions au niveau des sections.
  • Expérience des utilisateurs finaux
    • Si vous utilisez un Zendesk, tous les utilisateurs finaux peuvent se connecter à tous les centres d’aide. S’il y a des utilisateurs finaux communs quand plusieurs équipes utilisent une instance Zendesk Support pour les tickets, les utilisateurs finaux n’ont qu’un seul jeu d’identifiants de connexion (ils en ont plusieurs si les équipes utilisent différentes instances Support).
    • Les utilisateurs finaux peuvent voir tous les tickets à un seul et même endroit si vous utilisez une seule instance Support. Cependant, cela ne s’applique pas si les tickets concernent des marques différentes.
    • Les segments d’utilisateurs et une stratégie pour les permissions sont nécessaires pour gérer qui peut voir quel contenu pour tous les centres d’aide associés à une instance Support.
    • Enfin, si les agents d’une équipe sont des utilisateurs finaux pour une autre équipe, ils ont une expérience limitée du centre d’aide. Ils sont redirigés vers Support pour envoyer et consulter les demandes.

Portée

Avant de prendre votre décision finale, réfléchissez aux questions suivantes :

Tous les agents devraient-ils avoir accès à tous les tickets ?

Si vous utilisez une instance Support pour plusieurs équipes, voici les choses à prendre en compte avant d’autoriser l’accès à tous les tickets ou non.

Autoriser l’accès à tous les tickets :

  • Si les agents ont accès à tous les tickets, quel niveau de complexité/d’évolutivité serait nécessaire pour configurer des routages de tickets indépendants en utilisant les règles de gestion (vues, déclencheurs, automatismes, SLA, modèles d’e-mails) pour chaque équipe puisque les règles de gestion sont globales pour l’instance entière ? 
  • Par exemple, si deux équipes (assistance et ventes) utilisent un Zendesk, il faut un déclencheur de routage pour chaque équipe (ainsi que des déclencheurs indépendants pour les réponses automatiques/la mise à jour des commentaires) afin de personnaliser l’expérience des utilisateurs finaux pour chaque équipe.
  • Risque accru de routage incorrect des tickets en termes de SLA.

Ne pas autoriser l’accès à tous les tickets :

  • Il faut configurer des groupes ou des rôles personnalisés pour limiter l’accès.
  • Une gestion minutieuse du routage des tickets est nécessaire pour éviter que les tickets ne soient routés vers un groupe qui ne devrait pas y avoir accès.
  • Limite la visibilité des agents sur les demandes historiques ou autres demandes en cours. La restriction d’accès aux tickets peut aussi restreindre l’accès des agents aux rapports.
  • En fonction de votre configuration, si les agents restreints peuvent se connecter avec l’identité des utilisateurs finaux, ils risquent de pouvoir accéder aux tickets ne faisant pas partie de leur groupe à partir de Mes activités dans le centre d’aide.

Y a-t-il une stratégie de gestion des utilisateurs centralisée ou existante ?

Les points à prendre en compte pour les agents et les utilisateurs finaux incluent :

  • En termes d’authentification Zendesk, les utilisateurs qui sont des agents dans les deux instances ont deux jeux d’identifiants.
  • Si vous utilisez la connexion unique, Zendesk doit être configuré comme fournisseur de services pour les deux instances. Si vous utilisez des données utilisateur personnalisées, vous devez créer des champs d’utilisateur et d’organisation dans les deux instances. L’ensemble des champs d’utilisateur, des organisations et des rôles ont des ID uniques, ce qui nécessite la configuration d’assertions SAML/JWT uniques.

Les autres points à prendre en compte pour les utilisateurs finaux incluent :

  • Les utilisateurs finaux doivent-ils avoir accès au contenu du centre d’aide des deux équipes (p. ex., RH et assistance) qui utilisent une instance ?
  • Les utilisateurs finaux doivent-ils avoir accès à tout le contenu des RH et de l’assistance ?  

Récapitulatif

Voici un aperçu des avantages et des considérations pour le choix d’une instance ou de plusieurs instances :

Si vous utilisez une instance Zendesk Support, les avantages incluent :

  • Expérience client unifiée
  • Rapports unifiés
  • Coût des agents : les agents appartenant aux deux équipes n’ont besoin que d’une licence.
  • Les transferts entre services et le suivi des problèmes sont plus simples au sein d’une seule instance Support.
  • Gestion et authentification des utilisateurs unifiées :
    • Source de données unique pour les utilisateurs
    • Vue à 360 degrés du client

Les points à prendre en compte sont :

  • Avec certaines éditions, la restriction de l’accès aux tickets est complexe.
  • L’expérience des agents qui sont des utilisateurs finaux pour d’autres équipes est limitée.
  • Nécessite une stratégie et un processus de gestion des changements définis.
  • Complexité accrue pour le routage des tickets et les règles de gestion.
  • De nombreuses fonctionnalités personnalisables de Support sont configurées globalement (comme l’authentification, les modèles d’e-mail, le nom du compte ou les e-mails de bienvenue).

Si vous utilisez plusieurs instances Zendesk Support, les avantages incluent :

  • Cloisonnement simplifié.
  • Plus grande souplesse pour effectuer des changements sans risquer d’affecter les autres équipes.
  • Workflows de connaissances et de niveau 0/self-service indépendants et entièrement personnalisables (assistance axée sur les connaissances, Answer Bot, Publication d’équipe).
  • Expérience des utilisateurs finaux entièrement personnalisable et adaptée pour chaque équipe (expérience correcte pour les agents qui sont des utilisateurs finaux pour les autres équipes).
  • L’équipe contrôle l’accès et la sécurité des équipes.

Les points à prendre en compte sont :

  • Coûts de la configuration et des analyses pour plusieurs instances.

  • Nécessité de configurer la connexion unique, les applications et les intégrations pour toutes les instances.

  • Les utilisateurs finaux doivent aller à des endroits différents pour envoyer des demandes ou utiliser le self-service.

  • La complexité de la collaboration entre les agents est accrue du fait de l’utilisation du partage des tickets entre les instances Support.

  • La fonctionnalité de collision d’accès ne marche pas pour deux instances Support.

  • Le partage des tickets peut permettre à deux équipes qui utilisent Zendesk de collaborer, mais les mises à jour risquent d’être asynchrones du ticket d’une instance Zendesk à l’autre.

  • Avec certains types d’édition, il est possible de contrôler l’accès aux tickets et la sécurité par équipe en une seule instance en créant des groupes de tickets privés.

Réalisé par Zendesk