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.
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.
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 politiquesbusiness_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.
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 portebusiness_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
fetch
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
- Unified inbox SLA engine — la mécanique des minuteurs que cette page lit sémantiquement
- Lire le rapport SLA de l’inbox — la surface de breach en direct
- Analytics de performance d’équipe — le support de revue sur 30 jours où vivent First-response SLA et Avg first reply
- Politiques d’escalade SLA par file numérique — traiter les breaches de first reply récurrents au niveau de la file
- Concevoir les dispositions d’inbox — des jeux d’étiquettes qui gardent un reporting de clôture propre