Mise au point : comment créer le workflow idéal

Cet article Mise au point aborde les points à considérer quand vous créer un workflow, notamment :

Automatismes et déclencheurs
Emplois du temps d’entreprise et SLA
Macros et vues

N’oubliez pas de consulter également la première partie de cette discussion Mise au point.

Pour trouver d’autres articles Mise au point, consultez Mise au point - Ressources.

Partie 1 : automatismes et déclencheurs

Dans ma dernière discussion Mise au point, brique par brique, j’avais parlé des éléments de base dont vous avez besoin pour créer votre instance Zendesk idéale et de la façon de les configurer en fonction de vos besoins spécifiques. Cette fois-ci, je vais parler des éléments restants pour vous aider à développer le workflow idéal.

Déclencheurs

Les déclencheurs sont très utiles. Ce sont des actions système basées sur les événements qui s’exécutent à la création ou à la mise à jour d’un ticket. Vous pouvez utiliser les déclencheurs dans Zendesk de nombreuses façons différentes, mais elles peuvent toutes être regroupées dans ces catégories :

Affectation des tickets à un agent ou groupe d’agents spécifique
Modification des valeurs de champs de ticket ou ajout/suppression de marqueurs
Notification des utilisateurs (ou cibles) de la création ou de la mise à jour des tickets
Modification des valeurs des champs d’utilisateur ou d’organisation (à la mise à jour du ticket uniquement)

Risques potentiels :

Zendesk inclut quelques déclencheurs standards que vous devrez peut-être désactiver ou modifier. Si vous ne vérifiez pas votre liste de déclencheurs avant de passer à l’étape de production, vous risquez de recevoir beaucoup de notifications inutiles ou indésirables.

Le déclencheur par défaut Notifier le demandeur de la mise à jour des commentaires est le déclencheur le plus important de votre compte. C’est le déclencheur qui envoie vos commentaires de ticket aux utilisateurs finaux. Vous devez savoir que si vous le modifiez ou le supprimez, vos capacités de communication avec vos clients risquent d’en pâtir.

Évitez de créer des déclencheurs qui font trop de choses. Plus un déclencheur est compliqué, plus il est difficile d’en assurer la maintenance et le dépannage.

Si vous avez une instance Zendesk Support ouverte dans laquelle n’importe qui peut envoyer des tickets et qui ne nécessite pas d’inscription, les déclencheurs de première réponse (qui s’exécutent à la création du ticket) qui utilisent une ou plusieurs des balises ci-dessous peuvent servir à relayer du spam.

{{ticket.title}}
{{ticket.requester.first_name}}
{{ticket.requester.last_name}}
{{ticket.requester.name}}

Le relais de spam a lieu quand un e-mail est envoyé à une destination via une tierce partie (dans ce cas, Zendesk) pour masquer la source de l’adresse e-mail et se faire passer pour un tiers. Ces balises sont des cibles du spam de relais, car ce sont des points de terminaison anonymes qui permettent à n’importe qui de saisir le texte ou les liens désirés.

Pour éviter que votre compte ne devienne une cible de spam de relais, envisagez de configurer votre instance pour qu’elle soit fermée ou restreinte, comme expliqué dans Configuration de l’accès des utilisateurs finaux. Sinon, dans une instance Zendesk Support ouverte, n’utilisez pas les balises répertoriées ci-dessus dans le sujet ou le corps de vos déclencheurs de premières réponses et utilisez plutôt du texte statique. Cela garantit que la notification par e-mail envoyée à la création d’un ticket, par exemple, ne remplace pas une salutation qui devrait dire « Chère Amanda Smith » par « Chère www.spa,.com ». L’utilisation de ces balises dans d’autres déclencheurs (après la première réponse) est acceptable car, à ce stade, vous avez établi qu’il s’agit d’une interaction authentique.

Meilleures pratiques :

Utilisez une nomenclature et tenez-y vous. Idéalement, vous devriez pouvoir comprendre la fonction d’un déclencheur d’après son nom. Vous gagnerez beaucoup de temps en évitant d’avoir à cliquer chaque déclencheur pour savoir ce qu’il fait. Voici quelques exemples :

Définir la priorité - Normale

Définir l’emploi du temps - Amérique du Nord

Affecter au groupe - Niveau 1

Notifier le demandeur de la mise à jour des commentaires

Si votre liste de déclencheurs fait plus d’une page, la nomenclature est extrêmement importante. Vous pouvez rechercher un déclencheur en fonction de son titre.

L’ordre des déclencheurs est important. Le système vérifie chaque déclencheur chaque fois qu’un ticket est créé ou mis à jour. Je vous conseille de classer vos déclencheurs de la façon suivante :

Modification/Mise à jour des valeurs du ticket - les déclencheurs qui changent les valeurs de ticket, comme la priorité, le statut ou toute autre valeur de ticket, ou ajoutent des tickets à la liste doivent apparaître en premier. En effet, ces déclencheurs peuvent affecter les affectations de ticket et les notifications.
Affectations de ticket - les déclencheurs qui affectent les tickets à un agent ou un groupe d’agents doivent apparaître après les déclencheurs qui mettent à jour n’importe quelle autre valeur de ticket.
Notifications - les déclencheurs qui envoient des notifications aux utilisateurs ou aux cibles doivent apparaître en dernier. En effet, le système doit effectuer toutes les modifications nécessaires avant l’envoi des notifications par e-mail.

Au sein de chacune des catégories répertoriées ci-dessus, je vous conseille de classer vos déclencheurs en allant des conditions spécifiques aux conditions générales. Cela évite que vos déclencheurs globaux se déclenchent à la place de vos déclencheurs plus ciblés.

Dans la mesure du possible, vos déclencheurs doivent être simples et réfléchis. Plus vos déclencheurs sont simples, plus il est facile d’assurer leur maintenance au fil de la croissance ou des changements d’administrateurs.

Quelques questions à vous poser :

Vos agents travaillent-ils dans Zendesk toute la journée ou plutôt dans leur logiciel de messagerie ?
Lesquels de vos agents ont besoin de notifications par e-mail ?
Quand ont-ils besoin d’être notifiés ?
Quand vos utilisateurs finaux ont-ils besoin d’être notifiés ?
Quels éléments de votre workflow peuvent être automatisés ?
Quels éléments de votre workflow doivent être automatisés ?
Quelle formulation devez-vous utiliser pour vos déclencheurs de notification ?

Pour en savoir plus au sujet de la création et de la gestion des déclencheurs, cliquez ici.

Automatismes

Les automatismes sont des actions système temporelles. Ils s’exécutent toutes les heures et ont généralement des conditions temporelles. Vous pouvez utiliser les automatismes pour faire les choses suivantes :

Affectation des tickets à un agent ou groupe d’agents spécifique
Modification des valeurs de champs de ticket ou ajout/suppression de marqueurs
Notification des utilisateurs (ou cibles) de la création ou de la mise à jour des tickets
Modification des valeurs des champs d’utilisateur ou d’organisation

Vous avez peut-être remarqué que les actions qui peuvent être effectuées par les automatismes sont identiques aux actions qui peuvent être effectuées par les déclencheurs. La différence entre les déclencheurs et les automatismes n’est pas les actions qu’ils peuvent effectuer, mais les conditions qui déclenchent leur exécution. Les automatismes vous permettent d’effectuer des actions système quand la condition x heures depuis ou x heures jusqu’à un événement est vraie.

Risques potentiels :

Les automatismes s’exécutent au maximum une fois par heure. Il est donc difficile de s’en servir pour les mises à jour prioritaires. Si un ticket arrive même une seule minute après l’exécution de votre automatisme, celui-ci risque de toujours voir le ticket comme 0 heure depuis la création à sa prochaine exécution une heure plus tard.

Quand vous définissez une condition temporelle stricte (comme Temps écoulé depuis création est X) au lieu d’une condition temporelle plus générale (comme Temps écoulé depuis création est supérieur à X), il est possible que vos automatismes ne s’exécutent pas au cours de l’heure pendant laquelle votre ticket se qualifie. Vous risquez ainsi de rater des notifications ou mises à jour de ticket importantes.

Meilleures pratiques :

Avant de créer un automatisme, demandez-vous s’il vaut mieux utiliser un déclencheur ou un automatisme pour les résultats souhaités. Dans de nombreux cas, les déclencheurs sont plus efficaces, car ils peuvent être exécutés immédiatement.

Dans la mesure du possible, utilisez les conditions supérieur/inférieur à au lieu des conditions est quand vous créez des automatismes temporels. Cela élimine le risque que votre ticket passe à travers les mailles du filet sans que l’automatisme s’exécute. Attention, dans ce cas-là, vous devez ajouter une condition d’annulation et une action afin d’éviter une boucle (le système vous préviendra si cela est nécessaire).

Pour que cela fonctionne, créez des conditions qui cherchent quelque chose (comme un marqueur ou une valeur de champ) que le ticket ne devrait pas contenir avant l’exécution de l’automatisme, puis assurez-vous que l’automatisme effectue une modification qui disqualifie le ticket à sa prochaine exécution. Cela évite que l’automatisme ne s’exécute à plusieurs reprises.

Vous pouvez utiliser les automatismes pour créer un workflow transfert, transfert, résolution automatisé. Cela garantit que vos tickets ne tombent pas dans l’oubli si le demandeur ne répond pas et empêche également ces tickets d’encombrer vos vues inutilement.

Quelques questions à vous poser :

Cela devrait-il être un déclencheur ou un automatisme ?
Avez-vous besoin que le système vous notifie ou prenne des mesures quand un ticket tombe dans l’oubli ?
Combien de temps un ticket doit-il rester dans le statut Résolu avant d’être clos ?
Quelle formulation devez-vous utiliser pour vos e-mails de notification ?

Pour en savoir plus au sujet de la création et de la gestion des automatismes, cliquez ici.

Partie 2 : emplois du temps d’entreprise et SLA

Emplois du temps d’entreprise

Les emplois du temps d’entreprise sont peut-être moins tape-à-l’œil que les déclencheurs ou les automatismes, mais ils peuvent quand même jouer un rôle essentiel dans votre workflow. La définition d’emplois du temps d’entreprise vous permet de :

Effectuer des actions système avec des déclencheurs et des automatismes pendant ou hors des horaires d’ouverture
Spécifier les durées en heures ouvrées (et non en heures calendaires) dans les automatismes et les SLA
Fournir des objectifs de service précis par le biais des SLA

Risques potentiels :

Le premier emploi du temps de votre liste est votre emploi du temps par défaut et est appliqué à tous les nouveaux tickets. Vous ne pouvez pas réagencer vos emplois du temps, ce qui veut dire que vous ne pouvez pas définir un emploi du temps nouveau ou existant comme emploi du temps par défaut. Vous devrez supprimer tous les emplois du temps avant lui (ou changer son nom et ses propriétés) pour définir un nouvel emploi du temps par défaut.

Vous pouvez ajouter des jours chômés à vos emplois du temps, mais ils ne sont pas conservés d’une année à l’autre. Vous devez donc les saisir manuellement pour chaque année.

Les jours chômés sont des dates qui sont enlevées de votre emploi du temps d’entreprise. Ainsi, si vous travaillez seulement une demi-journée, vos SLA basés sur les heures ouvrées seront mis en pause toute la journée. (Mais cela peut aussi être une bonne chose.)

Vous ne pouvez pas cloner les emplois du temps. Cela signifie que vous devrez saisir manuellement vos jours chômés tous les ans pour chaque emploi du temps.

N’oubliez pas de définir votre fuseau horaire. Votre emploi du temps ne fonctionnera que s’il est dans le bon fuseau horaire. Avec certaines éditions, vous pouvez définir le fuseau horaire pour chaque emploi du temps. Avec d’autres types d’édition, vous pouvez définir l’emploi du temps ici.

Meilleures pratiques :

Élaborez un plan avant de commencer à saisir des emplois du temps. Saisissez votre emploi du temps par défaut (si vous en avez un) en premier. Cet emploi du temps sera appliqué par défaut à tous les nouveaux tickets, ce qui signifie que tous les SLA appliqués aux tickets utilisant les heures ouvrées suivront cet emploi du temps.

Si vous utilisez plusieurs emplois du temps, utilisez des déclencheurs pour affecter les emplois du temps aux tickets. Par exemple, vous pouvez créer un déclencheur qui affecte l’emploi du temps x quand un ticket est affecté au groupe x. Si vous faites cela pour tous les emplois du temps, la définition de l’emploi du temps par défaut n’a plus d’importance.

Vous ne pouvez pas cloner les emplois du temps, mais vous pouvez cloner les jours chômés. Vous devez toujours les saisir manuellement, mais vous pouvez au moins les cloner puis changer les dates. C’est le meilleur moyen de saisir les jours chômés récurrents.

Quand vous créez vos jours chômés, vous ne pouvez pas définir d’heures réduites. La journée entière est exclue de l’emploi du temps. Servez-vous de ces jours pour rattraper votre travail en retard, puisque de toute façon, il est probable que le volume de demandes soit plus faible ces jours-là.

Quelques questions à vous poser :

Proposez-vous une assistance 24/7/365 à vos clients ?
Avez-vous une ou plusieurs équipes qui sont disponibles uniquement pendant des heures ou des jours spécifiques ?
Avez-vous des jours chômés avec des heures réduites ?
De combien d’emplois du temps différents avez-vous besoin ?

Les emplois du temps d’entreprise ne sont pas disponibles avec les éditions Team. Pour en savoir plus au sujet de la création et de la gestion des emplois du temps, cliquez ici.

Politiques SLA

De nombreuses entreprises prennent des engagements envers leurs clients qui déterminent le laps de temps maximum attendu avant certains événements.

Les accords sur les niveaux de service (SLA) de Zendesk vous permettent de hiérarchiser les tickets en y ajoutant des objectifs de service. Les objectifs disponibles incluent :

Délai avant première réponse (le laps de temps entre la création du ticket et le premier commentaire public d’un agent)
Temps d’attente du demandeur (le temps total combiné du ticket en statut Nouveau, Ouvert ou En pause)
Temps de travail de l’agent (le temps total combiné du ticket en statut Nouveau et Ouvert)
Temps de réponse suivant (le laps de temps entre le commentaire d’un utilisateur final et le commentaire public suivant d’un agent)
Mise à jour périodique (le laps de temps écoulé entre le commentaire public d’un agent et le prochain commentaire public d’un agent)
Mise à jour avec mise en pause (Le laps de temps entre chaque commentaire public des agents quand les tickets ont le statut Nouveau, Ouvert ou En pause. Il y a mise en pause quand le statut du ticket est défini sur En attente)

Risques potentiels :

Avec les SLA de Zendesk, vous devez utiliser le champ de priorité du système. Si vous n’affectez pas de priorité à un ticket, vos SLA n’y sont pas appliqués.

Si vos SLA sont basés sur les heures ouvrées et si vous avez plusieurs emplois du temps, vous devez vous assurer que le bon emploi du temps est appliqué à chaque ticket. Si vous ne spécifiez pas d’emploi du temps pour un ticket, c’est l’emploi du temps d’entreprise par défaut qui s’applique.

L’objectif Délai avant première réponse est immédiatement réalisé quand un agent crée un ticket (même s’il définit un utilisateur final comme demandeur). En effet, la description du ticket compte comme premier commentaire public par un agent. Comme cet objectif est immédiatement réalisé, il semble que le ticket a été traité.

L’objectif Temps de réponse suivant ne fonctionne pas pour les tickets internes. L’objectif mesure le temps écoulé entre le commentaire d’un utilisateur final et le commentaire public suivant par un agent, donc cet objectif ignorera tous les tickets envoyés par des agents.

Évitez d’utiliser tous les objectifs dans une politique. Choisissez Temps d’attente du demandeur, Temps de travail de l’agent ou aucun des deux. L’utilisation de ces deux objectifs dans la même politique est inutile et complique les choses.

Les violations SLA ne peuvent pas être utilisées comme événements dans les déclencheurs. Cela signifie qu’il est impossible de créer un déclencheur de notification de violation immédiat.

Meilleures pratiques :

Vous disposez de six objectifs. Vous n’avez pas besoin (et devriez même éviter) de les utiliser dans la même politique.

L’objectif Délai avant première réponse est un excellent moyen de vous assurer que chaque nouveau ticket est traité dans un délai raisonnable. L’objectif Temps de réponse suivant est tout aussi important pour la même raison. En règle générale, nous conseillons de concevoir l’objectif Temps de réponse suivant de façon à ce qu’il ressemble le plus possible, voire complètement, à l’objectif Délai avant première réponse de la même politique.

Choisissez soit Temps de travail de l’agent, soit Temps d’attente du demandeur, ou encore aucun des deux, car ces deux objectifs mesurent le temps nécessaire à la résolution d’un ticket. L’objectif Temps de travail de l’agent mesure ce temps du point de vue de l’agent et est donc mis à pause quand le ticket est en pause et/ou en attente. L’objectif Temps d’attente du demandeur mesure ce temps du point de vue du demandeur et n’est donc mis en pause que lorsqu’un ticket est en attente.

Choisissez soit Mise à jour périodique soit Mise à jour avec mise en pause, car ces deux objectifs mesurent le temps écoulé entre les commentaires publics des agents.

Quelques questions à vous poser :

Avez-vous une obligation contractuelle de satisfaire à des objectifs de service spécifiques ?
Avez-vous des objectifs de service internes ?
Avez-vous besoin de plusieurs politiques ou une politique générale vous suffit-elle ?
Comment hiérarchisez-vous vos tickets ?
Avez-vous un objectif de service pour le temps de résolution d’un ticket ?
Si vous en avez un, doit-il être mesuré du point de vue du demandeur ou du point de vue de l’agent ?
Proposez-vous une assistance 24/7/365 à tous vos clients ?

Voulez-vous utiliser les heures calendaires ou votre emploi du temps d’entreprise pour vos objectifs ?

Les politiques SLA ne sont pas disponibles avec les éditions Team. Pour en savoir plus au sujet de la création et de la gestion des SLA, cliquez ici.

Partie 3 : macros et vues

Macros

Les macros sont des scripts activés par les agents, qui appliquent plusieurs actions à un ticket simultanément. Il est important de savoir qu’une macro ne peut faire que ce que peut faire un agent et que les modifications du ticket ne seront enregistrées qu’une fois que l’agent a mis le ticket à jour.

Les macros peuvent accroître la productivité de vos agents en réduisant le nombre de clics.

Les macros peuvent :

Ajouter du texte de commentaire
Mettre les champs de ticket à jour (liste déroulante et case à cocher uniquement)
Ajouter ou supprimer des marqueurs de ticket
Ajouter des CC
Modifier l’assigné
Définir le sujet du ticket (titre)
Ajouter des pièces jointes aux commentaires de ticket

Risques potentiels :

Les macros sont en gros des raccourcis destinés aux agents. La macro ne peut faire que ce l’utilisateur actuel peut faire. Par exemple, si un agent n’a pas la permission de modifier les marqueurs de ticket, la macro n’ajoutera pas ou ne supprimera pas les marqueurs quand l’agent l’exécute.

Les macros ne mettent pas à jour les champs de ticket de texte, de texte multiligne, de date, numériques ou d’expression régulière.

Meilleures pratiques :

Comme pour les champs de liste déroulante, vous pouvez imbriquer les macros. C’est un excellent moyen de les organiser.

Vous pouvez exécuter plusieurs macros dans le cadre d’une seule mise à jour de ticket. Cela signifie que vous n’avez pas à créer de macro pour chaque situation possible et imaginable. Restez simple.

Utilisez des balises. Si vous commencez vos commentaires avec {{requester.first_name}}, même vos réponses les plus génériques sembleront personnalisées. Vous pouvez aussi utiliser des balises quand vous définissez le sujet du ticket.

Vous pouvez affecter les macros à tous les agents ou à des groupes spécifiques. Si seuls certains de vos agents doivent pouvoir voir une macro, n’oubliez pas de la restreindre à ces agents pour éviter tout encombrement inutile.

Vous pouvez rechercher une macro. Commencez à saisir le titre de la macro dans le menu Macro au sein d’un ticket et les macros dans le menu seront filtrées.

Pour faciliter les recherches de macros, créez une nomenclature et tenez-y vous.

Servez-vous des macros pour mettre plusieurs tickets à jour simultanément. Vous pouvez le faire à partir de votre écran Vues en cochant les cases en regard de plusieurs tickets et en cliquant sur le bouton noir Modifier les tickets en fait à droite. Puis appliquez une macro et envoyez-la.

Vous pouvez utiliser les déclencheurs et les automatismes avec les macros. Vous pouvez par exemple avoir une macro ajoutant un marqueur, activant immédiatement un déclencheur. Imaginez toutes les possibilités...

Quelques questions à vous poser :

Pour quels problèmes les plus courants vos utilisateurs finaux envoient-ils des tickets ?
Que devrait dire votre texte de commentaire ?
Votre macro doit-elle envoyer un commentaire public ou privé ?
Quels agents doivent avoir accès à quelles macros ?

Les macros sont disponibles avec toutes les éditions. Pour en savoir plus au sujet de la création et de la gestion des macros, cliquez ici.

Vues

J’ai gardé le meilleur pour la fin. Les vues sont probablement l’élément le plus important de votre workflow. Les vues déterminent quels tickets sont visibles par vos agents et l’ordre dans lequel ils doivent être traités.

Les vues ne sont PAS des dossiers. Ce sont des recherches enregistrées ou des bases de données filtrées, un peu comme des listes de morceaux intelligents dans iTunes.

Risques potentiels :

Ne créez pas des vues trop compliquées. Plus une vue a de conditions, plus les résultats sont filtrés. Cela peut être une bonne chose, mais cela peut aussi être catastrophique. Si vous avez trop de conditions, vous risquez de perdre des tickets.

Si vous avez trop de vues, vos agents risquent de ne pas accorder la priorité aux tickets de votre choix. Pour éviter cela, limitez le nombre de vues à celles qui sont vraiment nécessaires.

Si vous laissez une vue ouverte dans votre navigateur, elle n’est pas automatiquement mise à jour. Elle est actualisée chaque fois que vous cliquez dessus (ou que vous actualisez la page).

Les vues peuvent afficher un maximum de 30 tickets par page. Si vos vues ne sont pas triées correctement, vous risquez de rater des tickets importants.

Meilleures pratiques :

Comme les macros, les vues peuvent être affectées à tous les agents ou à des groupes spécifiques. Dans de nombreux cas, il est judicieux de créer des vues personnalisées pour chacun de vos groupes. Cela garantit que chaque agent ne voit que des informations pertinentes.

Si vous utilisez les SLA, je vous conseille de trier vos vues par Violation SLA suivante. Cela garantit que tous les tickets se retrouveront en haut de liste à un moment ou un autre.

Utilisez le bouton Play. Le bouton Play se trouve en haut à droite de votre page Vues et vous amène directement au prochain ticket disponible dans votre vue.

Quelques questions à vous poser :

Comment hiérarchiser les tickets ?
Quels tickets chaque groupe doit-il voir ?
Comment classez-vous vos tickets ?

Pour en savoir plus au sujet de la création et de la gestion des vues, cliquez ici.