> ## 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.

# Leer las métricas de first-reply time: qué incluye el número y cómo moverlo

> Distinguir el first reply time del resolution time, encontrar la métrica first-reply de 30 días en Inbox → Analytics y en el informe SLA, y leer cómo el mix de canales y las disposiciones cambian lo que el número incluye — con ejemplos de cálculo resueltos.

# Leer las métricas de first-reply time: qué incluye el número

El first-reply time (también llamado first-response time) es la cifra SLA más citada del inbox, y la más mal leída. Esta página es la semántica: qué mide realmente la métrica, dónde viven las cifras de 30 días y qué cuenta y qué no cuenta en ella. Una vez que la lee correctamente, las páginas [Motor de temporizadores SLA](https://docs.orbit.devotel.io/guides/inbox-sla-timers.md) y [Informe SLA](https://docs.orbit.devotel.io/guides/inbox-sla-report-reading.md) retoman la mecánica y la vista de breaches en vivo.

## 1. First reply time frente a resolution time

Dos relojes miden promesas distintas:

* **First reply time** — tiempo transcurrido desde el primer mensaje entrante del cliente hasta la primera respuesta que envía su equipo. Mide *cuánto tiempo estuvo un cliente sin ninguna respuesta*.
* **Resolution time** — tiempo transcurrido desde la apertura de la conversación hasta el momento en que se cierra. Mide *cuánto tardó el problema completo*.

Una resolución de cinco minutos en un hilo antiguo puede seguir siendo un breach de first reply; una primera respuesta de un minuto seguida de una resolución de tres días es un breach de resolución. Léalos siempre por separado. (Un tercer reloj, por completitud: **next-response time** — la espera tras el mensaje de seguimiento del cliente — se reinicia con cada recontacto.)

Un solo predicado decide si el reloj de first reply existe: solo arranca con un mensaje **entrante**. Un hilo iniciado por el agente que el cliente nunca respondió — una campaña, una nota proactiva, una llamada saliente — no lleva reloj de first reply, así que nunca puede contar como breach de first reply y nunca diluye la métrica. Esto importa en los denominadores de abajo.

## 2. Dónde se lee la métrica first-reply de 30 días

Tres superficies, tres preguntas distintas:

* **Inbox → Analytics → Team performance** — la superficie de revisión. La tarjeta **First-response SLA** muestra la *proporción* de primeras respuestas dentro del objetivo como porcentaje (verde por encima de 95 %, ámbar 80–95 %, rojo por debajo de 80 %); la tabla **Per-agent breakdown** lleva el mismo porcentaje por agente, y al desplegar **More metrics** se añade **Avg first reply** — los segundos brutos detrás del porcentaje. Elija **Last 30 days** en el selector de ventana y la fila que captura en la revisión semanal es la cifra first-reply estándar de 30 días.
* **Inbox → SLA report** — la superficie en vivo. Responde «cuántos hilos están por encima de la línea de first reply *ahora mismo*», más un desglose por canal. Siempre muestra el estado actual, no el promedio histórico. Véase [Leer el informe SLA del inbox](https://docs.orbit.devotel.io/guides/inbox-sla-report-reading.md).
* **[Políticas de escalado SLA](https://docs.orbit.devotel.io/inbox/sla-escalation-policies.md)** — no es un lector de métricas, sino el lugar que consume la misma lógica de breach a nivel de cola: una política de escalado por cola digital decide qué ocurre cuando los breaches de first reply se acumulan. Lea la métrica en Analytics o en el informe SLA; actúe sobre ella con políticas de escalado.

La discrepancia a esperar: el porcentaje de Analytics es una cifra de *cumplimiento* a 30 días; el recuento del informe SLA es una instantánea de *breach* en vivo. No coincidirán, y ambos tienen razón.

## 3. Cómo el mix de canales ensancha o estrecha la ventana

El promedio de first reply es un mix, y el mix se mueve cuando se mueve el volumen por canal. Si su política de WhatsApp corre con un objetivo de 30 minutos y el email con un objetivo de cuatro horas, una semana de mucho volumen de WhatsApp tira del promedio agregado hacia **abajo** aunque la velocidad por canal no cambie — y un repunte de SMS nocturno lo tira hacia **arriba** cuando políticas con `business_hours_only` detienen el reloj de noche.

Regla práctica: antes de dar una tendencia por real, abra la fila **SLA by channel** del informe SLA y compare el cumplimiento por canal, y relea el agregado solo cuando el mix de canales esté estable. Un drill en **More metrics** de la tabla Per-agent resuelve si el promedio bruto se movió para un canal o para todos.

## 4. Cómo afectan las disposiciones al cómputo del first-reply

Las disposiciones son etiquetas de resultado a nivel de conversación (Resolved, Refund issued, Escalated). Se adjuntan al **cierre** de una conversación — es decir, a la resolución, no a la primera respuesta. El first-reply time arranca con el primer mensaje entrante y se detiene con la primera respuesta saliente, independientemente de cómo se dispositione después la conversación.

Dónde *sí* entran las disposiciones en el cuadro del first reply:

* **La etiqueta se estampa al cerrar**, así que una conversación cerrada sin haber enviado jamás una primera respuesta (spam, un hilo de número equivocado) sigue contando en el resolution time pero deja el reloj de first reply sin responder. Si usted dispositiona estos casos en su propia etiqueta (por ejemplo, «No response needed»), filtre su lectura para excluirlos — de lo contrario inflan el promedio de resolución mientras el porcentaje de first response queda limpio.
* **Las conversaciones reabiertas** (una reapertura dentro de su ventana de recontacto) reinician el reloj de resolución, pero el reloj de first reply ya fue respondido una vez y sigue respondido. Las disposiciones de limpieza mantienen estos hilos fuera del conjunto de reabiertas.

Para diseñar esos conjuntos de etiquetas de modo que el reporting quede limpio, véase [Diseñar disposiciones de inbox](https://docs.orbit.devotel.io/guides/inbox-dispositions.md).

## 5. Ejemplos de cálculo

Trabajados con el estilo de caso usado en [Unified inbox SLA engine](https://docs.orbit.devotel.io/guides/inbox-sla-timers.md). Rigen umbrales sintéticos por defecto hasta que usted adjunte una política (4 h de first response, 24 h de resolución, solo horas hábiles):

**Ejemplo A — primera respuesta dentro del objetivo, resolución por encima.** Un cliente escribe a las 09:12; el operador responde a las 09:37 (first reply de 25 minutos), y la conversación cierra a las 11:47 (resolución de 2 h 35 min). Resultado: first response *no* breached (por debajo de 4 h), resolución *no* breached (por debajo de 24 h) — pero lea los relojes por separado, porque una resolución más larga habría sido un breach de resolución mientras la primera respuesta quedaba limpia.

**Ejemplo B — hilo iniciado por el agente, sin reloj de first reply.** Un mensaje de campaña saliente sale a las 14:00; el cliente nunca responde. Resultado: no existe reloj de first reply, así que ningún breach de first response puede dispararse jamás; el resolution time corre de la apertura al cierre contra el objetivo por defecto de 24 h (o el objetivo de su política). No deje que tales hilos diluyan su porcentaje de first response — quedan excluidos por el predicado de mensaje entrante, no por usted.

**Ejemplo C — una política de horas hábiles congela el reloj de first reply.** Un cliente escribe el viernes a las 17:40; su espacio declara un horario laboral de lu–vi 09:00–18:00 y la política tiene `business_hours_only: true`. El operador responde el lunes a las 09:05. Resultado: la primera respuesta cuenta solo las horas hábiles entre el mensaje y la respuesta — 17:40–18:00 (20 minutos) más 5 minutos del lunes por la mañana = 25 minutos contra un objetivo de 30 minutos: dentro.

**Ejemplo D — porcentaje de cumplimiento a 30 días desde datos brutos.** En la página Team performance con Last 30 days: 1,842 conversaciones entrantes con primera respuesta; 1,774 enviadas dentro del objetivo. First-response SLA = 1,774 / 1,842 = 96.3 % — verde. La columna **Avg first reply** lee los segundos brutos de esas 1,842 primeras respuestas; el porcentaje y el promedio responden preguntas distintas y ambos aparecen en la página.

## 6. Leer la métrica por la API

Las cifras de Team performance también se resuelven en una familia de endpoints — `GET /api/v1/inbox/team-performance/agents` (rollup por agente) y `GET /api/v1/inbox/team-performance/trends` (serie diaria) — de modo que el porcentaje que la página renderiza es reproducible por programa: `days` acota la ventana de mirada atrás (1–90; el «Last 30 days» de la página es `days=30`), y `fcr_window_hours` acota la ventana de recontacto (24 por defecto).

```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"
```

Ningún SDK tipado cubre estas rutas — recurra a fetch crudo según [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.
```

**Respuesta — 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" }
}
```

Lea los campos por agente como la página lee el ejemplo D: `first_response_sla_attainment` es el porcentaje de cumplimiento 0–100, y `avg_first_response_seconds` son los segundos brutos detrás — las mismas dos superficies que muestran la tarjeta Team performance y la tabla por agente. El endpoint `/trends` acompañante devuelve una fila por día en la ventana, de modo que la serie `first_response_sla_attainment` grafica el cumplimiento en el tiempo en lugar de un único rollup de 30 días.

## 7. Dos lecturas: tendencia o anomalía, dotación o habilidad

Lea la serie diaria antes de considerar real un cambio. Una caída del 96 % al 89 % durante tres días seguida de un regreso al 96 % es una anomalía: compruebe una caída de cola, un pico de campaña o el mix de canales antes de cambiar la dotación. Una caída que persiste con volumen y mix estables es una tendencia; compare las filas de agentes antes de cambiar el objetivo.

Cuando baja el promedio del equipo, separe **dotación** de **habilidad**. Si todos los agentes empeoran los mismos días, la causa probable es la cobertura o el volumen entrante. Si se mueve un agente o canal mientras sus pares permanecen planos, revise las conversaciones y el recorrido de coaching para detectar una causa de habilidad o flujo de trabajo. Lleve la evidencia a las [evaluaciones QA](https://docs.orbit.devotel.io/guides/quality-evaluations.md) y practique después el patrón fallido en [Practice Studio Roleplay](https://docs.orbit.devotel.io/guides/practice-studio-roleplay.md).

## Lo que no es el first-reply time

El first-reply time no es el resolution time, ni el recuento de breaches en vivo, ni una promesa de que toda conversación recibió respuesta. Excluye los hilos iniciados por agentes sin mensaje entrante; para explicar un retraso, revise también el canal, la cobertura y el contexto del agente.

## Véase también

* [Unified inbox SLA engine](https://docs.orbit.devotel.io/guides/inbox-sla-timers.md) — la mecánica de temporizadores que esta página lee semánticamente
* [Leer el informe SLA del inbox](https://docs.orbit.devotel.io/guides/inbox-sla-report-reading.md) — la superficie de breach en vivo
* [Analytics de rendimiento de equipo](https://docs.orbit.devotel.io/guides/inbox-team-performance.md) — el soporte de revisión a 30 días donde viven First-response SLA y Avg first reply
* [Políticas de escalado SLA por cola digital](https://docs.orbit.devotel.io/inbox/sla-escalation-policies.md) — tratar los breaches de first reply recurrentes a nivel de cola
* [Diseñar disposiciones de inbox](https://docs.orbit.devotel.io/guides/inbox-dispositions.md) — conjuntos de etiquetas que mantienen limpio el reporting de cierre


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