Si vous avez déjà regardé Zendesk Explore en vous demandant pourquoi il existe deux mesures différentes qui semblent toutes deux compter les tickets résolus, vous n’êtes pas seul(e). La distinction entre « tickets résolus » et « tickets résolus » déconcerte même les administrateurs expérimentés. Si vous vous trompez, vos rapports raconteront une histoire complètement différente de ce qui se passe réellement dans votre file d’attente de support.
Décomposons cela. Ce guide explique la différence essentielle entre ces deux mesures, quand utiliser chacune d’elles et comment créer des rapports précis qui reflètent réellement les performances de votre équipe.
| Cas d’utilisation | Utilisez cette mesure | Ensemble de données |
|---|---|---|
| Charge de travail actuelle par agent | Tickets résolus | Tickets |
| Tickets résolus aujourd’hui/cette semaine | Tickets résolus | Tickets |
| Tendances au fil du temps (créés vs résolus) | Tickets résolus | Historique des mises à jour |
| Suivi de la conformité aux SLA | Tickets résolus | Historique des mises à jour |
| Examens des performances des agents | Dépend de l’objectif | L’un ou l’autre |
En résumé ? Si vous suivez les tendances ou mesurez les performances au fil du temps, vous voulez presque toujours les Tickets résolus de l’ensemble de données Historique des mises à jour. Si vous avez besoin d’un instantané actuel de la charge de travail résolue, utilisez les Tickets résolus de l’ensemble de données Tickets.
Pour les équipes qui cherchent à aller au-delà de la création manuelle de rapports, nous offrons un suivi autonome de la résolution qui fournit ces informations sans avoir à naviguer dans les ensembles de données et les formules.
Choisir le bon ensemble de données pour votre rapport
Zendesk Explore organise les données en ensembles de données, et choisir le mauvais est le moyen le plus rapide d’obtenir des résultats déroutants. Voici comment décider.
Ensemble de données Tickets : pour l’état actuel et les instantanés
Utilisez ceci lorsque vous voulez connaître l’état des tickets en ce moment. Il contient des informations générales sur les tickets sans modifications historiques.
- Idéal pour : Charge de travail actuelle, nombre de tickets ouverts, analyse de l’arriéré
- Attributs de temps : Ticket créé, Ticket résolu (le plus récent), Ticket mis à jour
- Mesures clés : Tickets résolus, Tickets non résolus, Tickets résolus - 7 derniers jours
Ensemble de données Historique des mises à jour : pour suivre les changements au fil du temps
Cet ensemble de données enregistre chaque modification apportée aux tickets. Il est basé sur les événements, ce qui signifie qu’il suit ce qui s’est passé et quand.
- Idéal pour : Analyse des tendances, rapports créés vs résolus, suivi de l’activité des agents
- Attributs de temps : Horodatage de la mise à jour (quand les changements se sont produits)
- Mesures clés : Tickets créés, Tickets résolus, Mises à jour des agents, Commentaires
Ensemble de données Historique de l’arriéré : pour les instantanés historiques
Cela montre combien de tickets non résolus existaient à une date donnée. Explore collecte ces données chaque fois que vos données se synchronisent.
- Idéal pour : Comprendre la croissance ou la réduction de l’arriéré au fil du temps
- Limite : Ne capture que les données des points de synchronisation, pas en temps réel
Cadre de décision rapide
Posez-vous la question : à quelle question est-ce que j’essaie de répondre ?
- « Combien de tickets sont résolus en ce moment ? » → Ensemble de données Tickets
- « Combien de tickets avons-nous résolus cette semaine ? » → Ensemble de données Historique des mises à jour
- « Quelle est notre tendance d’arriéré ? » → Ensemble de données Historique de l’arriéré
- « Est-ce que nous suivons le volume de tickets ? » → Ensemble de données Historique des mises à jour (créés vs résolus)
Comment créer un rapport de tickets créés vs résolus
C’est l’un des rapports les plus courants dont les équipes de support ont besoin. Il montre si vous faites du surplace, si vous prenez du retard ou si vous avancez. Voici comment le construire.
Étape 1 : Créer un nouveau rapport dans l’ensemble de données Historique des mises à jour
Naviguez vers Explore, cliquez sur l’icône des rapports, puis cliquez sur Nouveau rapport. Sur la page « Sélectionner un ensemble de données », choisissez Support > Support - Historique des mises à jour, puis cliquez sur Démarrer le rapport.
Étape 2 : Ajouter les mesures
Dans le panneau Mesures, cliquez sur Ajouter. Dans la liste, choisissez :
- Tickets > Tickets créés
- Tickets > Tickets résolus
Puis cliquez sur Appliquer.
Pourquoi ces mesures ensemble ? Tickets créés montre le volume entrant. Tickets résolus montre le volume sortant. Lorsque les résolus dépassent constamment les créés, vous réduisez l’arriéré. Lorsque les créés dépassent les résolus, votre file d’attente s’allonge.
Étape 3 : Configurer le filtrage des dates
Dans le panneau Filtres, cliquez sur Ajouter. Choisissez Temps - Mise à jour du ticket > Mise à jour - Année, puis cliquez sur Appliquer.
Cliquez sur le filtre Mise à jour - Année que vous venez d’ajouter, puis cliquez sur Modifier les plages de dates. Vous pouvez choisir une plage simple comme « Cette année » ou cliquer sur l’onglet Avancé pour plus d’options comme « 12 semaines dans le passé à 1 semaine dans le passé ».
Conseil de pro : Pour une analyse précise des jours de la semaine, utilisez toujours des semaines complètes de données. Les semaines partielles peuvent fausser vos résultats.
Étape 4 : Ajouter des colonnes et une visualisation
Dans le panneau Colonnes, cliquez sur Ajouter. Choisissez Temps - Mise à jour du ticket > Mise à jour - Date pour afficher les résultats quotidiens. Cliquez sur Appliquer.
Dans le menu Visualisations, choisissez le type de graphique Colonne. Dans le menu de configuration du graphique :
- Cliquez sur Graphique et cochez Empilé
- Décochez Valeurs agrégées
- Cliquez sur Valeurs affichées et choisissez d’afficher les valeurs à l’intérieur des colonnes
Cliquez sur Enregistrer pour enregistrer votre rapport. Vous pouvez maintenant l’ajouter à un tableau de bord ou le rouvrir à partir de la bibliothèque plus tard.
Créer des mesures personnalisées pour un suivi avancé
Parfois, les mesures intégrées ne vous donnent pas exactement ce dont vous avez besoin. Voici deux scénarios courants où les mesures calculées aident.
Mesure de la date de première résolution
Utilisez ceci lorsque vous voulez suivre quand les tickets ont été résolus pour la première fois, même s’ils ont été rouverts plus tard. Ceci est utile pour mesurer les taux de résolution au premier contact.
Pour le créer :
- Dans votre rapport, cliquez sur le menu des calculs (icône de calculatrice)
- Choisissez Mesure calculée standard
- Nommez-le « Date de la première mise à jour résolue »
- Collez cette formule :
IF ([Modifications - Nom du champ] = "status" AND [Modifications - Nouvelle valeur] = "solved"
AND [Modifications - Valeur précédente] != "solved" AND [Mise à jour - Horodatage] =
DATE_FIRST_FIX([Mise à jour - Horodatage], [ID du ticket], [Modifications - Nom du champ]))
THEN [ID du ticket de mise à jour]
ENDIF
- Cliquez sur Enregistrer
Source : Centre d’aide Zendesk - Création d’une mesure de la date de la première résolution d’un ticket
Pourcentage résolu dans le SLA
Vous voulez suivre quel pourcentage de tickets respectent vos objectifs de SLA ? Vous aurez besoin de deux mesures calculées.
Tout d’abord, créez une mesure pour les tickets résolus dans votre seuil (exemple : 20 minutes) :
IF (VALUE(Temps de résolution complète (min)) < 20 AND [Statut du ticket - Non trié] = "Solved")
THEN [ID du ticket]
ENDIF
Ensuite, créez une mesure de pourcentage :
COUNT(Tickets résolus en moins de 20 minutes) / COUNT(Tickets résolus)
Formatez ceci en pourcentage et appliquez-le à vos rapports. Vous pouvez ajuster le seuil (20 minutes) pour qu’il corresponde à votre SLA.
Source : Geckoboard - % de tickets résolus en moins de 20 minutes
Erreurs courantes et comment les éviter
Même les administrateurs expérimentés font ces erreurs. Voici ce qu’il faut surveiller.
Erreur 1 : Utiliser l’ensemble de données Tickets pour l’analyse des tendances
L’ensemble de données Tickets montre l’état actuel, pas les événements historiques. Si vous essayez de créer un rapport « créé vs résolu par date » en utilisant l’ensemble de données Tickets, vos chiffres ne correspondront pas à la réalité. Utilisez toujours l’ensemble de données Historique des mises à jour pour les rapports de tendances.
Erreur 2 : Ignorer les heures ouvrables vs les heures du calendrier
Zendesk suit les deux. Si votre SLA est basé sur les heures ouvrables, mais que vous regardez les heures du calendrier dans votre rapport, vous obtiendrez des résultats trompeurs. Vérifiez quelle mesure de temps vous utilisez :
- Heures du calendrier : « Temps de résolution complète (min) »
- Heures ouvrables : « Temps de résolution complète - Heures ouvrables (min) »
Erreur 3 : Ne pas tenir compte de la marge d’erreur
Zendesk reconnaît que certains calculs dans l’ensemble de données Historique des mises à jour ont une petite marge d’erreur en raison de la façon dont les mesures sont calculées. Pour la plupart des rapports opérationnels, cela n’a pas d’importance. Mais si vous faites des calculs financiers précis ou des tableaux de bord exécutifs, validez vos chiffres par rapport aux données au niveau du ticket.
Source : Zendesk - Rapports sur les tickets créés et résolus
Erreur 4 : Double comptage des transitions résolu à fermé
La mesure « Tickets résolus » dans l’ensemble de données Historique des mises à jour exclut déjà les transitions résolu à fermé. Mais si vous créez des formules personnalisées, assurez-vous de ne pas compter ces transitions comme des résolutions distinctes.
Conseils de validation
- Vérifiez ponctuellement des exemples de tickets par rapport aux chiffres de votre rapport
- Comparez les « Tickets résolus » dans l’historique des mises à jour aux « Tickets résolus » dans l’ensemble de données Tickets pour la même période. Ils devraient être proches (bien que pas identiques en raison des tickets rouverts).
- Testez les mesures calculées avec une petite plage de dates d’abord
Aller au-delà des rapports de base avec notre agent d’IA
Zendesk Explore est puissant, mais il nécessite la création manuelle de rapports, la connaissance des ensembles de données et l’écriture de formules. Pour les équipes qui veulent des informations sur la résolution sans la complexité, il existe une autre option.
Notre agent d’IA s’intègre directement à Zendesk et fournit un suivi autonome de la résolution. Au lieu de créer des rapports, vous obtenez :
- Des informations sur la résolution en temps réel sans formules personnalisées
- Des requêtes en langage naturel - demandez « combien de tickets avons-nous résolus cette semaine ? » au lieu de naviguer dans les ensembles de données
- Un suivi automatisé des taux de résolution, de la conformité aux SLA et des performances des agents
- Aucune maintenance manuelle des rapports - les informations se mettent à jour automatiquement au fur et à mesure que les tickets circulent dans votre système
Pour les équipes qui utilisent déjà Zendesk, nous travaillons aux côtés de votre configuration existante. Notre IA apprend de vos tickets passés, de votre centre d’aide et de vos macros pour fournir des informations qui correspondent à votre contexte commercial spécifique.
Si vous passez plus de temps à créer des rapports qu’à agir sur les informations, il est peut-être temps d’envisager une approche qui gère l’analyse automatiquement.
Foire aux questions
Partager cet article
Article by
Stevia Putri
Stevia Putri is a marketing generalist at eesel AI, where she helps turn powerful AI tools into stories that resonate. She’s driven by curiosity, clarity, and the human side of technology.
