Skip to main content

Lire les métriques de first-reply time : ce que le chiffre inclut

Le first-reply time (aussi appelé first-response time) est le chiffre SLA le plus cité de l’inbox, et le plus mal lu. Cette page en est la sémantique : ce que la métrique mesure réellement, où se trouvent les valeurs sur 30 jours, et ce qui compte ou non dans son calcul. Une fois que vous la lisez correctement, les pages Moteur de minuteurs SLA et Rapport SLA prennent le relais pour la mécanique et la vue des breaches en direct.

1. First reply time et resolution time

Deux horloges mesurent deux promesses différentes :
  • First reply time — temps écoulé entre le premier message entrant du client et la première réponse envoyée par votre équipe. Il mesure combien de temps un client est resté sans aucune réponse.
  • Resolution time — temps écoulé entre l’ouverture de la conversation et le moment de sa clôture. Il mesure combien de temps a pris l’ensemble du problème.
Une résolution en cinq minutes sur un ancien thread peut quand même constituer un breach de first reply ; une première réponse en une minute suivie d’une résolution en trois jours est un breach de résolution. Lisez-les toujours séparément. (Troisième horloge, pour être complet : next-response time — l’attente après le message de suivi du client — redémarre à chaque recontact.) Un seul prédicat décide si l’horloge de first reply existe : elle ne démarre que sur un message entrant. Un thread initié par un agent auquel le client n’a jamais répondu — une campagne, une note proactive, un appel sortant — ne porte aucune horloge de first reply, ne peut donc jamais compter comme breach de first reply et ne dilue jamais la métrique. Cela compte dans les dénominateurs ci-dessous.

2. Où lire la métrique first-reply sur 30 jours

Trois surfaces, trois questions différentes :
  • Inbox → Analytics → Team performance — la surface de revue. La carte First-response SLA montre la part des premières réponses dans l’objectif, en pourcentage (vert au-dessus de 95 %, ambre entre 80 et 95 %, rouge en dessous de 80 %) ; le tableau Per-agent breakdown porte le même pourcentage par agent, et déplier More metrics ajoute Avg first reply — les secondes brutes derrière le pourcentage. Choisissez Last 30 days dans le sélecteur de fenêtre, et la ligne que vous capturez lors de la revue hebdomadaire est le chiffre first-reply standard sur 30 jours.
  • Inbox → SLA report — la surface en direct. Répond à « combien de threads dépassent la ligne de first reply en ce moment », avec une ventilation par canal. Elle montre toujours l’état courant, pas la moyenne historique. Voir Lire le rapport SLA de l’inbox.
  • Politiques d’escalade SLA — pas un lecteur de métrique, mais l’endroit qui consomme la même logique de breach au niveau de la file : une politique d’escalade par file numérique décide ce qui se passe quand les breaches de first reply s’accumulent. Lisez la métrique dans Analytics ou dans le rapport SLA ; agissez dessus avec les politiques d’escalade.
L’écart à attendre : le pourcentage d’Analytics est un chiffre d’atteinte sur 30 jours ; le décompte du rapport SLA est un instantané de breach en direct. Ils ne coïncideront pas, et les deux ont raison.

3. Comment le mix de canaux élargit ou resserre la fenêtre

La moyenne de first reply est un mix, et le mix bouge quand les volumes par canal bougent. Si votre politique WhatsApp tient un objectif de 30 minutes et l’email un objectif de quatre heures, une semaine à fort volume WhatsApp tire la moyenne agrégée vers le bas même si la vitesse par canal ne change pas — et un pic SMS en fin de soirée la tire vers le haut quand des politiques business_hours_only gèlent l’horloge la nuit. Règle pratique : avant de déclarer une tendance réelle, ouvrez la ligne SLA by channel du rapport SLA et comparez l’atteinte par canal, puis ne relisez l’agrégat qu’une fois le mix de canaux stabilisé. Un forage dans More metrics du tableau Per-agent permet de savoir si la moyenne brute a bougé pour un canal ou pour tous.

4. Comment les dispositions affectent le calcul du first-reply

Les dispositions sont des étiquettes de résultat au niveau de la conversation (Resolved, Refund issued, Escalated). Elles s’attachent à la clôture d’une conversation — c’est-à-dire à la résolution, pas à la première réponse. Le first-reply time démarre au premier message entrant et s’arrête à la première réponse sortante, quelle que soit la disposition appliquée ensuite à la conversation. Là où les dispositions entrent malgré tout dans le tableau du first reply :
  • L’étiquette est apposée à la clôture, donc une conversation fermée sans qu’aucune première réponse ait jamais été envoyée (spam, thread de mauvais numéro) compte toujours dans le resolution time mais laisse l’horloge de first reply sans réponse. Si vous rangez ces cas dans leur propre étiquette (par exemple « No response needed »), filtrez votre lecture pour les exclure — sinon ils gonflent la moyenne de résolution pendant que le pourcentage de first response reste propre.
  • Les conversations rouvertes (une réouverture dans votre fenêtre de recontact) redémarrent l’horloge de résolution, mais l’horloge de first reply a déjà reçu une réponse et reste répondue. Les dispositions de nettoyage tiennent ces threads hors de l’ensemble des rouvertes.
Pour concevoir ces jeux d’étiquettes de façon à garder un reporting propre, voir Concevoir les dispositions d’inbox.

5. Exemples de calcul

Travaillés dans le style de cas utilisé par Unified inbox SLA engine. Des seuils synthétiques par défaut s’appliquent tant que vous n’attachez pas de politique (4 h de first response, 24 h de résolution, heures ouvrées uniquement) : Exemple A — première réponse dans l’objectif, résolution dépassée. Un client écrit à 09:12 ; l’opérateur répond à 09:37 (first reply de 25 minutes), et la conversation se clôture à 11:47 (résolution de 2 h 35). Résultat : first response non breached (sous 4 h), résolution non breached (sous 24 h) — mais lisez les horloges séparément, car une résolution plus longue aurait été un breach de résolution pendant que la première réponse restait propre. Exemple B — thread initié par l’agent, pas d’horloge de first reply. Un message de campagne sortant part à 14:00 ; le client ne répond jamais. Résultat : aucune horloge de first reply n’existe, donc aucun breach de first response ne peut jamais se déclencher ; le resolution time court de l’ouverture à la clôture contre l’objectif par défaut de 24 h (ou l’objectif de votre politique). Ne laissez pas de tels threads diluer votre pourcentage de first response — ils sont exclus par le prédicat de message entrant, pas par vous. Exemple C — une politique en heures ouvrées gèle l’horloge de first reply. Un client écrit vendredi à 17:40 ; votre espace déclare des heures ouvrées lun–ven 09:00–18:00 et la politique porte business_hours_only: true. L’opérateur répond lundi à 09:05. Résultat : la première réponse ne compte que les heures ouvrées entre le message et la réponse — 17:40–18:00 (20 minutes) plus 5 minutes le lundi matin = 25 minutes contre un objectif de 30 minutes : dans l’objectif. Exemple D — pourcentage d’atteinte sur 30 jours à partir des données brutes. Sur la page Team performance avec Last 30 days : 1 842 conversations entrantes avec une première réponse ; 1 774 envoyées dans l’objectif. First-response SLA = 1 774 / 1 842 = 96,3 % — vert. La colonne Avg first reply lit les secondes brutes de ces 1 842 premières réponses ; le pourcentage et la moyenne répondent à des questions différentes et figurent tous deux sur la page.

6. Lire la métrique via l’API

Les chiffres de Team performance se résolvent aussi en une famille d’endpoints — GET /api/v1/inbox/team-performance/agents (agrégat par agent) et GET /api/v1/inbox/team-performance/trends (série quotidienne) — si bien que le pourcentage que la page affiche est reproductible par programme : days borne la fenêtre de regard en arrière (1–90 ; le « Last 30 days » de la page est days=30), et fcr_window_hours borne la fenêtre de recontact (24 par défaut).
cURL
Aucun SDK typé ne couvre ces routes — revenez à un fetch brut selon How to read a worked sample :
fetch
Réponse — 200 OK
Lisez les champs par agent comme la page lit l’exemple D : first_response_sla_attainment est le pourcentage d’atteinte 0–100, et avg_first_response_seconds les secondes brutes derrière — les deux mêmes surfaces que montrent la carte Team performance et le tableau par agent. L’endpoint /trends associé renvoie une ligne par jour dans la fenêtre, si bien que la série first_response_sla_attainment trace l’atteinte dans le temps plutôt qu’un agrégat unique sur 30 jours.

7. Deux lectures : tendance ou anomalie, effectif ou compétence

Lisez la série quotidienne avant de considérer une variation comme réelle. Une baisse de 96 % à 89 % pendant trois jours, suivie d’un retour à 96 %, est une anomalie : vérifiez une panne de file, un pic de campagne ou le mix de canaux avant de modifier les effectifs. Une baisse qui persiste avec un mix de canaux et un volume stables est une tendance ; comparez les lignes des agents avant de modifier la cible. Quand la moyenne de l’équipe baisse, séparez effectif et compétence. Si tous les agents baissent les mêmes jours, la couverture ou le volume entrant est probablement en cause. Si un agent ou un canal bouge tandis que les autres restent stables, examinez les conversations et le parcours de coaching pour trouver une cause de compétence ou de workflow. Transmettez les éléments aux évaluations QA, puis répétez le schéma manqué dans Practice Studio Roleplay.

Ce que le first-reply time n’est pas

Le first-reply time n’est ni le resolution time, ni le nombre de breaches en direct, ni la promesse que chaque conversation a reçu une réponse. Il exclut les threads initiés par un agent sans message entrant ; pour expliquer un retard, examinez aussi le canal, la couverture et le contexte de l’agent.

Voir aussi