Modèles de réponse et de ticket

Les modèles se trouvent sous « Settings → Templates ». La ligne sous le titre dit ce qu'ils font et ce qu'ils ne font pas : « Reply templates fill the comment editor and suggest field actions. Nothing is sent automatically. » Un modèle est un geste préparé, pas une machine. C'est toujours toi qui envoies.

Il y a deux sortes et tu en choisis une à la création : « Add reply template » pour la réponse sur un ticket ouvert, « Add ticket template » pour le formulaire de nouveau ticket. La sorte ne peut pas être changée ensuite, parce qu'elle décide des champs que le formulaire affiche. La pastille au-dessus de chaque modèle te dit lequel tu as sous les yeux : « Reply template » en bleu, « Ticket template » en vert.

Un modèle de réponse se compose du texte de la réponse (« Reply text »), de la case « Internal note » et d'un nombre libre d'actions. Il y a six actions : « Set the status », « Set the priority », « Assign to a user », « Remove the assignee », « Hand over to another team » et « Set a follow-up ».

La liste « Assign to a user » commence par l'entrée « The agent who applies it ». Prends celle-ci quand plusieurs personnes partagent le modèle : le ticket appartient alors à la personne qui l'a appliqué, et non à une personne fixe de la liste. « Set a follow-up » demande une quantité et une unité (minutes, heures, jours, minutes ouvrables, heures ouvrables, jours ouvrables), plus la note qui te dira plus tard pourquoi le ticket est revenu.

L'encadré bleu à la fin de chaque modèle écrit en une phrase ce qu'il va faire, par exemple « Inserts the text as a public comment, sets status to Waiting for Service Provider Response, assigns to the applying agent, sets a follow-up in 3 days. » La phrase se reconstruit pendant que tu modifies. C'est ta contre-vérification : si elle dit autre chose que ce que tu avais en tête, un réglage est faux.

Le texte n'est pas obligatoire. « Transmettre ceci à l'équipe réseau sans écrire un mot » est un modèle valable. La phrase se lit alors « Suggests actions without a reply text ». L'action « Set the status » suit les mêmes règles qu'un changement de statut à la main. Appliqué à plusieurs tickets à la fois, le modèle ignore les tickets verrouillés et en donne la raison.

La fenêtre « Close ticket » propose aussi des modèles de réponse, dans le champ « Template ». Elle ne liste que les modèles dont l'action active « Set the status » définit un statut qui compte comme résolu ou fermé. Les modèles internes n'y sont pas proposés. Si tu en choisis un, la fenêtre reprend son texte comme commentaire. Si le modèle envoie un e-mail et que la fenêtre propose l'envoi d'e-mails, elle ne reprend le destinataire que s'il s'agit de « Requester » ou d'une adresse fixe. Les autres actions du modèle ne s'exécutent pas à cet endroit, et ses pièces jointes ne sont pas ajoutées. Le ticket est fermé comme d'habitude.

Sur un ticket ouvert, le bouton « Template » se trouve au-dessus de l'éditeur de commentaire. Un clic ouvre la recherche instantanée (« Search templates… »), et le choix d'un modèle remplit l'éditeur de commentaire. Rien d'autre ne se passe, et la ligne en dessous le dit : « Nothing happens until you add the comment. »

Chaque action du modèle devient une pastille à côté du bouton, en mots simples et non en jargon : « sets status to Waiting for Service Provider Response », « assigns to the applying agent », « sets a follow-up in 3 days ». Cliquer sur une pastille la barre : elle est retirée et ne s'exécutera pas. Un autre clic la ramène.

Les actions retirées sont barrées, pas supprimées. Cela laisse visible ce que le modèle aurait proposé, et cela garde la décision réversible tant que tu n'as pas envoyé.

Les pastilles actives au départ sont décidées par le modèle : dans les paramètres, chaque action porte un interrupteur « Suggested ». Cet interrupteur est la proposition pour tous les cas ; la pastille sur le ticket est la décision pour celui-ci.

Le « × » derrière les pastilles retire de nouveau le modèle. Le texte reste dans l'éditeur, tu l'as peut-être déjà réécrit. Seul l'effet disparaît, c'est-à-dire les actions, le message et les pièces jointes.

Tu envoies avec le bouton de commentaire habituel. C'est seulement alors que le commentaire est créé, et c'est seulement après que s'exécutent les actions encore actives.

Le texte de la réponse peut utiliser cinq variables ; la liste se trouve sous le champ : « {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName} ». Écris-les avec des accolades, exactement comme elles apparaissent là.

« {ticketRef} » est la référence du ticket sous la forme « [TICKET-8-…] ». C'est à elle que le système reconnaît la réponse d'un client quand elle revient par courrier électronique. « {ticketId} », en revanche, n'est que le numéro nu.

Elles sont résolues au moment où le modèle est APPLIQUÉ, pas à l'enregistrement : la page des paramètres continue d'afficher « {requesterName} », l'éditeur de commentaire sur le ticket affiche le vrai nom. La raison est pratique : résoudre à l'enregistrement graverait pour de bon dans le modèle les valeurs d'UN seul ticket.

Tu lis ainsi le texte terminé avant que quoi que ce soit ne quitte l'entreprise. Si la formule d'appel ne convient pas, tu la changes dans l'éditeur comme n'importe quel autre texte.

Qui compte comme « demandeur » est décidé par le ticket, pas par le compte : le demandeur enregistré sur le ticket passe avant le compte qui l'a déposé. Si un agent dépose un ticket pour un collègue après un appel téléphonique, la réponse salue quand même le collègue et non l'agent.

Une variable mal écrite est refusée à l'enregistrement, et elle est nommée : « Reply text: unknown placeholders {requesterNam}. Available here: {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}. » Tu la remarques donc en écrivant le modèle, pas sur un client.

L'objet de l'e-mail a sa PROPRE liste, plus courte (« {originalSubject}, {ticketTag}, {ticketId} »), c'est pourquoi elle y est imprimée une seconde fois. « {ticketRef} » y fonctionne aussi et signifie la même chose que « {ticketTag} ». « {requesterName} », « {ticketTitle} » et « {agentName} » ne fonctionnent pas dans l'objet et sont refusées de la même façon.

L'interrupteur « Send the comment as e-mail » fait aussi du commentaire le message. Il n'y a volontairement pas de second champ de texte pour cela : ce qui est dans le ticket est ce que le client lit. Deux textes finiraient tôt ou tard par diverger.

Sous « Recipient », tu choisis entre « Requester », « Assignee », « Observers » et « Fixed address ». L'identité du demandeur est résolue par le serveur au moment où le modèle est appliqué : un modèle ne connaît pas encore le ticket. On n'écrit jamais au compte de la boîte de réception elle-même, ce serait un message à nous-mêmes. Si le champ « User » contient un nom sans adresse, aucun message ne part vers le demandeur. Il n'est pas non plus envoyé à la place à la personne qui a saisi le ticket.

L'objet peut porter « {originalSubject} », « {ticketTag} » et « {ticketId} ». Garde « {ticketTag} » dedans : c'est à cette référence que le système reconnaît la réponse du client et l'ajoute au même ticket. Sans elle, chaque réponse devient un nouveau ticket.

Le message part en texte simple. Le gras, les listes et les liens sont retirés avant l'envoi, sinon le client lirait le balisage brut. À l'intérieur du ticket, le commentaire garde sa mise en forme.

Sur le ticket, le message est une pastille de plus à côté des actions (« E-mail to Requester ») et se retire aussi facilement qu'elles. Un modèle n'envoie donc jamais rien sans que tu l'aies vu. La pastille n'apparaît que si la boîte aux lettres de l'équipe envoie les messages liés aux actions de ticket.

Les pièces jointes d'un modèle (« Attachments ») sont ses propres copies des fichiers. Appliquer le modèle les ajoute au TICKET, avec leur propre ligne dans l'historique ; elles ne font pas partie du message. Porter des pièces jointes sur un modèle ne demande aucune licence Professional, seul l'envoi en demande une. Un modèle avec la case « Internal note » cochée n'ajoute aucun fichier.

La plupart des modèles ne naissent pas sur une planche à dessin, mais au moment où tu écris la même réponse pour la deuxième fois. C'est pourquoi chaque commentaire d'un ticket porte à droite une petite icône de feuille, intitulée « Make template ». Elle prend exactement ce commentaire comme texte de départ, y compris le commentaire d'un collègue. Seules les personnes qui peuvent gérer les modèles voient l'icône.

Si le ticket a des pièces jointes, une boîte de dialogue demande d'abord lesquelles doivent suivre : « Tick only the attachments the template should carry — one of them may be a customer's screenshot. Nothing is ticked by default. » Rien n'est coché d'avance, et c'est voulu.

Ensuite, tu arrives sur la page des modèles avec un brouillon qui n'est PAS encore enregistré. En haut se trouve la bannière orange « Draft from ticket #… — name it and review the text (it may contain customer details), then save. » Le nom est vide : tu dois en donner un, sinon il ne s'enregistre pas.

Ce qui est repris : le texte, la case « Internal note », l'équipe du ticket, et l'état du ticket comme proposition ; son statut et sa priorité sont déjà là sous forme de deux actions. Ce qui n'est pas repris : le demandeur, l'adresse et le titre. Ceux-ci appartiennent à ce seul dossier.

Lis le texte avant d'enregistrer. Il vient d'un vrai dossier et peut contenir le nom d'une personne, un numéro de commande ou un local. Rien n'est anonymisé pour toi. La bannière le dit, mais le faire est ton travail.

Seul « Save » crée le modèle ; les pièces jointes cochées sont alors copiées et un message le confirme.

« Applies to » décide à qui le modèle est proposé : une équipe précise ou « All teams ». Un nouveau modèle commence avec une équipe concrète ; « All teams » est un choix que quelqu'un doit faire, pas un réglage par défaut silencieux.

Sur un ticket, on te propose les modèles de l'équipe propriétaire et les modèles globaux. Si le ticket passe à une autre équipe après une transmission, la liste suit : ce sont les modèles de la nouvelle équipe que tu peux choisir.

L'interrupteur « Draft » fait du modèle ton atelier : « Only you can see this template until you publish it. » Le brouillon de quelqu'un d'autre n'apparaît dans aucune liste et n'est pas non plus joignable par son adresse, pas même par les administrateurs. Un nouveau modèle commence comme brouillon ; c'est seulement quand tu désactives cela et que tu enregistres que les autres le voient.

Deux modèles ne peuvent pas porter le même nom s'ils peuvent se croiser : un modèle global entre en conflit avec tout modèle du même nom, dans n'importe quelle équipe. Un modèle de réponse et un modèle de ticket peuvent en revanche porter le même nom, ils n'apparaissent jamais côte à côte dans la même liste.

« Duplicate » fait une copie, et la copie est toujours un brouillon : « Duplicated. The copy is a draft only you can see. » C'est la voie confortable vers une variante sans que la version à moitié faite soit proposée à quelqu'un d'autre.

Un modèle de ticket remplit le formulaire « Create new ticket ». Il n'a pas de texte de réponse, pas d'actions et pas de message : à ce moment-là, il n'y a aucun ticket sur lequel agir. Le formulaire montre donc d'autres champs que pour un modèle de réponse, et le cadre vert te dit que tu as un modèle de ticket sous les yeux.

Tu peux préremplir « Ticket title », « Owning team of the new ticket », « Main category », « Subcategory », « Priority » et la « Ticket description ». Chaque champ peut rester sur « Not prefilled » ; ce qui reste vide est rempli plus tard par la personne qui utilise le formulaire.

Fais attention à la différence entre les deux champs d'équipe : « Applies to » en haut dit QUI voit le modèle. « Owning team of the new ticket » dit OÙ va le nouveau ticket. Ce sont deux questions différentes, et elles peuvent avoir des réponses différentes.

Les catégories sont regroupées par équipe, parce qu'une catégorie appartient à une équipe. Si tu en choisis une d'une autre équipe, le formulaire te le dit et l'enregistrement est refusé : sur le formulaire de nouveau ticket de l'équipe cible, cette catégorie ne serait pas proposée du tout, le préremplissage n'aboutirait donc à rien.

Il n'y a pas de variables ici, et l'indication sous le texte le dit : « No placeholders here: the template only prefills the form, nothing is resolved or sent. » Un « {requesterName} » se retrouverait tel quel dans le nouveau ticket, c'est pourquoi il est refusé à l'enregistrement.

L'encadré bleu résume ici aussi ce que fait le modèle : « Prefills the new ticket with title 'New notebook for a colleague' · category Notebook / New request · priority Medium · team Helpdesk · the description. »

Sur le formulaire lui-même, tu choisis le modèle avec le bouton « Template » ; à côté figure « Prefills the form - nothing is created until you submit. » Tout ce qui est prérempli peut encore être changé, et rien n'est créé tant que tu n'as pas envoyé.

Un modèle d'exemple est livré avec le système : « Example: create accounts for a new colleague ». Il montre la forme de la chose et ne fait rien de lui-même. Reconstruis-le ou supprime-le.

L'interrupteur « Offer this template to customers » est désactivé au départ. L'indication à côté dit les deux choses à savoir : « Customers can pick this template when they create a ticket. A draft stays hidden either way. »

Pourquoi il est désactivé par défaut : un modèle porte souvent un nom en vocabulaire interne et est écrit pour des collègues. Le rendre visible aux clients est une prise de parole vers l'extérieur ; quelqu'un doit le faire délibérément, pas par accident.

Le client voit le même bouton « Template » au-dessus du formulaire de nouveau ticket, mais seulement les modèles ouverts. Un brouillon reste caché même avec l'interrupteur activé : les deux règles se suivent, elles ne sont pas côte à côte.

L'enjeu n'est pas le confort, c'est le premier contact : une demande qui arrive complète évite l'échange de questions qui coûterait sinon deux jours. Mets ces questions dans la description du modèle, le client y répond en créant le ticket.

Tu peux aller plus loin avec « Fields to ask for ». Le modèle décide alors des champs personnalisés que le formulaire demande, dans quel ordre, et lesquels sont obligatoires. Cette sélection REMPLACE les champs habituels de l'équipe, elle ne s'y ajoute pas. C'est précisément son but. Les champs personnalisés eux-mêmes font partie de Professional ; leur carte s'appelle « Champs personnalisés ». Ouvrir un modèle aux clients fonctionne dans toutes les éditions.

Un champ caché aux clients reste caché, même si un modèle le liste. La sélection de champs est un outil d'ordre et de découpe, pas un moyen de contourner les réglages des champs.

Chaque utilisation qui fait plus qu'insérer du texte écrit UNE entrée dans l'historique, sous le nom de champ « Template ». Elle nomme le modèle. Les actions exécutées écrivent leurs propres lignes. Sans cela, il n'y aurait aucun moyen d'expliquer plus tard pourquoi un ticket est soudain passé à « In Progress » : les actions individuelles écrivent bien leurs propres lignes, mais aucune ne nomme le modèle.

L'image se lit ainsi : « Template ‘First reply: we have your ticket’ applied ». Ce que le modèle a fait figure dans les lignes de ses propres actions, comme le changement de statut.

Les actions retirées n'y figurent pas : elles n'ont pas eu lieu. Un échec y figure, et il est nommé comme tel, derrière le mot « failed ». Un modèle de texte seul, sans actions, message ni pièces jointes, ne laisse aucune entrée « Template » sur un ticket isolé. Il n'a fait qu'insérer du texte. Appliqué à plusieurs tickets à la fois, l'entrée est toujours écrite, avec la ligne interne « Bulk ».

L'entrée est INTERNE, le demandeur ne la voit pas. Le nom d'un modèle est du vocabulaire interne (« refus standard »), et l'historique est ouvert aussi à la personne qui a créé le ticket. Les changements de champs eux-mêmes lui restent visibles ; seule leur origine dans un modèle ne l'est pas.

L'auteur est l'agent, pas « system » ni le modèle. C'est voulu : l'appliquer était sa décision. Contrairement à une règle d'automatisation, ce qui figure ici sur le ticket est une personne.