Gestion des tickets

Tu crées un nouveau ticket avec « New Ticket » dans la barre de gauche. Le formulaire s'appelle « Create new ticket ». En tant qu'agent, tu enregistres aussi les demandes des autres avec lui. C'est à cela que sert le champ « User » : il dit pour qui est le dossier, pas qui le saisit.

Tout ce qui porte une étoile est obligatoire : « Title », « User », « Main category » et « Description ». Il y en a un de plus, facile à manquer : le formulaire ne s'enregistre pas sans sous-catégorie, même si « Subcategory » ne porte pas d'étoile. Une catégorie principale et une sous-catégorie vont ensemble et se règlent toujours par paire.

Les champs obligatoires se règlent sous « Settings → Ticket Settings ». La carte « Admin / Agent Field Settings » n'a pour cela que l'interrupteur « Field is mandatory ». La carte « Customer Field Settings » a en plus « Is hidden for Customer » et « Is not editable ». C'est pourquoi un client peut voir un formulaire plus court que le tien, sans que personne ait à entretenir deux formulaires. « Title » et « Description » sont toujours obligatoires. Cela ne peut pas être désactivé.

Ensuite, tu peux presque tout changer : à droite du ticket se trouve la carte « Details » avec le demandeur, le téléphone, l'adresse e-mail, le site, la catégorie et le numéro de référence. Tu modifies le champ lui-même et tu confirmes avec le « Save » en dessous. Le statut, l'attribution, la priorité, le canal et les observateurs se trouvent une carte plus haut sous « Actions ». Le statut et l'attribution prennent effet immédiatement. La priorité, le canal et les observateurs ne sont enregistrés qu'avec le « Save » de la carte « Details ».

Seuls les agents et les administrateurs peuvent changer cela. Le demandeur peut lire le dossier, le commenter et y joindre des fichiers, mais pas modifier la classification sur laquelle tes rapports sont construits.

Un effet à connaître une fois pour toutes : si tu modifies un ticket qui n'appartient encore à personne, il est ensuite à toi. Le système t'inscrit comme agent et fait passer le statut de « Open » à « Assigned », les deux se retrouvent dans l'historique. Si tu ne voulais pas cela, attribue-le ensuite à quelqu'un d'autre.

Chacun de ces changements arrive dans l'historique du ticket, avec le nom, l'heure, l'ancienne valeur et la nouvelle. Tu n'as rien à activer pour cela.

Reste la question de savoir comment se débarrasser des tickets. Sous « Settings → Archive », tu choisis une période, tu vois avec « Preview » combien de tickets fermés elle contient, et tu crées un fichier ZIP avec « Create archive » : tickets, commentaires, historique, champs personnalisés et pièces jointes, le tout dans un seul fichier. Le créer ne supprime rien. Les tickets ne quittent la base de données en fonctionnement qu'avec l'étape à part « Delete from live DB » dans la liste « Existing archives », et ils peuvent être restaurés depuis ce même fichier.

La description et les commentaires ne sont pas de simples zones de texte. Chacune a une barre d'outils au-dessus, et les boutons disent ce qu'ils font quand tu les survoles : « Bold », « Italic », « Underline », « Strikethrough », « Text color », « Highlight color », « Bullet list », « Numbered list », « Quote », « Link » et « Clear formatting ».

Voici comment on fait un lien : sélectionne le texte, clique sur « Link », saisis l'adresse dans la petite invite. Une saisie vide retire le lien. Les adresses web et de messagerie sont autorisées (http, https, mailto). Tout le reste est écarté à l'enregistrement, pour qu'un commentaire ne puisse rien faire passer à personne.

Les images passent par le presse-papiers : fais une capture d'écran et colle-la directement dans l'éditeur avec Ctrl+V. Au début, le texte n'affiche qu'un marqueur comme « [inline-image:1] ». À l'enregistrement, le système envoie l'image et l'affiche exactement là. Elle arrive aussi dans l'onglet « Attachments », où se trouvent tous les fichiers du dossier. Coller des images fonctionne dans la description d'un ticket existant et dans un nouveau commentaire. Cela ne fonctionne pas dans le formulaire « Create new ticket » ni pendant que tu modifies un commentaire.

Ce que tu vois est ce que les autres voient : la mise en forme, les listes et les liens sont conservés dans le ticket, et dans le message au demandeur également. Le balisage étranger, venu par exemple d'une page web copiée ou d'un e-mail entrant, est ramené à cet ensemble autorisé. Rien de ton texte n'est perdu au passage, seulement l'emballage.

Un commentaire peut être marqué comme interne avec « Internal note (not visible to the customer) ». Il porte alors la pastille « Internal » et est invisible pour le demandeur. Même la recherche ne le fait pas apparaître.

Chacun peut modifier et supprimer ses propres commentaires. Ce qu'un client a écrit ne peut être modifié ou supprimé que par ce client ou par un administrateur. Cela inclut ses e-mails. Les commentaires des collègues peuvent être modifiés et supprimés par tout agent qui peut travailler sur le ticket. Cela inclut une équipe qui avait le ticket auparavant.

Les fichiers appartiennent au dossier, pas à un commentaire isolé. Sur le ticket, l'onglet « Attachments » mène à la liste : « Upload file » en ajoute un, chaque ligne nomme le fichier, sa taille et sa date. Toute personne impliquée dans le ticket peut joindre quelque chose, le demandeur compris. Personne n'a donc besoin de t'envoyer sa capture d'écran par courrier électronique. Un client ne peut supprimer que les pièces jointes qu'il a envoyées lui-même. Quand un sous-ticket est fermé, ses pièces jointes sont copiées dans le ticket principal, où elles portent la pastille « Internal ». Les agents les voient ; les clients ne les voient pas et ne les téléchargent pas.

Un clic sur le nom ouvre l'aperçu, sans que tu doives télécharger le fichier. Pour les images, tu peux y agrandir, réduire et pivoter, ce qui est utile pour un écran photographié de biais. Un PDF s'affiche dans la même fenêtre, avec l'aperçu des pages, le zoom et l'impression. Les fichiers texte sont affichés comme du texte. Avec « Open in new tab », tu ouvres le fichier dans une fenêtre à part.

Une pièce jointe appartient au dossier et le suit : elle apparaît dans l'historique (« File uploaded: … »), survit à une transmission vers une autre équipe, et se retrouve dans le fichier d'archive quand le ticket est archivé.

L'onglet « History » du ticket répond à la question qui se pose à chaque reprise : qui a changé quoi, et quand ? Chaque ligne nomme la personne, le champ, l'ancienne valeur barrée, la nouvelle derrière et l'heure à la seconde près. L'entrée la plus récente est en haut.

Les entrées s'écrivent sans que tu fasses rien : lors des changements de statut, de priorité, d'attribution, de catégorie, de site, d'observateurs, de titre et de description, ainsi qu'à la création (« Ticket opened »), à chaque commentaire et à chaque fichier envoyé. Le nombre sur l'onglet te dit à l'avance combien de mouvement il y a eu dans le dossier.

L'historique ne peut pas être modifié ni désactivé. C'est exactement ce qui le rend utile : c'est la raison pour laquelle un ticket ne peut pas être supprimé un par un, et il part dans le fichier d'archive quand le ticket est archivé.

Pour un commentaire, l’historique enregistre seulement qu’il a été ajouté, modifié ou supprimé. Le texte se trouve dans l’onglet « Comments ». Un commentaire interne apparaît lui aussi dans l’historique, mais seulement pour les agents et les administrateurs.

Le statut dit où en est un ticket. Douze statuts sont livrés avec le système : Open, Assigned, In Progress, Waiting for User Response, Resolved, Closed et d'autres. Tu les trouves sous « Settings → General Settings » dans la section « Drop-down lists », derrière l'onglet « Status ». « + Add status » en crée un à toi, « Edit status » en ouvre un existant.

Le point important est la différence entre le nom et la signification. Dans l'éditeur d'un statut, sous « Meaning of this status », il y a trois interrupteurs : « Counts as resolved », « Counts as closed » et « Waiting for the requester ». Seuls ces interrupteurs disent au système comment traiter un statut.

Tu peux renommer chaque statut, y compris ceux livrés avec le système : en bas de l'éditeur, sous « Translations », il y a un champ « Name » par langue. Mets-y ce que tes collègues doivent lire. Le nom technique derrière reste intact, et c'est justement pour cela que rien ne casse : l'automatisation, les rapports et les interrupteurs au-dessus se rattachent à ce nom, pas à ton étiquette. « Resolved » peut donc devenir « Terminé ».

La suppression, en revanche, ne fonctionne pas pour tous. Huit statuts portent la pastille « Mandatory » dans la liste : Open, Assigned, In Progress, Resolved, Closed, Reopened, Waiting for approval et Rejected. Ils peuvent être renommés et réordonnés, mais pas supprimés ; un essai se termine par un message clair. Ce n'est pas là pour t'embêter : des processus s'y rattachent qui s'arrêteraient sinon sans un mot, par exemple la fermeture automatique, qui a besoin d'un statut « résolu » comme point de départ.

Deux statuts appartiennent au système lui-même : « Waiting for approval » et « Rejected » portent la pastille « System only ». Ils viennent d'un processus d'approbation, et personne ne doit pouvoir affirmer à la main que quelque chose a été refusé alors que rien n'a jamais été soumis à décision.

Ce que font les trois : un statut qui compte comme résolu ferme le ticket de lui-même au bout de 24 heures. Un statut qui compte comme fermé est l'état final dans lequel le ticket est placé. Et « Waiting for the requester » veut dire exactement cela : nous attendons le demandeur, pas une autre équipe et pas un prestataire. C'est le drapeau sur lequel l'horloge du SLA s'arrête, si tu l'as réglé ainsi.

En dessous se trouve « Allowed transitions to new status ». Tu y coches les statuts qui peuvent être atteints depuis celui-ci. Laisse tout vide et rien n'est limité ; coche quelque chose et tous les autres chemins sont fermés. C'est ainsi qu'on construit un déroulé qu'on ne peut pas sauter, par exemple : depuis « Open », on ne peut aller que vers « In Progress » ou « Assigned », mais pas directement vers « Closed ».

Les autres interrupteurs de l'éditeur sont de petites choses au grand effet : la couleur pour la liste, « Sort order » pour l'ordre, « Show status in new ticket form » (ce statut doit-il pouvoir être choisi à la création d'un ticket ?), « Requires comment in dialog » (imposer un motif) et « System only » pour les statuts que seul le système peut poser.

Jusqu'à quatre statuts apparaissent sur le ticket sous forme de boutons sous « Change Status to: ». Tu les choisis dans l'éditeur avec l'interrupteur « Set as primary status (max. 4) ». Dans le réglage d'usine, ce sont In Progress, Waiting for User Response, Waiting for Service Provider Response et Resolved. Tous les autres statuts se trouvent sous « More statuses ».

Tout ce qui apparaît comme liste déroulante dans un ticket t'appartient. Sous « Settings → General Settings » se trouve la carte « Drop-down lists » avec six onglets : « Department », « Position », « Location », « Role », « Status » et « Priority ». La manipulation diffère d'une liste à l'autre.

Une par une : saisis le nom anglais dans le champ vide et clique sur le bouton à côté. Il porte le nom de la liste, donc « + Add location », « + Add department » et ainsi de suite. Les lignes en dessous sont les entrées existantes. Dans « Department », « Position » et « Location », c'est là que tu changes un nom et que tu confirmes avec le « Save » à côté.

Pour beaucoup d'entrées à la fois, « Department », « Position » et « Location » proposent aussi « Export JSON » et « Import JSON ». Sur un système fraîchement installé, tu télécharges la structure vide avec « Export JSON », tu la remplis et tu la réimportes. Ce n'est pas un moyen de renommer, la carte le dit elle-même.

Certaines entrées portent la pastille « Mandatory ». Les trois rôles « Admin », « Agent » et « Customer » en font partie, huit des statuts livrés avec le système, et un emplacement de remplacement dans chacune des listes Location, Position et Department (« None selected or available »). Aucune ne peut être supprimée : des autorisations et des processus s'y rattachent qui s'arrêteraient sinon sans un mot. Les statuts peuvent quand même être renommés dans leur éditeur. Les rôles et les emplacements de remplacement ne peuvent pas être renommés. Ce qui est permis dépend de la liste. « Role » est verrouillée : un rôle ne peut être ni ajouté ni renommé. Dans « Priority », tu ajoutes et supprimes des entrées, mais il n'y a ni fichier ni renommage. « Status » a son propre éditeur et pas de fichier non plus.

Tu ne traduis pas ici dans les autres langues, mais en une seule fois sur la page de traduction. Le nom anglais suffit ici, c'est l'ancre à laquelle les traductions se rattacheront plus tard.

Le statut est la seule entrée à posséder son propre éditeur, parce qu'il y a plus qu'un nom qui s'y rattache. Il a sa propre carte plus bas.

Les catégories sont ce que le demandeur ou l'agent choisit à la création d'un ticket, et ce selon quoi tu regroupes ensuite tes rapports. Chaque équipe a les siennes : un helpdesk trie selon d'autres critères qu'un service réseau, et aucun des deux ne voit les listes de l'autre.

Tu les trouves sous « Settings » à l'entrée « <nom de l'équipe> Categories ». Dans l'exemple, l'équipe s'appelle « Helpdesk », l'entrée se lit donc « Helpdesk Categories ».

La page a trois cartes : « Main categories », « Subcategories » et « Links ». Le démarrage le plus rapide : saisis le nom anglais dans le champ « EN (required) » et clique sur « + New main category » ou « + New subcategory ». Tu traduis tout plus tard en une seule fois sur la page de traduction, il n'y a rien à préparer ici pour cela.

Si beaucoup de catégories t'attendent, prends la voie du fichier : « Export JSON » télécharge la structure. Sur un système fraîchement installé, le fichier est vide et ne fait que te montrer la disposition. Tu le remplis, à la main ou avec l'aide d'une intelligence artificielle, tu l'enregistres et tu le renvoies par « Import JSON ». Ce n'est pas un moyen de renommer : tu changes un nom dans le champ de la catégorie concernée et tu confirmes avec le « Save » à côté, la page le dit également.

La troisième carte, « Links », est là où se fait le vrai travail. Choisis une catégorie principale en haut, coche en dessous les sous-catégories qui lui appartiennent, et enregistre avec « Save links ». L'astuce : une sous-catégorie peut se rattacher à plusieurs catégories principales. Tu n'as donc besoin de « Malfunction » qu'une fois et tu la réutilises pour Printer, Network, Meeting-Room et Notebook.

À partir de là, les catégories sont disponibles dans le ticket. La suppression peut échouer tant que des tickets utilisent encore une catégorie. C'est voulu, sinon d'anciens tickets perdraient leur classification. Si tu retires une liaison, les tickets qui utilisent ce couple peuvent toujours être enregistrés. Seule une catégorie nouvellement choisie est vérifiée par rapport aux liaisons.

Si tu transmets un ticket à une autre équipe, sa classification reste, même quand la nouvelle équipe n'a pas du tout ces catégories. Elle figure alors dans le champ avec son origine, par exemple « Meeting-Room · from Helpdesk », et elle est grisée : la nouvelle équipe voit sous quoi le dossier a couru jusque-là, mais ne peut pas attribuer cette entrée elle-même. Pour le reclasser, tu choisis dans ta propre liste, et le système veut alors une catégorie principale et une sous-catégorie ensemble.

Chaque ticket porte un canal. Il se trouve dans le formulaire, puis sur la carte « Actions » sous « How the request came in », et il répond à une question qui devient vite importante dans les rapports : le travail arrive-t-il par le portail ou par téléphone ?

Tu ne peux choisir que ce qu'une personne sait et que le système ignore : « Phone » et « Entered by an agent ». Les deux autres valeurs sont posées par le système lui-même : « Self-service » quand le demandeur a créé le ticket dans le portail, et « E-mail » quand il est né d'un message entrant. Quand un agent crée un ticket, le formulaire commence avec « Entered by an agent ».

Un canal posé par le système ne peut plus être modifié par personne après coup. Le champ indique alors « Recorded by the system. It cannot be changed. » Sinon, le champ perdrait justement l'information pour laquelle il existe. Dans l'autre sens, sur un ticket enregistré par téléphone, tu peux encore tout changer.

Seuls un agent ou un administrateur peuvent poser le canal. Pour le demandeur, ce serait une affirmation sur son propre dossier, et les rapports dépendraient de l'honnêteté de chacun.

« E-mail » exige une boîte aux lettres connectée, qui fait partie de l'édition Professional. Les trois autres canaux existent dans les deux éditions.

Au-dessus de chaque liste de tickets se trouve le champ « Search tickets… ». Il ne cherche pas seulement dans les titres, mais dans tout le dossier : le titre, la description, le nom du demandeur, son adresse e-mail et son numéro de téléphone, le site, le numéro de ticket de référence, tous les commentaires et les valeurs textuelles de tes propres champs personnalisés.

L'exemple le montre : « coffee » n'apparaît dans aucun titre, seulement dans la description d'un ticket, et il est trouvé quand même. Tu n'as donc pas à te rappeler comment un ticket a été intitulé ; un mot du dossier suffit.

Les majuscules et les minuscules n'ont pas d'importance. La recherche porte toujours sur la liste dans laquelle tu te trouves et se combine avec « Filter » à côté ; « Reset » efface de nouveau la recherche et les filtres. La liste retient tes filtres, séparément pour chaque liste d'équipe. Ils sont toujours là quand tu reviens d'un ticket, recharges la page ou te connectes sur un autre ordinateur. Le texte de recherche, lui, n'est pas retenu. Pour les clients, il y a une limite invisible qu'il faut connaître : ils ne cherchent pas dans les commentaires internes, sinon ils pourraient déduire de la liste des résultats ce qui a été discuté en interne. Ils ne cherchent pas non plus dans les champs personnalisés masqués pour les clients.

Chacun compose sa propre liste de tickets. Pour cela, le bouton « Columns » se trouve à côté de « Filter ». Il ouvre la boîte de dialogue « Choose columns ».

Dans la boîte de dialogue, tu coches chaque colonne que tu veux voir. Les flèches à côté fixent l'ordre. « # » et « Title » sont toujours inclus. Tu changes la largeur d'une colonne dans la liste elle-même, en faisant glisser le bord de son en-tête.

« Save » enregistre ton choix avec ton compte utilisateur. Il s'applique donc sur chaque ordinateur et reste après ta déconnexion. « Default columns » remet la liste dans son réglage d'usine.

Quand la place manque pour toutes les colonnes, celles tout à droite disparaissent en premier. « # », « Title » et « Status » restent toujours. Tu places donc devant ce qui compte le plus pour toi.

Avec Professional, tes champs personnalisés sont aussi proposés. Ils apparaissent dans la boîte de dialogue sous leur propre nom, ici par exemple « Asset tag ».

Les clients peuvent organiser leur liste de la même façon, mais on leur propose moins de colonnes. « Team », « Created by », « Last activity », « Status changed at », « Deadline », « Follow-up » et « Time » ne sont pas disponibles pour eux. Les champs que tu as cachés aux clients n'apparaissent pas non plus comme colonne.

Sur un téléphone, le bouton n'est pas affiché. La liste y montre les colonnes qui tiennent.

Le ticket propose deux boutons côte à côte pour cela, et la différence est imprimée en dessous en petits caractères. « Involve another team » : tu restes responsable, l'autre équipe travaille à tes côtés dans un ticket lié. « Escalate to another team » : l'autre équipe prend le relais.

Quand tu transmets, la responsabilité change de mains sans qu'un second ticket naisse. Ton équipe garde l'accès en lecture et peut encore commenter, mais ne peut plus rien changer, ce que la boîte de dialogue te dit exactement avant que tu confirmes. Tu y choisis l'équipe cible et tu peux ajouter un motif.

Quand tu associes une équipe, ton ticket reste entre tes mains et reçoit un sous-ticket dans l'autre équipe. Le tien passe au statut « Waiting for other team » ; dès que l'autre équipe ferme le sien, le tien revient en « Back from other team ». Tu n'as donc pas à demander s'il s'est passé quelque chose là-bas. Les pièces jointes du sous-ticket sont copiées dans ton ticket avec la pastille « Internal », et le client ne les voit pas.

Quant à la classification : les catégories de l'équipe qui transmet restent sur le ticket, même quand la nouvelle équipe ne les a pas du tout. Elles y apparaissent avec leur origine, en grisé. Ainsi, la nouvelle équipe voit sous quoi le dossier a couru jusque-là et peut le reclasser dans sa propre liste si besoin.

Seule la personne responsable à l'instant peut transmettre un ticket. Une étape précédente voit encore le dossier mais ne peut pas le transmettre une seconde fois. Elle peut commenter, mais ne peut pas reprendre le ticket pour elle-même.

Dans la liste de ton équipe, le ticket affiche alors « Waiting for other team » tant que l'autre équipe travaille dessus. La case « Also show tickets this team handed over » est cochée comme réglage d'usine, et le choix propre à chaque utilisateur est conservé. Pour l'autre équipe, le ticket commence en « Open ».

Qui transmet le ticket en devient observateur. La boîte de dialogue le dit avant que tu confirmes. En tant qu'observateur, tu reçois un e-mail quand le statut change, quand le ticket est fermé ou quand quelqu'un commente. Comme tout observateur, tu te retires avec « Stop observing ».

Quand une information manque à tes tickets, le numéro d'inventaire, la fin de la garantie, le centre de coûts, tu l'ajoutes toi-même. Sous « Settings → Ticket Settings », tout en bas, se trouve la carte « Custom fields » ; le bouton s'appelle « Add custom field ».

Dans la boîte de dialogue, tu donnes un nom et un type de champ : « Text », « Multiline text », « Integer », « Decimal », « Date » ou « Yes / No ». Le type décide de ce qui peut être saisi. Un champ de date n'acceptera pas « la semaine prochaine », et c'est justement pour cela que tu pourras en faire un rapport plus tard.

Sous « Scope », tu décides où le champ s'applique : « All teams (including new ones) » ou « Selected teams only ». Le premier choix couvre aussi les équipes qui n'existent pas encore, le genre de différence qu'on ne remarque qu'un semestre plus tard.

Les trois interrupteurs sous « Defaults » sont « Mandatory by default », « Hidden for customer by default » et « Not editable by customer by default ». Ils ne s'appliquent à un champ que tant que rien n'a été enregistré pour ce champ dans les réglages du champ sur la même page. Dès que tu le règles là, ce sont les réglages du champ qui décident.

Sur le ticket, les champs personnalisés se trouvent dans une carte à part, « Additional information », entre la description et les commentaires. Sans modèle, le formulaire montre tous les champs personnalisés de l'équipe. Si tu choisis un modèle à la création d'un ticket, il montre exactement les champs que ce modèle liste, dans son ordre : « seulement les champs dont ce dossier a besoin ».

Un modèle peut en plus rendre un champ obligatoire. Ce que l'administrateur a caché aux clients reste caché, même quand un modèle le liste. Un champ obligatoire qu'un modèle ne liste pas n'est pas demandé, cette exigence ne s'applique donc pas aux tickets créés avec ce modèle.

Le nombre de champs personnalisés qu'une équipe peut avoir se règle sous « Settings → General Settings » dans la carte « Custom fields limit ». Tu te débarrasses d'un champ avec « Deactivate » : il disparaît du formulaire, mais ses valeurs restent sur les anciens tickets. L'interrupteur « Show deactivated » le ramène dans la liste.

Parfois, quelqu'un doit suivre un dossier sans y travailler : le responsable d'équipe sur une affaire délicate, le collègue qui reprend la semaine prochaine. C'est à cela que servent les observateurs. Sur le ticket, le champ « Observers » se trouve sur la carte « Actions », le bouton s'appelle « Add observer » ; le formulaire « Create new ticket » a le même champ. Sur le ticket, un changement à cet endroit est enregistré avec le « Save » de la carte « Details ».

Seuls les agents et les administrateurs de l'équipe à laquelle appartient le ticket peuvent être choisis. Un client ne peut pas être observateur, il recevrait sinon des messages sur le travail interne.

Un observateur reçoit un e-mail quand quelque chose se passe sur le ticket : un nouveau commentaire, un statut modifié, une nouvelle attribution, des champs modifiés. L'envoi n'est pas immédiat mais groupé : après le dernier changement, le système attend une minute et envoie ensuite UN message qui couvre tout ce qui s'est passé pendant ce temps. Traiter un ticket d'une traite ne déclenche donc pas sept messages. Si plusieurs commentaires arrivent pendant ce temps, ils figurent tous dans le message.

Qui observe fait partie de l'historique : un changement est consigné comme n'importe quel autre, avec l'ancien et le nouvel état.

Saisir des observateurs fait partie de Basic. Le message aux observateurs fait partie de Professional, car il a besoin de l'envoi de courrier. Sans cela, tu peux saisir des observateurs, mais rien ne part. Un observateur peut se retirer lui-même avec le bouton « Stop observing ». Il n'a pas besoin pour cela du droit de modifier le ticket.

Un observateur s'ajoute aussi automatiquement : qui transmet un ticket avec « Escalate to another team » en devient observateur. Il apprend ainsi ce que l'autre équipe en fait.

Quand deux personnes travaillent sur le même ticket en même temps, l’enregistrement le plus tardif pourrait écraser le précédent, et personne ne le remarquerait. C’est pourquoi le ticket montre qui d’autre l’a ouvert. Il refuse aussi un enregistrement qui repose sur un état périmé.

L’indication se trouve dans l’en-tête du ticket. « Marco Rossi is viewing this ticket » signifie que Marco a le ticket ouvert. « Marco Rossi is actively editing this ticket » signifie que Marco a des saisies non enregistrées. Il peut s’agir d’une réponse commencée, d’un commentaire en cours de modification, du titre ou de la description en mode édition, d’un suivi, d’un champ personnalisé ou d’une saisie de temps. Les champs modifiés dans les cartes « Actions » et « Details » comptent aussi, tant qu’ils n’ont pas été enregistrés avec « Save ». Une fenêtre ouverte sur le ticket compte également. Ce sont les fenêtres « Involve another team? », « Escalate to another team? », « Close ticket », « Resolve incident » et « Start a workflow », ainsi que la fenêtre du commentaire lors d’un changement de statut. Après deux minutes sans saisie, l’indication affiche de nouveau « viewing », même si le brouillon est toujours là.

Si plusieurs collègues ont le ticket ouvert, l’indication les regroupe, par exemple « Marco Rossi and 2 more are viewing this ticket ». Pointe sur l’indication pour voir tous les noms. Dès que quelqu’un modifie activement, la ligne ne compte plus que les personnes qui modifient. Tu ne te vois jamais toi-même. Si tu as le ticket ouvert dans deux onglets, tu comptes une seule fois. Si le ticket n’est ouvert que dans un onglet masqué, tu disparais de l’indication des autres au bout d’environ une minute.

Quand un collègue enregistre une modification, l’indication affiche « Marco Rossi changed this ticket », avec le bouton « Refresh » à côté. Un nouveau commentaire de quelqu’un d’autre affiche « Marco Rossi added a comment ». Si la modification ne vient d’aucune personne, par exemple d’une règle d’automatisation ou d’un e-mail entrant, l’indication affiche « This ticket was changed ». L’indication reste affichée jusqu’à ce que tu recharges.

« Refresh » charge l’état actuel du ticket, par exemple le statut, l’attribution, les champs et l’historique. La page entière n’est pas rechargée. Tes saisies non enregistrées restent. Une réponse commencée reste dans la zone de réponse, et un titre ou une description ouverts gardent ton texte. Si le texte enregistré a changé entre-temps, « The saved text has changed in the meantime. » apparaît sous le champ. Si tu enregistres alors, ton texte remplace le texte enregistré. Le bouton « Refresh » dans l’en-tête du ticket fait la même chose.

Si tu enregistres malgré tout sur un état périmé, l’enregistrement est refusé. La fenêtre « Ticket changed in the meantime » s’ouvre. Si une personne a fait la modification, la fenêtre la nomme. Ta modification n’a pas été enregistrée. Clique sur « Refresh », compare ta modification à l’état actuel et enregistre de nouveau. Cela vaut pour toute modification du ticket lui-même, par exemple le statut, l’attribution, la priorité, la carte « Details » et les champs personnalisés.

Les commentaires ne sont jamais refusés. Deux réponses ne s’écrasent pas l’une l’autre. Les deux arrivent sur le ticket. Il en va de même pour les pièces jointes et les saisies de temps. Les actions groupées sur la liste des tickets et les règles d’automatisation ne sont pas non plus vérifiées par rapport à l’état. Elles modifient le ticket directement. Celui qui l’a ouvert voit ensuite l’indication.

Les clients ne voient rien de tout cela. Ils n’apparaissent pas dans l’indication. Ils ne voient pas non plus qui travaille sur leur ticket.

Qui a un ticket ouvert n’est conservé que dans la mémoire du serveur. Environ une minute après que la personne a quitté le ticket, l’entrée disparaît. Rien de tout cela n’est écrit dans un journal. Le ticket enregistre qui l’a modifié en dernier. Cette entrée fait partie de l’export de données de cette personne. Quand la personne est anonymisée, elle est supprimée.

Le canal de messagerie est une route à deux sens, et les deux vont ensemble : un message entrant devient un ticket, ta réponse part par courrier électronique, et la réponse du demandeur arrive comme commentaire sur le même ticket, pas sur un second.

Le rapprochement ne se fait pas à l'intuition : une réponse n'arrive sur le ticket existant que si le message porte la référence du dossier dans son objet ou apporte les en-têtes de réponse du logiciel de messagerie. Un message qui n'a ni l'un ni l'autre ouvre un nouveau dossier. Mieux vaut un ticket de trop que deux dossiers sans rapport fusionnés parce que l'objet se ressemblait.

Tout ce qu'il faut se trouve sous « Settings → E-Mail Settings ». La carte du haut, « SMTP settings », est la voie de sortie : l'hôte, le port, « Use SSL », l'utilisateur et le mot de passe, plus l'adresse et le nom de l'expéditeur. Avec « Send test e-mail », tu t'envoies un exemple. Enregistre d'abord, teste ensuite, comme la carte le dit elle-même.

La carte « IMAP settings » est la voie d'entrée : l'hôte, le port, l'intervalle de relève et les deux dossiers. Tu n'as pas à deviner le nom du dossier : « Read from server » récupère les dossiers qui existent réellement dans ta boîte aux lettres, « Create on server » en crée un nouveau. Le champ prend alors le chemin que ton serveur de messagerie utilise : un serveur écrit « INBOX/Processed », le suivant « INBOX.Processed », et les deux veulent dire la même chose.

Le « Processed folder » reçoit les messages que le système met de côté : messages d'expéditeurs bloqués, messages générés automatiquement et messages qu'un workflow déplace avec « Move to folder » sans dossier propre. Laisse-le vide et ils restent dans la boîte de réception. En dessous, tu règles le moment du nettoyage (« Hour », « Minute ») et l'âge qu'un message peut atteindre (« Retention (days) »). Sinon, la boîte aux lettres grossit sans bruit.

Les boîtes aux lettres appartiennent à l'équipe, pas au système : sous « Team mailboxes », chaque équipe saisit sa propre adresse avec un mot de passe. Cette adresse est en même temps l'expéditeur des messages de cette équipe, le demandeur répond donc là où le courrier est relevé.

Et maintenant la partie sans laquelle rien de tout cela n'arrive : le workflow. Une boîte aux lettres configurée ne fait rien du tout à elle seule. Si une équipe n'a aucun workflow activé, la boîte aux lettres n'est même pas relevée : pas de ticket, pas de confirmation, les messages restent là. La réponse automatique à tes clients n'existe qu'ici, et c'est toi qui la mets en place. C'est voulu : un système qui écrirait sans qu'on le lui demande à chaque adresse d'expéditeur serait pire qu'un système qui se tait.

Sous « E-Mail workflows », tu choisis l'équipe en haut et tu crées un workflow avec « + Add workflow ». Il reçoit un nom (pour toi seulement), un interrupteur « Enabled » et deux indications sur les cas où il s'applique : « Match » décide si toutes les conditions doivent être vraies (« All conditions ») ou si une seule suffit, et « Stop after match » met fin au traitement dès que ce workflow a correspondu. Un workflow plus bas n'a alors jamais son tour. Tu changes l'ordre avec les flèches à côté.

Sous « When? » se trouve la condition elle-même. « Every e-mail in this mailbox » prend chaque message ; « Only when subject or text contains » exige un mot dans l'objet ou dans le corps. « Advanced » rend cela précis : tu y choisis ce qui est examiné, « Subject or body », « Subject », « Body », « Sender (From) » ou « Recipient (To/Cc) », et comment la comparaison se fait : « Contains », « Equals » ou « Regex ». C'est ainsi que tu sépares par exemple les signalements envoyés à une adresse commune du reste.

En dessous se trouvent cinq actions sous forme d'interrupteurs. Elles sont le contenu même du workflow : ce qui n'est pas activé ne se produit pas.

« Create or append ticket » transforme le message en ticket, ou l'ajoute comme commentaire à un ticket existant quand la référence figure dans l'objet. Sans cette action, un message ne devient jamais un dossier.

« Set fields » définit la priorité, le statut, la catégorie principale et la sous-catégorie, l'équipe propriétaire et la personne responsable dès la création du ticket. Tout ce qui reste sur « — Keep default — » demeure comme ce serait sans workflow.

« Auto-reply » est la confirmation envoyée à l'expéditeur. Avec cet interrupteur désactivé, ton client ne reçoit aucune confirmation, quelle que soit la qualité du reste de la configuration. « Send mail » peut aussi écrire à l'expéditeur, comme le montre l'action suivante.

« Send mail » envoie un message supplémentaire : soit à l'expéditeur du message entrant, soit à des membres d'équipe choisis et à des adresses fixes. Il a ses propres « Send conditions » ; laisse-les vides et il part à chaque exécution de ce workflow.

« Move to folder » classe le message traité dans un dossier. Laisse le champ vide et le « Processed folder » général des paramètres IMAP ci-dessus s'applique.

L'action « Auto-reply » en détail : tu construis l'objet à partir d'éléments. « Original subject {originalSubject} » reprend l'objet du message entrant, « Ticket reference {ticketTag} » insère la référence du dossier. Ensemble, cela donne quelque chose comme « Printer problem [TICKET-99-a1b2c3] ».

La référence n'est pas ajoutée toute seule. Elle n'apparaît que là où tu places {ticketTag}. {ticketId} n'insère que le numéro nu, et le système ne reconnaît pas une réponse à cela. Sans la référence dans l'objet, une réponse est quand même rattachée si elle porte les en-têtes de réponse de la confirmation. Seul un message qui n'a ni l'un ni l'autre devient un nouveau ticket.

Le texte en dessous est ton message de confirmation. Écris-le en anglais : il passe par le même export et le même import que tous les autres textes, et ce n'est que par là qu'il peut être traduit dans les autres langues. Laisse-le vide et le système envoie son propre message par défaut. Les mêmes variables sont autorisées ici aussi.

« Reply language » décide de la langue dans laquelle l'objet et le texte partent : « Standard English » utilise l'anglais, « Fixed language » une langue que tu choisis, « Assigned agent's language » la langue de l'agent responsable, et « Team default language » la langue par défaut de l'équipe. Les traductions elles-mêmes s'entretiennent sur la page des langues.

Un conseil que le système imprime aussi au-dessus de la carte : tout ce qui appartient à un même dossier appartient à UN seul workflow. Seules les actions d'un même workflow connaissent le ticket qui vient d'être créé, c'est pourquoi la confirmation peut nommer son numéro et pourquoi une action d'un second workflow ne le peut pas.

Tout le canal de messagerie, entrée et sortie, fait partie de l'édition Professional. Dans Basic, le système n'envoie ni ne reçoit de courrier électronique ; les tickets y sont créés par le portail, par téléphone et par l'agent.