Peut-être planifiez-vous des exportations de rapports de tableau de bord Explore pour distribuer des PDF à votre équipe. Ou alors, vous extrayez les chiffres manuellement tous les mois pour les reporter dans une feuille de calcul. Vous pouvez aussi créer des rapports dans Explore pour les mêmes chiffres. Si ces méthodes donnent des résultats différents, cela peut prêter à confusion : pourquoi les chiffres ne correspondent-ils pas ?
Quand vous analysez ces différences, n’oubliez pas que les PDF et les feuilles de calcul sont statiques alors qu’Explore est dynamique.
Cet article aborde les sujets suivants :
Pourquoi des résultats différents ?
Supposons par exemple que le 1er août, vous avez exporté des données pour tout le mois de juillet et les avez placées dans une feuille de calcul. Mais plus tard, en septembre, vous générez un autre rapport sur les mêmes données dans Explore et les résultats pour le mois de juillet sont différents.
| Colonne pour juillet dans une exportation effectuée en août | Colonne pour juillet dans un rapport généré dans Explore en septembre |
 |
 |
Pour en savoir plus :
Pourquoi y a-t-il une différence pour les tickets créés ?
Le nombre total de tickets créés peut baisser si vous en avez supprimé certains.
Les tickets supprimés le sont aussi du jeu de données Tickets. Ainsi, si vous marquez des tickets comme spam ou les supprimez pour toute autre raison, ces tickets sont déduits du nombre total de tickets. Cela change donc aussi le nombre de tickets créés.
Dans l’exemple ci-dessus, le nombre de tickets créés est passé de 705 à 693. Cela suggère que 12 tickets ont été supprimés entre l’exportation des données en août et la génération du rapport dans Explore en septembre.
Mais le nombre total de tickets créés peut augmenter si vous avez récupéré des tickets supprimés.
Pour examiner le nombre de tickets supprimés et le nombre de tickets récupérés, vous pouvez utiliser les mesures Suppressions et Récupérations dans le jeu de données Updates history.
Pour la mesure Suppressions, vous ne voyez pas de détails comme l’ID du ticket ou autres attributs (car les tickets ont été supprimés), mais vous pouvez voir :
- Quand les tickets ont été supprimés, en utilisant l’attribut Mise à jour - Horodatage.
- Qui a supprimé les tickets, en utilisant l’attribut Nom du responsable de la mise à jour.
Pour la mesure Récupérations, vous pouvez consulter des informations similaires (quand les tickets ont été récupérés et par qui), mais aussi les autres attributs des tickets comme l’ID du ticket (car les tickets existent à nouveau).
Pourquoi y a-t-il une différence pour les tickets résolus ?
En général, vous examinez les tickets créés en utilisant l’attribut Ticket créé - Date et les tickets résolus en utilisant l’attribut Ticket résolu - Date. Cependant, dans ces scénarios, les chiffres fluctuent en fonction de certains événements.
Si vous consultez les tickets par date de résolution, ces chiffres sont affectés par la mesure Réouvertures (disponible dans les jeux de données Tickets et Updates history). Ce chiffre change si les tickets sont rouverts entre l’exportation des données et la génération du rapport dans Explore. Une réouverture peut totalement supprimer un ticket de cette mesure (car il n’est plus résolu) ou le déplacer d’une période à une autre (si la dernière résolution a eu lieu dans une autre période que la première résolution).
Si vous consultez les tickets par date de création, ces chiffres sont affectés par les résolutions au fil du temps. Si 10 tickets ont été créés le lundi et 2 tickets ont été résolus le même jour, une exportation montre 2 tickets résolus pour le lundi. Si 3 autres tickets sont résolus le mardi, le rapport et l’exportation suivante montrent que 5 tickets résolus ont été créés le lundi.
La mesure Tickets résolus dans le jeu de données Updates history n’examine que la dernière résolution des tickets actuellement résolus. Vous pouvez le voir en regardant la formule de la mesure, en particulier les deux conditions en gras :
IF ([Changes - Field name]="status"
AND [Changes - Previous value]!="solved"
AND ([Changes - New value]="solved" OR [Changes - New value]="closed")
AND ([Ticket status - Unsorted] = "Solved" OR [Ticket status - Unsorted] = "Closed")
AND [Update - Timestamp]=[Ticket solved - Timestamp])
THEN [Update ID]
ENDIF
Si vous voulez suivre toutes les résolutions, vous pouvez créer une mesure calculée standard qui élimine ces deux conditions pour l’état actuel et la date, avec donc la formule suivante :
IF ([Changes - Field name]="status"
AND [Changes - Previous value]!="solved"
AND ([Changes - New value]="solved" OR [Changes - New value]="closed"))
THEN [Update ID]
ENDIF
Pourquoi y a-t-il une différence pour les tickets d’une certaine catégorie ?
Le jeu de données Tickets examine l’état actuel des tickets (statut, groupe, assigné, priorité, champs personnalisés, etc.). Ainsi, si un champ change entre l’exportation et la génération d’un rapport dans Explore, vos résultats risquent de changer.
Dans les exemples d’écrans ci-dessus, vous voyez que l’exportation montre 10 blips et 61 bugs, alors que le rapport de septembre montre 2 blips et 69 bugs. Cela suggère que 8 tickets ont été reclassés de blips en bugs entre l’exportation et la génération du rapport.
Ce genre de changement peut aussi affecter les filtres de votre rapport. Par exemple, supposons que vous avez un rapport filtré afin de n’afficher que les tickets du groupe A. Si un ticket est transféré du groupe A à un autre groupe entre l’exportation et la génération du rapport, ce ticket n’est pas inclus dans le rapport.
L’inverse est vrai pour les tickets initialement affectés au groupe B puis réaffectés au groupe A. Votre rapport inclura plus de tickets qu’auparavant, à cause du filtre.
Ne pas oublier que les chiffres sont relatifs
Quand vous analysez les différences entre les rapports Explore et les exportations, il est utile de ne pas oublier que les chiffres sont relatifs. Quelques exemples :
- Si un résultat passe de 20 tickets à 21, c’est une hausse de 1. Cela semble insignifiant et pourtant c’est un changement de 5 %.
- Si un autre résultat passe de 1998 à 2100, l’écart est de 102. Cela peut sembler significatif et pourtant ce n’est qu’un changement de 5 %.
Quand il y a des variations, prenez en compte le pourcentage, pas seulement le chiffre brut. Cela peut vous aider à comprendre ce qui est important ou non.
Réfléchissez au nombre d’agents que vous avez. Si vous avez 200 agents et qu’un résultat enregistre une variation de 102, cela suggère qu’environ la moitié de vos agents, en moyenne, ont modifié ce champ dans un ticket entre l’exportation et la génération du rapport dans Explore.
Ici aussi, vous pouvez examiner ces résultats dans le jeu de données Updates history. Utilisez l’attribut Nom du responsable de la mise à jour pour filtrer un rapport affichant l’attribut [Modifications - Nom de champ] et le résultat (ancien ou nouveau) qui vous intrigue.
Souvent, vous verrez une vaste distribution des modifications, par exemple 100 agents modifiant environ un champ pendant la période.
Cependant, vous pouvez aussi voir qu’un ou deux agents changent les résultats des champs plus souvent. Il s’agit peut-être d’un manager mettant au propre le travail des membres de son équipe ou d’un nouvel agent qui n’avait pas immédiatement compris comment appliquer le champ, auquel cas il peut être judicieux d’envisager une formation supplémentaire.
Utiliser les bons agrégateurs
Enfin, quand vous examinez la durée, il ne faut pas oublier la différence entre quantité et qualité.
Par défaut, Explore utilise l’agrégateur médian (MED) pour les mesures comme le délai avant première réponse et le délai de résolution. Mais vous avez peut-être des assignés ou des groupes qui ne traitent que très peu de tickets et très différemment de vos agents standards. Il peut s’agir de membres de votre équipe des finances ou de la sécurité qui traitent rarement les tickets et pour lesquels les attentes en termes de temps de réponse ne sont pas les mêmes.
L’utilisation de l’agrégateur MED pour les mesures de durée vous « protègent » de ces cas particuliers. Si vous utilisez l’agrégateur moyen (AVG), cette protection est réduite. Par exemple, supposons que l’équipe des finances est aux prises avec un ticket provenant d’un client depuis 6 mois, alors que le reste de votre équipe résout généralement les tickets en moins d’une semaine. Ce cas particulier a un impact considérable sur l’âge de vos tickets non résolus, surtout si vous utilisez l’agrégateur AVG.
Quand l’équipe Finances finit par résoudre ce ticket, le délai de résolution pour la période pendant laquelle elle le résout peut lui aussi être considérablement affecté, et encore une fois surtout si vous utilisez l’agrégateur AVG.
Conclusion
Les chiffres qui évoluent dans le temps peuvent prêter à confusion. Nous en avons conscience. Surtout si votre supérieur vous demande d’expliquer ces variations. Mais il peut y avoir de nombreuses raisons logiques.
Si ce problème vous préoccupe, réfléchissez aux points discutés ci-dessus et à leur impact potentiel. Si vous avez encore des questions, parcourez la documentation Explore ou la communauté, ou contactez l’assistance client Zendesk.