> **Can't find what you're looking for?** Use `search_docs` on the docs MCP server at `https://naturgy-comer-documentation-p5mde.vercel.app/api/mcp` to find what you need.

# Resultado, auditoría e indicadores principales

La misma llamada tiene tres lecturas y ninguna sustituye a las otras: el
resultado dice cómo terminó; la auditoría, si un humano la daría por
buena; y el indicador principal, si se cumplió una regla de conducta en un nodo
concreto. Cómo entra y sale la llamada está en
[cómo funciona](/use-cases/atc/explanations/overview). Las cifras de
un periodo, en el [panel](/account/reference/apps/dashboard-atc).

## Alcance

Hoy el canal atiende el **4 %** de la línea. Para pasar al 100 % la
**auditoría** tiene que llegar al **90 %**. Esa nota la pone
Teleperformance escuchando llamadas, en una aplicación de Naturgy; no la
produce el resultado ni ningún indicador principal.

Cada defecto de ese 4 % se multiplica por 25 si el tráfico se abre. Cómo
se elige la muestra sigue abierto: si es al azar, las cifras extrapolan;
si es un filtro (intención, franja, IVR), no. El mecanismo vive aguas
arriba, fuera de este sistema.

Según confirmó negocio, el 90 % está cerca de la paridad con el auditor
humano, medido en la misma aplicación y con la misma taxonomía.

## Resultado

Toda llamada de producción recibe una de cuatro etiquetas, que
particionan el total.

Naturgy distingue dos tipos de pase. Un **traspaso** es el
traspaso a otra plataforma (Operaciones, Ventas, Solar, PRB). Un agente
humano habría hecho ese mismo pase; el cliente oye el cambio de equipo.
Cuenta como E2E. Un **escalado** es el pase a una persona de Atención al
Cliente: el trámite sigue siendo de este canal, ya no del bot. Si el pase
era el que tocaba, es escalado OK; si no debía ocurrir, o se hizo mal, es
escalado KO. Un fallo de sistema que obliga a una persona no es un
traspaso. Destinos: [escalados](/use-cases/atc/reference/capabilities/escalados).

Si otro especialista de Dani puede resolverlo, no hay ni traspaso ni
escalado: la conversación sigue, sin que el cliente lo oiga.

**E2E.** Dani cerró el trámite o la duda, o hizo el traspaso a la
plataforma correcta. No hace falta una persona de ATC para terminar. Al
colgar, un extracto elige uno de 35 motivos y escribe la etiqueta en Twin
(`atc_call_extractions`). El panel cuenta esas filas sobre el entorno
`production`.

Esa es la definición de diseño. El clasificador, hoy, trata «solo
informé» como no E2E, y confunde informar con resolver, y un escalado por
fallo con un traspaso. Hasta que negocio cierre el criterio, la cifra que
se enseña es la etiqueta escrita.

**Escalado OK.** Hacía falta una persona de ATC y el pase fue el
correcto. En un canal que aún no cubre todas las gestiones, que este
ratio sea alto no es un fallo: es el pase bien hecho.

**Escalado KO.** El bot no debía pasar, o pasó mal. La etiqueta de
resultado es una. El panel, en paralelo, marca como fallo tres tipos
de escalado (técnico, no entendimiento, usuario no autenticado). Todo KO
de clasificación está en ese segundo conjunto; al revés, no. La
diferencia son, sobre todo, clientes que no se autenticaron y acabaron
con una persona. Si eso es fallo del bot o un pase correcto lo decide
negocio.

**Abandono.** El cliente se fue sin cierre. El campo no dice en qué punto
de la llamada colgó.

**Gestión correcta.** E2E más escalado OK: resuelta por Dani (incluido un
traspaso) o bien pasada a ATC. No es un campo; la suma la hace el
panel. Se parece al 90 % de la auditoría en el número, pero no mide lo mismo, y
no es E2E: las dos escalas no se comparan entre sí.

| Métrica | Significado | Dónde se escribe |
|---|---|---|
| E2E | Cierra Dani o hace un traspaso a la plataforma correcta | `clasificacion = OK_E2E` |
| Escalado OK | Pase correcto a una persona de ATC | `clasificacion = OK_escalado` |
| Escalado KO | Pase que no debía ocurrir, o mal hecho | `clasificacion = KO_escalado` |
| Abandono | El cliente se fue sin cierre | `clasificacion = ABANDONO` |
| Gestión correcta | E2E + escalado OK | Suma en el panel |

No hay resultado por especialista, porque la tabla no tiene esa columna:
lo que se presenta «por especialista» es en realidad por el **motivo** de
la llamada (lecturas, pago, duplicado), y es una aproximación que debe
presentarse como tal. Hasta que el flujo escriba quién tenía el control
al colgar, no hay señal de producción por agente.

Tampoco hay tasa de autenticación: el campo vale «sí» o está vacío, y no
distingue un intento fallido de quien no llegó a intentarlo. Un conteo de
ejecuciones de la plataforma no es un conteo de llamadas: mezcla
producción, pruebas y evaluaciones. La cifra que se enseña a Naturgy sale
de Twin, entorno `production`.

## Auditoría

La auditoría es la nota humana: un auditor escucha la llamada y la marca
bien o mal,
con la taxonomía de Naturgy (resolución, motivo de KO, frustración). Esa
es la vara del 90 % y la única que abre el tráfico.

No mira el resultado escrito al colgar. No aplica indicadores principales. Una llamada E2E puede salir KO en auditoría,
y una bien escalada también.

La produce Teleperformance, en la aplicación de Naturgy. La
[Plataforma de auditoría](/account/reference/apps/audit-platform) existe para ver esa
nota aquí y ligarla a un cambio. Una importación de prueba en Twin no
cuenta.

## Indicadores principales

Son criterios de conducta sobre la transcripción de **un nodo**. Cuelgan de
un objetivo del agente (que el cliente quede con la lectura registrada,
no «gestionar lecturas») y cubren una clase de fallos, no un incidente.
Un juez automático los decide en el nodo que se evaluó.

No son la auditoría. No puntúan la llamada entera. No abren ni cierran
tráfico. Una llamada puede ser E2E, OK en auditoría, y haber fallado un
indicador principal de precio. Las tres cosas pueden ser verdad a la vez.

Tampoco son una prueba. La prueba es un escenario concreto, pasa o falla;
el indicador principal es la vara que esa prueba ejerce. Varias pruebas pueden
colgar del mismo criterio. El mapa de cobertura está en
[pruebas](/use-cases/atc/how-to/testing). Los textos viven en HappyRobot; el
[índice](/use-cases/atc/reference/generated) lista nombres y conteos.

Sobre tráfico real dejan una fila por criterio y llamada. Sirven para ver
dónde se rompe una regla antes de publicar, y después. Hoy no están
listos ni para eso como cifra: hay criterios vivos que penalizan el
comportamiento correcto (el más caro, no pedir la letra del DNI, cuando
la letra la dice el cliente) y casi ninguno tiene ejemplos. Eso contamina
el indicador principal. No dice nada de la auditoría.

## Fuentes

| Qué | Dónde |
|---|---|
| Resultado | Twin, `atc_call_extractions` · [panel ATC](/account/reference/apps/dashboard-atc) |
| Auditoría | Aplicación de Naturgy · [Plataforma de auditoría](/account/reference/apps/audit-platform) |
| Indicadores principales | HappyRobot · [índice](/use-cases/atc/reference/generated) |
| Prueba de un cambio | [Pruebas](/use-cases/atc/how-to/testing) · [Contrato de evidencia](/use-cases/atc/reference/evidence) |

## Decisiones pendientes

Las posee negocio. Hasta que las cierren, el canal se lee con lo escrito
arriba.

1. Cómo se elige el 4 % de la línea que entra en este canal.
2. Si el 90 % es paridad con el auditor humano.
3. Si un cliente que no se autentica y acaba con una persona es fallo del
   bot o un pase correcto: y, por tanto, cuál de las dos lecturas de KO
   se presenta.
4. Si «solo informé» cuenta como E2E o no.