Ce que les gens veulent vraiment dire par « exemples de systèmes de tickets »
Deux recherches différentes aboutissent à la même expression, et les deux sont légitimes.
Certaines personnes veulent des exemples de systèmes : nommez-moi les outils, montrez-moi les écrans, dites-moi lequel convient à une équipe de support de 12 personnes. D'autres veulent des exemples de tickets : à quoi ressemble un enregistrement réel une fois qu'il arrive, et que lui arrive-t-il ensuite. Je travaille sur la file d'attente de support chez eesel, donc c'est surtout la deuxième chose qui m'intéresse, et j'ai des opinions à ce sujet. La comparaison d'outils vient après avoir compris à quoi ressemble un bon ticket, c'est pourquoi le panorama des logiciels de système de tickets a plus de sens après cet article qu'avant.
Voici ce que trois ans de files d'attente en direct m'ont appris : c'est dans l'enregistrement du ticket que les équipes de support perdent discrètement de l'argent. Pas dans la réponse. Dans le ticket resté en Pending pendant neuf jours parce que personne n'a défini qui le clôture, dans le champ de priorité que chaque demandeur met en Urgent, dans les deux tickets qui étaient le même problème déposé par deux personnes différentes.
Cette différence n'est pas cosmétique. Zendesk propose six statuts (New, Open, Pending, On-hold, Solved, Closed). Freshdesk en propose quatre qui ne peuvent pas être supprimés, et dans HubSpot il n'y a aucun champ de statut, parce qu'un ticket y est un enregistrement CRM qui avance le long d'un pipeline de support.
Jira Service Management empile trois objets : un type de demande sur un type de travail sur un workflow. Sautez la couche de type de demande et l'élément de travail perd totalement l'accès aux fonctionnalités de service desk.
Choisissez l'exemple qui correspond à votre file d'attente
Six des huit exemples ci-dessous, tels qu'ils arrivent réellement. Parcourez-les avant de lire les versions longues.
Huit exemples de systèmes de tickets, traités de bout en bout
Chacun des exemples ci-dessous suit la même forme : la demande telle qu'elle arrive réellement, l'enregistrement qu'elle crée, le parcours de statuts, et le piège qui mord les équipes au troisième mois.
1. « Où est ma commande ? » dans une file d'attente e-commerce
L'exemple au plus haut volume dans toute file d'attente retail, et le moins intéressant à traiter. Un client colle un numéro de commande, l'agent ouvre l'onglet du transporteur, recopie une date. Chez Gorgias, la commande se trouve dans un panneau latéral juste à côté de la conversation, ce qui constitue tout l'argument en faveur d'un helpdesk natif e-commerce plutôt que générique.
L'enregistrement est mince : demandeur, numéro de commande, un tag, une réponse publique. Le statut passe de New à Open à Solved et se rouvre presque jamais. C'est cette forme qui pousse les gens à acheter du suivi de commande par IA, parce que la réponse est une consultation, pas un jugement. Si un type de ticket n'a jamais besoin d'un avis, il ne devrait pas avoir besoin d'un agent.
Le piège, c'est la mesure. Zendesk compte la résolution en un contact comme « des tickets résolus ou clôturés avec une seule réponse d'agent ou sans réponse », selon sa documentation sur la résolution en un contact, donc une file d'attente pleine de ce genre de tickets fait paraître votre équipe plus rapide qu'elle ne l'est réellement.
2. Un remboursement hors du délai de retour
Celui-ci arrive poliment et se transforme en décision de politique. Le client dépasse le délai de retour de 11 jours et a une raison plutôt valable.
L'enregistrement acquiert un statut d'approbation, qui prend quatre valeurs dans les champs de tickets Zendesk : Pending, Approved, Denied, Withdrawn. Beaucoup d'équipes ajoutent un statut personnalisé comme « Remboursement traité » pour que la finance puisse filtrer dessus plus tard. Il vaut mieux le savoir avant de le construire : Zendesk autorise jusqu'à 100 statuts de ticket, mais « le sélecteur de statut n'affichera que les 10 premiers » selon sa documentation de gestion des statuts, et un ticket résolu avec un statut personnalisé conserve cette étiquette après clôture.
Le parcours de statuts fait un détour par Pending pendant que vous attendez des photos ou une confirmation de commande, et Pending est l'endroit où les tickets de remboursement vont mourir. Freshdesk repasse un ticket en Open « à chaque fois qu'un client répond », ce qui est utile, mais rien ne sauve le ticket dont le client ne répond jamais. Automatiser la rédaction est acceptable ici, selon notre guide sur l'automatisation des remboursements. Automatiser la décision d'exception ne l'est pas.
3. Réinitialisation de mot de passe et blocage MFA
Le ticket le plus documenté en IT, et celui avec l'écart de coût le plus large. Même question, six portes d'entrée :
Les chiffres de HDI pour 2021 situent le self-help à 2,37 $ et le guichet à 37,52 $, un écart que les auteurs de l'analyse de coûts de HDI décrivent comme « plus de deux ordres de grandeur (100X) ». Rien n'a changé dans la réponse elle-même. Seule la porte par laquelle l'utilisateur est passé a changé.
Le hic, c'est que la déviation ne rend pas la file d'attente moins chère en moyenne. HDI est direct à ce sujet dans son benchmark du self-service : à mesure que les incidents à faible temps de traitement basculent vers le self-service, « la complexité moyenne et le temps de traitement moyen des incidents qui continuent d'être traités par des agents en direct augmenteront ». Votre coût par ticket peut monter tandis que votre coût total baisse. Planifiez la conversation sur le reporting avant que votre portail self-service ne soit mis en ligne, sinon la première revue mensuelle ressemblera à un échec.
Il vaut aussi la peine de calibrer l'ambition : la base de données de benchmark de MetricNet situe le taux moyen d'aboutissement du self-service à 10,4 %, contre des présentations d'éditeurs qui promettent 60 ou 80. Notre guide de déviation de tickets utilise ce même chiffre comme base.
4. Demande d'accès et d'équipement pour un nouvel employé
Un manager dépose une ligne (« nouvel arrivant lundi, le kit habituel ») et crée une semaine de travail. C'est une demande de service, pas un incident, et la distinction coûte cher : les données de terrain de MetricNet situent le temps de travail d'un incident entre 12,3 et 21,5 minutes contre 35,4 à 95,9 minutes pour une demande de service dans l'étude de volume de MetricNet.
Jira Service Management modélise bien cela. Un nouvel espace propose d'office cinq types de travail (IT Help, Purchase, Change, Fault, Access) et deux types de demande, et les champs du type de demande proviennent de son type de travail. Il renomme aussi les statuts pour le demandeur : en interne le ticket indique Waiting for Customer, et le portail affiche « Requester Action Needed » dans la configuration par défaut de JSM. Un petit détail, une grande différence sur le nombre de réponses du type « des nouvelles ? » que vous recevez.
Si cette forme domine votre file d'attente, lisez ensuite les articles sur les demandes d'accès et les demandes de matériel, et considérez l'onboarding RH comme le même schéma avec des approbateurs différents.
5. Un rapport de bug qui devient une escalade ingénierie
Un client découvre un vrai défaut. Le support le reproduit, lie un ticket d'ingénierie, et se retrouve désormais propriétaire d'un ticket qu'il ne peut pas clôturer.
Le champ Type de Zendesk porte quatre valeurs (Question, Incident, Problem, Task) dans le jeu de champs standard, et c'est à sens unique : une fois défini, vous ne pouvez plus le vider. Désactiver entièrement le champ fait passer tous les tickets par défaut en Incident. Jira Service Management sépare plutôt les deux axes, gardant le statut pour l'endroit où en est le travail et la resolution pour la façon dont il s'est terminé, avec une valeur de resolution Known error pour le cas cause documentée plus contournement.
Le piège ici, c'est On-hold. C'est un statut interne optionnel que « le demandeur du ticket ne voit jamais », selon la documentation du cycle de vie Zendesk ; sa vue affiche toujours Open. Le ticket est donc mis de côté et le client pense qu'on y travaille. Mettez en place un rythme de mises à jour proactives, et voyez la gestion des escalades ainsi que le triage des rapports de bugs pour le côté acheminement.
6. Un litige de facturation dans un helpdesk centré CRM
« Vous m'avez facturé deux fois en juin » est un ticket de support qui est en réalité un ticket de finance, et c'est exactement pour cela que les équipes le gèrent dans un système en forme de CRM.
Dans HubSpot Service Hub, le ticket est un objet sur un pipeline, et le Support Pipeline par défaut a quatre statuts : New, Waiting on contact, Waiting on us, Closed. Plusieurs comportements comptent pour un litige qui rebondit entre équipes. La date de clôture est bidirectionnelle, donc remettre un ticket dans une étape ouverte efface la valeur. Category est défini par l'IA à partir du premier message et n'existe que sur Enterprise. Et hs_ticket_owner_type enregistre si un Human rep, un Customer Agent ou un Rule-based bot a touché l'enregistrement, ce qui est la première piste d'audit honnête que j'aie vue pour des tickets traités par IA dans un helpdesk grand public.
Les objectifs de déviation doivent rester modestes sur cette forme. Notre article sur la déviation de tickets HubSpot donne le détail des restrictions par plan, et le CRM de service client couvre les cas où le modèle centré CRM l'emporte réellement.
7. Une panne qui arrive sous forme de quarante tickets
Une panne, quarante enregistrements, et un champ de priorité qui va être mis à l'épreuve.
Les cinq priorités de Jira viennent avec la formulation propre à Atlassian, dans le schéma de priorités JSM, de Highest (« Ce problème bloquera la progression ») jusqu'à Lowest. Les quatre priorités de Freshdesk sont « codées en dur dans nos systèmes » parce que les politiques SLA en dépendent, selon son guide des champs de tickets. Zendesk cache une dépendance plus vicieuse : désactivez le champ Priority et les objectifs SLA cessent complètement de s'appliquer.
Laissez les demandeurs fixer eux-mêmes la priorité et le champ ne veut plus rien dire :
"Dealt with this decades ago. It was scrapped quickly because as you might imagine it was abused to death. It really didn't bother me though. I still got the same number of tickets and just slogged through them. When people got mad because we were missing SLAs we just replied there was nothing we could do now that all tickets were priority."
371 votes positifs sur ce commentaire, ce qui montre à quel point ce schéma est courant. La priorité devrait être dérivée de règles d'impact et d'urgence que vous contrôlez, pas saisie par celui qui crie le plus fort. Le guide sur la gestion des SLA couvre le côté politique, et la priorisation de tickets par IA couvre comment la dériver automatiquement.
8. Une demande de fonctionnalité qui ne sera jamais construite
Le ticket le plus poli de la file d'attente et celui qui risque le plus de pourrir. Quelqu'un demande un mode sombre, le produit dit non, et l'enregistrement n'a nulle part où aller.
Jira Service Management a une réponse nette : resolution Won't do, séparée du statut, et la clé de l'élément de travail s'affiche barrée une fois résolue. Zendesk et Freshdesk vous poussent au contraire vers Solved ou Resolved, ce qui code silencieusement « on a fait le nécessaire » alors que ce n'est pas le cas. Freshdesk est au moins explicite sur cette distinction : dans ses propres mots, Resolved signifie fait « selon l'agent » et Closed signifie fait selon le client, avec une clôture automatique après 72 heures.
La clôture n'appartient souvent de toute façon pas à l'agent. Zendesk indique clairement dans sa documentation du cycle de vie des tickets que « les tickets ne peuvent pas être manuellement mis à Closed » : une automatisation par défaut les clôture quatre jours après Solved, et avec les automatisations de clôture désactivées, un plafond dur de 28 jours entre en jeu et ne peut pas être modifié.
Le même ticket dans six systèmes réels
Passons maintenant à l'autre lecture du mot-clé : les systèmes exemples. Voici ce que coûte et à quoi ressemble une demande identique dans six des outils que je vois le plus souvent lors d'appels clients.
| Système | Un ticket est | Statuts d'origine | Prix d'entrée | Unité de facturation IA | Meilleure adéquation |
|---|---|---|---|---|---|
| Zendesk | Objet ticket avec 15 champs standards | 6 (plus jusqu'à 100 personnalisés) | 19 $/agent/mois Support Team, 55 $ Suite Team | Verified automated resolution, tarif non publié | Grandes files multi-marques |
| Freshdesk | Ticket avec 11 champs par défaut non supprimables | 4 | 19 $/agent/mois Growth | Session, 49 $ par tranche de 100 supplémentaires | Équipes moyennes voulant de la simplicité |
| Zoho Desk | Ticket au sein d'un département | 3 principaux plus personnalisés | 0 $ Free (3 utilisateurs), 14 $ Standard | Zia, inclus selon l'édition | Équipes soucieuses du coût |
| Help Scout | Conversation dans une boîte de réception partagée | Active, Pending, Closed | 0 $ Free (5 utilisateurs), 25 $/utilisateur/mois | Résolution, 0,75 $ | Petites équipes, travail à forte composante email |
| Gorgias | Ticket lié à une commande Shopify | Open, Closed | 40 $/mois (50 tickets), jamais par agent | Interaction automatisée, 1,50 $ | Exemples de commandes e-commerce |
| Jira Service Management | Type de demande sur type de travail sur workflow | Double nommage, défini par le workflow | 25 $/agent/mois Standard (1 à 15 agents) | 1 $ par résolution, plus 0,30 $ par conversation assistée | IT interne et approbations |
Les prix sont les tarifs catalogue annuels tirés de la page de prix de chaque éditeur, vérifiés cette semaine. Deux d'entre eux méritent un avertissement. Jira Service Management annonce une moyenne combinée de 20 $ par agent, qui est le tarif pour son curseur par défaut de 75 agents dans le cadre d'une tarification progressive au volume, pas ce que paie une équipe de 10 agents. Et l'unité phare de Zendesk, l'automated resolution, n'a aucun chiffre en dollars publié nulle part sur la page de prix, ce qui fait de la budgétisation de la couche IA un appel commercial.
Les évaluations et les grilles de fonctionnalités ne vous diront pas lequel de ces outils convient. Les formes de tickets ci-dessus, si. Une file d'attente e-commerce à 60 % suivi de commande veut le modèle Gorgias ; un desk IT interne rempli d'approbations veut Jira Service Management.
Pour le champ plus large, le top des logiciels helpdesk passe outil par outil, et les exemples de logiciels couvre le côté orienté client.
Trois exemples de tickets qui tournent mal
Les cas d'échec sont plus instructifs que le chemin idéal, et chacun d'eux se corrige avec de la configuration plutôt qu'avec plus de personnel.
Le ticket que personne n'attend. Un responsable support a compté sa file d'attente et a découvert que le backlog était en grande partie fictif :
"I was going through our queue today and found 90 tickets where we responded, asked for more information from the customer but then never heard back from them. They just sit there inflating our numbers and that honestly doesn't look good for management. We have been called before for unresolved open tickets so this is a big deal."
90 des 200 tickets ouverts attendaient un client resté silencieux, donc le nombre d'ouverts n'a jamais été le vrai backlog. Un autre manager IT a rapporté avoir réduit le backlog d'un groupe de 54 % simplement en clôturant automatiquement les tickets de plus de cinq jours. Notre article sur le nettoyage de backlog est la version longue de cette correction.
La base de connaissances que personne ne met à jour. Chaque exemple de self-service ci-dessus suppose qu'un article existe et est à jour :
"I run a small team, and we have an internal wiki for processes, FAQs, and troubleshooting. The problem? No one updates it. People keep asking the same questions in Slack instead of checking the wiki."
Les deux moitiés échouent ensemble : la base de connaissances interne se dégrade, et les gens la contournent. Entraîner l'IA sur les tickets passés plutôt que uniquement sur des articles est la réponse pratique, ce que couvre notre guide sur l'entraînement de la base de connaissances.
Le reporting que vous ne pouvez pas extraire de l'outil. Un responsable support qui a construit des tableaux de bord dans un vrai outil de BI n'a quand même pas pu obtenir des chiffres de base :
"I have never found anything as complex as Zendesk explore. I've worked with ThoughtSpot building dashboards, reports and exports but omg Zendesk, you are taking so much of my time!!!!!!!!"
Vérifiez la couche de reporting sur ces exemples précis avant d'acheter, pas après. Le reporting Zendesk et les KPI de service client sont les deux choses à tester dès le premier jour d'un essai.
Ce qu'une couche IA change sur ces huit exemples
Pas les huit, et c'est justement le point. Les exemples 1, 3 et la majeure partie du 6 se répètent indéfiniment avec une réponse connue. Les exemples 2, 5, 7 et 8 ont besoin d'une personne qui porte la politique.
J'ai observé ce mode d'échec de près. L'un de nos propres clients, un fournisseur danois d'énergie solaire, a eu un bot qui a fabriqué des affirmations d'abonnement et les a envoyées à de vraies personnes alors que sa base de connaissances n'avait aucun article correspondant. Cet incident est la raison pour laquelle chaque déploiement eesel exécute désormais une simulation sur des tickets historiques avant de répondre en direct à qui que ce soit. Un responsable CX d'une marque de compléments alimentaires sur Gorgias a formulé cette exigence mieux que notre propre documentation :
"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
C'est une demande raisonnable, et elle correspond exactement à la liste d'exemples : confiez à l'IA la forme du statut de commande, éloignez-la de la panne. Quand le périmètre est le bon, les chiffres sont bons. Gridwise a résolu 73 % des demandes de niveau 1 dès son premier mois après un essai de sept jours. Quand le périmètre est mal défini, on se retrouve avec l'histoire du panneau solaire.
Lisez les hallucinations de l'IA dans le support et le transfert de l'IA vers un humain avant de choisir quelles formes automatiser.
La classification de tickets et le tagging de tickets sont les premiers pas sûrs dans presque toutes les files d'attente, parce qu'un mauvais tag ne coûte rien et qu'une mauvaise réponse coûte un client.
Testez eesel sur vos propres exemples de tickets
Si votre file d'attente ressemble à la liste ci-dessus, l'action utile n'est pas de changer de helpdesk. C'est de poser une couche IA sur celui que vous avez déjà et de la pointer vers les deux ou trois formes qui se répètent.
eesel se connecte à Zendesk, Freshdesk ou Gorgias en quelques minutes, s'entraîne sur vos tickets passés et votre centre d'aide, puis simule sur le volume historique pour que vous voyiez les réponses qu'il aurait envoyées avant qu'un client ne les voie jamais.
Vous choisissez les formes de tickets qu'il touche, donc l'exemple 7 ne lui parvient jamais. La facturation est de 0,40 $ par ticket traité, sans frais par siège, donc acheminer 200 de vos 1 000 tickets mensuels coûte 80 $, pas un nouveau palier de plan. Gratuit à tester.
Commencez par l'exemple 1 ou l'exemple 3. Ce sont ceux au plus haut volume, au plus faible risque, et les plus faciles à prouver en une semaine.
Questions fréquentes
Qu'est-ce qu'un exemple de système de tickets ?
Quels sont des exemples de systèmes de tickets ?
À quoi ressemble un ticket de support à l'intérieur du système ?
Quels sont des exemples de tickets de système de tickets IT ?
Combien coûte un seul ticket de support ?
Quelle est la différence entre un incident et une demande de service ?
L'IA peut-elle traiter ces exemples de systèmes de tickets de bout en bout ?
Article by
Riellvriany Indriawan
Riell is a designer and writer at eesel AI with about two years of experience researching CX platforms, AI chatbots, and helpdesk software. She combines her design background with a sharp eye for how these tools actually look and feel in practice — making her comparisons unusually visual and user-focused.
