> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Lire les métriques de first-reply time : ce que le chiffre inclut, et comment le faire bouger

> Distinguer le first reply time du resolution time, trouver la métrique first-reply sur 30 jours dans Inbox → Analytics et dans le rapport SLA, et lire comment le mix de canaux et les dispositions changent ce que le chiffre inclut — avec des exemples de calcul détaillés.

# 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](https://docs.orbit.devotel.io/guides/inbox-sla-timers.md) et [Rapport SLA](https://docs.orbit.devotel.io/guides/inbox-sla-report-reading.md) 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](https://docs.orbit.devotel.io/guides/inbox-sla-report-reading.md).
* **[Politiques d'escalade SLA](https://docs.orbit.devotel.io/inbox/sla-escalation-policies.md)** — 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](https://docs.orbit.devotel.io/guides/inbox-dispositions.md).

## 5. Exemples de calcul

Travaillés dans le style de cas utilisé par [Unified inbox SLA engine](https://docs.orbit.devotel.io/guides/inbox-sla-timers.md). 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).

```bash cURL theme={null}
curl "https://api.orbit.devotel.io/api/v1/inbox/team-performance/agents?days=30&limit=50" \
  -H "X-API-Key: dv_live_sk_your_key_here"
```

Aucun SDK typé ne couvre ces routes — revenez à un fetch brut selon [How to read a worked sample](https://docs.orbit.devotel.io/guides/using-orbit-samples.md) :

```typescript fetch theme={null}
const res = await fetch(
  `https://api.orbit.devotel.io/api/v1/inbox/team-performance/agents?days=30&limit=50`,
  { headers: { "X-API-Key": process.env.ORBIT_API_KEY! } },
);
const { data } = await res.json();
// data.totals.first_response_sla_attainment — the team headline; each agents[] row carries the same percentage + raw seconds.
```

**Réponse — 200 OK**

```json theme={null}
{
  "data": {
    "agents": [
      {
        "agent_id": "usr_8a2c…",
        "display_name": "Maya",
        "tickets_total": 214,
        "avg_first_response_seconds": 1543,
        "first_response_sla_attainment": 97.2,
        "avg_resolution_seconds": 13140,
        "resolution_sla_attainment": 92.5
      }
    ],
    "totals": {
      "active_agents": 12,
      "tickets_total": 1842,
      "first_response_sla_attainment": 96.3,
      "resolution_sla_attainment": 93.8
    }
  },
  "meta": { "request_id": "req_abc123" }
}
```

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](https://docs.orbit.devotel.io/guides/quality-evaluations.md), puis répétez le schéma manqué dans [Practice Studio Roleplay](https://docs.orbit.devotel.io/guides/practice-studio-roleplay.md).

## 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](https://docs.orbit.devotel.io/guides/inbox-sla-timers.md) — la mécanique des minuteurs que cette page lit sémantiquement
* [Lire le rapport SLA de l'inbox](https://docs.orbit.devotel.io/guides/inbox-sla-report-reading.md) — la surface de breach en direct
* [Analytics de performance d'équipe](https://docs.orbit.devotel.io/guides/inbox-team-performance.md) — le support de revue sur 30 jours où vivent First-response SLA et Avg first reply
* [Politiques d'escalade SLA par file numérique](https://docs.orbit.devotel.io/inbox/sla-escalation-policies.md) — traiter les breaches de first reply récurrents au niveau de la file
* [Concevoir les dispositions d'inbox](https://docs.orbit.devotel.io/guides/inbox-dispositions.md) — des jeux d'étiquettes qui gardent un reporting de clôture propre


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.