Six KPIs Freshdesk sélectionnés pour piloter la performance individuelle des agents support sur le volume traité, la vélocité, la qualité de résolution et la conformité SLA, avec les critères de sélection rendus explicites.
| Indicateur | Objet | Type | Formule | Unité |
|---|---|---|---|---|
| Tickets Resolved Number of tickets resolved or closed by the agent in the period. | Ticket | Résultat | COUNT | count |
| Average First Response Time Average time in hours between ticket creation and the agent's first response. | Ticket | Résultat | AVG(first_response_hours) | heures |
| Average Resolution Time Average time in hours between ticket creation and resolution. | Ticket | Résultat | AVG(resolution_hours) | heures |
| Reopen Rate Ratio of tickets reopened over tickets resolved, per agent. | Ticket | Résultat | COUNT_RATIO | % |
| SLA Breach Rate Ratio of tickets where the first response SLA was breached over total tickets assigned to the agent. | Ticket | Prédictif | COUNT_RATIO | % |
| Open Backlog Number of open or pending tickets currently assigned to the agent. | Ticket | Prédictif | COUNT | count |
Freshdesk expose une large gamme d'objets : tickets, conversations, agents, contacts, entreprises, groupes et articles de base de connaissances. Cette intégration se concentre sur les tickets, qui constituent l'unité de travail fondamentale du support client et le seul objet permettant une mesure de performance attribuable et délimitée dans le temps au niveau de l'agent individuel. Des objets tels que les contacts, les entreprises ou les articles de base de connaissances sont riches en données, mais relèvent de la segmentation client et de la gestion de contenu plutôt que de la performance agent. Six KPIs ont été retenus, sélectionnés selon trois critères : capacité à attribuer à un responsable, résistance au gaming, et équilibre entre indicateurs avancés et retardés.
Tickets Resolved comptabilise le nombre de tickets clôturés par un agent sur une période donnée. Reopen Rate mesure la proportion de ces résolutions qui ont été rouvertes par le client. Les deux indicateurs sont conçus pour être lus ensemble, et c'est leur combinaison qui rend chacun fiable. Pris isolément, Tickets Resolved est un indicateur de volume avec un risque de gaming significatif : un agent peut gonfler son compteur en clôturant des tickets prématurément, sans vérifier que le problème du client a réellement été résolu. Reopen Rate agit comme contrepoids direct. Un agent qui clôture superficiellement pour maximiser son volume verra son Reopen Rate augmenter en conséquence, ce qui révèle mécaniquement le comportement. À l'inverse, un Reopen Rate faible dans un contexte de fort volume indique une résolution réelle et durable — la combinaison qu'un responsable support cherche à observer.
La lecture conjointe de Tickets Resolved et de Reopen Rate fait également apparaître une dynamique plus subtile : les agents qui traitent les tickets les plus complexes tendent à afficher des Reopen Rates plus élevés, non par faiblesse d'exécution, mais parce que les problèmes complexes comportent intrinsèquement davantage d'ambiguïté au moment de la clôture. Ce contexte ne peut être lu sur aucun des deux indicateurs pris seul, mais la divergence entre volume et qualité pose la bonne question managériale.
Average First Response Time mesure le délai moyen entre la création du ticket et la première réponse substantielle de l'agent. Average Resolution Time mesure la durée totale moyenne entre la création et la clôture. Ces deux indicateurs occupent des positions différentes dans le cycle de support et révèlent des choses différentes lorsqu'ils sont lus ensemble. Un Average First Response Time court combiné à un Average Resolution Time long indique que l'équipe engage les clients rapidement mais peine à mener les problèmes à terme : c'est la phase d'échanges qui accumule les délais. Le schéma inverse — une première réponse longue avec une résolution finale rapide — suggère que les tickets font la queue avant d'être pris en charge, mais qu'une fois le travail engagé il avance efficacement. Chaque configuration pointe vers un levier opérationnel différent : la couverture horaire dans le premier cas, les processus de triage et d'affectation dans le second.
Average First Response Time porte également un risque de gaming propre : un agent peut envoyer un accusé de réception bref et sans substance pour faire repartir le compteur sans engager réellement le problème du client. Ce comportement est détectable via le Reopen Rate, qui augmente lorsque des premières réponses superficielles ne permettent pas de mener à une vraie résolution. Le groupe de trois indicateurs — première réponse, temps de résolution, taux de réouverture — forme un ensemble auto-correcteur où le gaming d'un indicateur tend à dégrader les autres.
SLA Breach Rate mesure la proportion de tickets pour lesquels l'accord de niveau de service sur la première réponse a été violé. Open Backlog mesure le nombre de tickets ouverts ou en attente actuellement affectés à un agent. Les deux sont des indicateurs avancés : ils décrivent l'état présent de la charge de travail d'un agent plutôt que les résultats de travaux achevés. Leur rôle dans le jeu d'indicateurs est anticipatoire. Un SLA Breach Rate en hausse signale qu'un agent n'est plus en mesure d'honorer ses engagements de réponse, ce qui est un avertissement qui précède la dégradation du temps de première réponse et, en aval, du temps de résolution. Open Backlog fournit l'explication structurelle : un agent dont le backlog croît opère au-delà de sa capacité soutenable, et les violations de SLA en sont la conséquence prévisible.
Le suivi conjoint des deux indicateurs permet aux responsables de distinguer deux causes de violation SLA qui appellent des réponses différentes. Un agent avec un SLA Breach Rate élevé et un Open Backlog faible fait probablement face à des enjeux de complexité ou de compétences sur certains types de tickets. Un agent avec un taux de violation élevé et un backlog large et croissant fait face à un problème de volume qu'aucun changement de comportement individuel ne peut résoudre — la réponse est la réaffectation ou un ajustement de capacité au niveau de l'équipe.
Freshdesk enregistre les événements du cycle de vie des tickets et les champs de temporalité, mais ne mesure pas la qualité de l'interaction elle-même. Un ticket marqué résolu peut correspondre à un échange expert et empathique qui a laissé le client satisfait, ou à une réponse laconique qui a techniquement clôturé le ticket sans adresser la préoccupation sous-jacente. Les données de l'API ne distinguent pas les deux. Les scores de satisfaction client, lorsqu'ils sont activés via le module CSAT de Freshdesk, ne sont pas disponibles via l'API REST v2 standard et sont donc exclus de cette intégration. L'absence de données CSAT est la lacune la plus significative du jeu d'indicateurs : le volume traité, la vélocité et la conformité SLA sont des mesures nécessaires mais non suffisantes de la qualité du support.
Par ailleurs, cette intégration ne capture que les tickets affectés à un agent via le champ de responsable. Les tickets non affectés, traités par automatisation ou résolus via le portail en libre-service sont invisibles aux KPIs par agent. L'exhaustivité de la vue dépend directement de la discipline d'équipe dans l'affectation des tickets : les équipes qui affectent systématiquement chaque ticket entrant produiront des indicateurs fiables ; les équipes où des tickets non affectés s'accumulent ou où les agents travaillent informellement en dehors de l'outil produiront des volumes systématiquement sous-estimés.
Sans connexion et sur la base des données publiques de votre entreprise, nous allons construire un scénario sur-mesure. Dans quelques heures, vous recevrez un mail avec le lien d'accès.
On prépare votre aperçu personnalisé et on vous envoie le lien très vite par email.