Comment créer un rapport de tickets de support : étape par étape

Un rapport sur les tickets de support est avant tout un problème de définitions. Les tickets créés, les tickets résolus, le temps de première réponse et le temps de résolution semblent tous explicites. Pourtant, chacun d'entre eux possède plus d'une signification officielle au sein d'un même help desk.

Définissez clairement les règles de calcul et le rapport s'écrira tout seul. Sautez cette étape, et deux personnes de bonne foi obtiendront des résultats différents de plusieurs heures à partir du même export.

Ce guide présente les éléments à inclure dans le rapport, les quatre points de divergence dans les définitions et la méthode pour le construire à partir d'un export de tickets.

Ce que doit contenir un rapport sur les tickets de support

Le volume seul ne dit presque rien. C'est l'organisation des données qui permet d'interpréter les chiffres en toute sécurité.

Élément	Pourquoi il y figure
Tickets créés sur la période	Le côté de la demande
Tickets résolus sur la période	Le côté de l'offre, selon une règle de statut définie
Backlog en fin de période	Tout ce qui n'est ni résolu ni clos
Temps de première réponse	Selon des horaires et une définition définis
Temps de résolution	Première ou complète, explicitement nommée
Tickets réouverts	L'indicateur de qualité que les autres chiffres masquent
Tickets sans réponse	Là où le processus a totalement échoué
Une base de date et un périmètre définis	Quels canaux, marques et files d'attente sont inclus

Deux lignes ont un impact bien plus important que leur taille ne le laisse supposer. Les tickets réouverts et sans réponse sont les éléments qui transforment un simple tableau d'affichage en un rapport véritablement utile.

Zendesk publie les formules sous-jacentes, ce qui permet de vérifier les définitions plutôt que d'en faire une question d'opinion. Sa référence des métriques et attributs détaille chacune d'elles.

Commençons par le plus simple. Les tickets résolus correspondent au « nombre de tickets résolus ou clos », de sorte que la métrique englobe deux statuts plutôt qu'un seul.

Le « temps de première réponse » a deux définitions officielles

C'est le point de divergence qui suscite le plus de désaccords, et l'éditeur met directement en garde à ce sujet.

La documentation SLA de Zendesk le résume en une ligne : « Ne confondez pas le temps de réponse SLA avec la métrique de temps de réponse native de Zendesk. »

La métrique native est stricte quant à l'auteur de la réponse. Zendesk précise que « le temps de première réponse est calculé exclusivement sur la base des réponses des agents ». Les actions automatisées et liées aux bots « ne sont pas prises en compte dans le calcul du temps de première réponse ».

Ce n'est pas le cas de la métrique SLA. Pour cette dernière, le temps de première réponse est « le temps écoulé entre la création du ticket et le premier commentaire public d'un agent (ou une réponse automatique) ». Zendesk ajoute que « les métriques de temps de réponse sont satisfaites si vous configurez un déclencheur pour envoyer une réponse automatique sous forme de commentaire public ».

En combinant ces deux éléments, la conséquence est flagrante. Un répondeur automatique peut valider votre objectif de SLA alors que le temps de première réponse natif continue de s'écouler.

Ainsi, un rapport affichant un taux de respect des SLA de 98 % et un temps de première réponse médian de quatre heures n'est pas contradictoire. Il rend compte de deux indicateurs différents, tous deux de manière exacte.

Il existe deux exceptions mineures qui méritent d'être connues. Dans le cas où un agent crée le ticket et que le premier commentaire est public, la référence des métriques de durée indique que le second horodatage « passe au deuxième commentaire public de l'agent ».

De plus, les tickets partagés ne comptent pas. Zendesk précise que lorsqu'un agent commente publiquement depuis un autre compte en utilisant le partage de tickets, « cela n'est pas pris en compte dans le temps de première réponse de votre compte ».

Le « temps de résolution » en a également deux

La même distinction s'applique aux métriques de résolution, et ici, les deux versions sont proposées par défaut.

Le temps de première résolution est la « durée entre la création du ticket et sa première résolution », se terminant « la première fois que le statut du ticket est défini sur résolu ».

Le temps de résolution complète est la « durée entre la création du ticket et sa résolution la plus récente ». Il se termine « la dernière fois que le statut du ticket a été défini sur résolu ».

Pour un ticket résolu une seule fois, les deux sont identiques. Pour un ticket résolu, réouvert, puis résolu à nouveau, ils divergent de la durée qu'a nécessitée la seconde phase.

C'est précisément pour cela que les tickets réouverts doivent figurer dans le rapport. Zendesk les définit comme des tickets « réouverts après avoir été résolus », et note que cette métrique « n'inclut pas les tickets résolus et réouverts lors de la même mise à jour ».

Il y a un effet secondaire que l'on oublie souvent. La moyenne quotidienne des tickets résolus ne les comptabilise « que s'ils sont actuellement résolus ou clos ». Ainsi, un ticket réouvert aujourd'hui disparaît discrètement du décompte des tickets résolus du mois dernier.

Un rapport généré en juin ne donnera donc pas les mêmes résultats en août. Rien n'a planté ; c'est simplement le statut sous-jacent qui a changé.

Deux autres métriques permettent de distinguer le temps d'attente du temps de traitement. Le temps d'attente du demandeur est le temps cumulé dans les statuts nouveau, ouvert et en attente, tandis que le temps d'attente de l'agent est le temps cumulé dans le statut en attente.

Ce binôme répond à une question qu'une moyenne de résolution ne peut résoudre. Des temps de résolution longs dus à l'attente d'une réponse du client relèvent d'un problème différent de ceux causés par la longueur de la file d'attente.

Heures calendaires ou heures ouvrées

Chaque chiffre de réponse et de résolution repose sur deux modes de calcul du temps, et choisir l'un d'eux est indispensable.

Zendesk enregistre les deux. Après la première réponse publique, « le système calcule le temps de première réponse en heures calendaires et en heures ouvrées ». Les deux métriques « sont stockées avec les données du ticket ».

L'affichage par défaut n'est pas neutre. Zendesk précise que les rapports Explore prédéfinis « affichent les informations en heures calendaires ». Les métriques en heures ouvrées « sont disponibles et peuvent être utilisées dans vos propres rapports ».

Ainsi, une équipe travaillant de 9h à 17h semblera lente sur le rapport par défaut. Un ticket arrivant le vendredi à 18h accumulera environ 63 heures calendaires avant le lundi matin, contre près de zéro heure ouvrée.

Les canaux de conversation en direct ajoutent une autre subtilité. La métrique Temps de première réponse (sec) pour la messagerie et le chat « ignore vos paramètres d'heures ouvrées de messagerie et d'heures de fonctionnement du chat en direct ».

De plus, les SLA de temps de réponse pour le chat sont optionnels. Zendesk indique que les SLA de temps de réponse pour le chat en direct « sont désactivés par défaut », de sorte que leur absence relève d'un choix de configuration plutôt que d'une performance parfaite.

Comment procéder manuellement

Option 1 : Un onglet par famille de métriques

Exportez la liste des tickets avec les champs de métriques, puis séparez le volume, le temps de réponse et le temps de résolution dans des onglets distincts avant de faire la moindre synthèse.

Conservez les colonnes d'heures calendaires et d'heures ouvrées côte à côte plutôt que d'en choisir une seule lors de l'export. On finira inévitablement par vous demander l'autre.

Calculez des médianes plutôt que des moyennes pour les métriques de temps. Quelques tickets laissés ouverts pendant un jour férié fausseront la moyenne vers un chiffre qui ne correspond à la réalité d'aucun ticket.

La limite réside dans le fait qu'un tableur ne peut pas voir l'historique des statuts. Vous obtenez l'état actuel de chaque ticket, de sorte que le comportement de réouverture doit être déduit du décompte des réouvertures plutôt que d'une reconstruction de l'historique.

Option 2 : Un onglet de définitions, rédigé en premier

Notez la définition du temps de réponse, le mode de calcul du temps, la métrique de résolution, la règle de statut pour les tickets résolus, les canaux concernés et la base de date.

Notez ensuite ce que le rapport ne prétend pas mesurer. Préciser par écrit que le respect des SLA et le temps de première réponse natif mesurent des choses différentes évitera qu'un collègue bien intentionné ne les confonde en un seul chiffre.

La limite est celle que l'on connaît bien. Documenter une règle ne suffit pas à l'appliquer, et au trimestre suivant, quelqu'un reconstruira le tableau croisé dynamique de mémoire.

Option 3 : Segmenter avant de calculer la moyenne

Séparez par canal avant de calculer toute métrique de temps. Les tickets par e-mail, chat et téléphone répondent à des logiques différentes, et une médiane globale ne décrira fidèlement aucun d'entre eux.

Excluez ou signalez ensuite les tickets qui faussent les données. Les tickets en attente d'une réponse du client depuis des semaines doivent figurer sur leur propre ligne plutôt que d'être inclus dans la moyenne de résolution.

Indiquez ce que vous avez exclu et en quelle quantité. Un lecteur qui ne voit pas le filtre supposera qu'il n'y en avait pas.

La limite est que la segmentation multiplie le travail. Trois canaux multipliés par deux modes de calcul du temps multipliés par deux métriques de résolution donnent douze chiffres à suivre rigoureusement.

La limite commune. Ces trois options supposent que l'export couvre une seule plage de dates sur une seule base de date pour chaque file d'attente. Le mélange de plages de dates d'un onglet à l'autre est l'erreur silencieuse la plus fréquente dans ce type de rapport.

Là où la méthode manuelle montre ses limites

Le premier rapport sur les tickets de support prend une après-midi. Le quatrième prend plus de temps, car le help desk a évolué entre-temps.

Un nouveau canal est activé, et la médiane globale évolue pour des raisons sans rapport avec la performance. Les heures ouvrées sont modifiées pour une nouvelle région, et tous les chiffres historiques en heures ouvrées s'en trouvent modifiés.

Puis l'effet de réouverture se manifeste. Les chiffres du trimestre précédent ne correspondent plus, et expliquer pourquoi prend plus de temps que de reconstruire le rapport.

Il existe un quatrième coût qui n'apparaît que sous la pression. Quelqu'un demande si le support est devenu plus rapide ce trimestre. Pour donner une réponse honnête, il faut d'abord préciser le mode de calcul du temps, la définition et la répartition des canaux.

Pour l'aspect satisfaction de cette même réalité, consultez notre guide pour créer un rapport NPS. Si le volume lui-même pose problème, notre tutoriel sur la création d'un agent IA pour le support client avant-vente traite de l'aspect déviation des tickets.

Comment le construire avec Powerdrill Bloom

Étape 1 : Importez votre export de tickets

Importez l'export de tickets, ou les exports de tickets et de SLA ensemble. Powerdrill Bloom analyse les colonnes dès leur arrivée, de sorte que les horodatages vides, les formats de date mixtes et les tickets sans première réponse apparaissent avant même le calcul de la moindre médiane.

Étape 2 : Décrivez le rapport en langage naturel

Énoncez les définitions plutôt que de les reconstruire. Indiquez la définition du temps de réponse, le mode de calcul du temps, la métrique de résolution souhaitée, la règle de statut pour les tickets résolus et les canaux concernés.

Posez ensuite les questions qui permettent de détecter les erreurs. Demandez combien de tickets n'ont reçu aucune réponse d'un agent. Demandez quels tickets ont été réouverts. Demandez des médianes par canal plutôt qu'un seul chiffre global.

Étape 3 : Exportez le graphique, le rapport ou la présentation

Extrayez le tableau des métriques par canal, ou un graphique comparant les tickets créés et résolus avec le backlog en arrière-plan. Les diapositives présentant les définitions à côté des chiffres sont générées lors de la même opération.

Erreurs courantes

Confondre le respect des SLA et le temps de première réponse. L'un accepte une réponse automatique tandis que l'autre exclut totalement les actions automatisées.

Comparer les heures calendaires aux heures ouvrées. Le rapport par défaut vous donne les premières, alors que votre objectif a probablement été défini sur les secondes.

Utiliser la moyenne pour les temps de réponse et de résolution. Quelques tickets abandonnés déplacent la moyenne vers une valeur qui ne correspond à la réalité d'aucun ticket.

Mélanger les canaux. Les médianes du chat et de l'e-mail diffèrent par nature, et les mélanger masque ces deux réalités.

Indiquer le temps de résolution sans préciser lequel. Le temps de première résolution et le temps de résolution complète sont des métriques distinctes enregistrées séparément, et non des variantes d'arrondi.

Considérer le décompte des tickets résolus comme définitif. Les décomptes de tickets résolus n'incluent que les tickets actuellement résolus ou clos, de sorte que les réouvertures modifient le passé.

Omettre les tickets sans réponse. Ils sont définis comme des tickets ayant reçu moins d'une réponse d'un agent, et constituent l'échec le plus flagrant qu'un rapport puisse mettre en évidence.

Conclusion

Nommez la définition de la réponse, nommez le mode de calcul du temps, choisissez la première résolution ou la résolution complète, définissez la règle de statut, segmentez par canal, et affichez les tickets réouverts et sans réponse. Vous obtiendrez ainsi un rapport sur les tickets de support véritablement exploitable.

Ce que le rapport ne permettra peut-être pas, c'est de se comparer facilement aux chiffres d'une autre entreprise. Les définitions étant configurables, un benchmark lu quelque part a presque certainement été mesuré selon des règles différentes.

Suivez-le plutôt par rapport à votre propre historique, selon un ensemble de règles fixes. C'est cette version qui vous indiquera si des améliorations réelles ont été apportées.

Si reconstruire ce rapport chaque mois vous prend une journée entière, essayez Powerdrill Bloom sur votre export de tickets. Consultez également la page du générateur de rapports IA et le synthétiseur de la voix du client.

Questions fréquentes

Pourquoi mon taux de respect des SLA ne correspond-il pas à mon temps de première réponse ?

Ils mesurent des événements différents. Le temps de première réponse SLA de Zendesk peut être satisfait par une réponse automatique, tandis que la métrique de temps de première réponse native exclut totalement les actions automatisées et les bots.

Dois-je indiquer le temps de première résolution ou le temps de résolution complète ?

Indiquez celui que vous nommez. Le temps de première résolution se termine la première fois qu'un ticket est défini sur résolu. Le temps de résolution complète se termine la dernière fois, de sorte que les tickets réouverts séparent les deux.

Les métriques de support sont-elles mesurées en heures calendaires ou en heures ouvrées ?

Les deux sont enregistrées. Les rapports Explore prédéfinis de Zendesk affichent les heures calendaires, et les métriques en heures ouvrées sont disponibles pour les rapports que vous construisez vous-même.

Pourquoi le décompte des tickets résolus du trimestre dernier a-t-il changé ?

Les décomptes de tickets résolus incluent les tickets qui sont actuellement résolus ou clos. Un ticket réouvert après la fin de la période est exclu du décompte de cette période.

Puis-je comparer mon temps de résolution à un benchmark du secteur ?

Seulement de manière très approximative. Les définitions, le mode de calcul du temps et la répartition des canaux sont tous configurables, de sorte qu'un chiffre publié a probablement été mesuré selon des règles différentes des vôtres.