El QA del recorrido del cliente revisa todo lo que vivió un cliente para resolver un problema: cada bot, agente de IA, chat, llamada y contacto humano sobre ese problema dentro de un plazo fijo. En lugar de preguntar si cada conversación fue buena, pregunta si el recorrido terminó con el problema resuelto, sin bucles, sin contexto perdido y sin peticiones de hablar con una persona ignoradas.
En resumen
- El QA de conversaciones evalúa un contacto. El QA del recorrido evalúa todo el camino que siguió un cliente para resolver un problema, entre bots, agentes de IA, canales y personas.
- La mayoría de los fallos de la era de la IA están entre conversaciones: un “quiero hablar con una persona” ignorado, un bucle entre chat y teléfono, contexto perdido, un recontacto, un cliente que abandona en silencio.
- Defina un recorrido como el mismo cliente con el mismo problema dentro de un plazo fijo, 7 días por defecto.
- Mida los recorridos resueltos correctamente, los contactos por recorrido, los traspasos fallidos, el contexto perdido, las peticiones de una persona atendidas, el abandono silencioso y el tiempo hasta la resolución.
- Revise recorridos completos con una scorecard de recorrido, elija la muestra según señales de riesgo y dé a cada recorrido fallido un responsable que corrija la causa.
¿Qué es el QA del recorrido del cliente?
El QA del recorrido del cliente es un control de calidad en el que la unidad de revisión es el problema del cliente, no la conversación aislada. Un revisor, o una comprobación automática, sigue a un cliente y un problema por cada punto de contacto (bot, agente de IA, chat, email, teléfono, agente humano) dentro de un plazo fijo y juzga si el recorrido resolvió el problema correctamente y sin esfuerzo innecesario.
El QA tradicional lee un ticket y evalúa al agente que lo gestionó. Con agentes de IA en primera línea, un problema se convierte a menudo en tres o cuatro contactos: una conversación con el bot, un escalamiento al chat, una llamada, un email de seguimiento. Cada contacto puede aprobar su propia scorecard mientras el cliente pasa tres días sin avanzar.
“Agentes de IA para el customer journey” suele referirse a herramientas de marketing, como el Journey Creation Agent de Microsoft (en inglés), que construye recorridos de email, SMS y notificaciones push a partir de un objetivo escrito en lenguaje natural. Esta guía trata de soporte: comprobar los recorridos que los clientes siguen de verdad cuando necesitan ayuda.
¿Por qué evaluar conversaciones sueltas no detecta dónde falla el soporte en la era de la IA?
Evaluar conversaciones sueltas no detecta los fallos de la era de la IA porque esos fallos ocurren entre conversaciones. Un bot que ignora “quiero hablar con una persona”, un chat que manda al cliente al teléfono, un traspaso que pierde el número de pedido o un cliente que se rinde en silencio dejan cada conversación con un aspecto aceptable. Solo el recorrido completo muestra el daño.
Los clientes lo esperan. En una encuesta de Gartner a 5.728 clientes (diciembre de 2023), el 64% dijo que preferiría que las empresas no usaran IA en la atención al cliente (en inglés), y su principal preocupación era que fuera más difícil llegar a una persona. Gartner aconseja que un chatbot que no puede resolver el problema traspase a un chat con un agente que “retome donde lo dejó el chatbot”. Es un requisito del recorrido.
El informe sobre chatbots en las finanzas de consumo (en inglés) de la Consumer Financial Protection Bureau de Estados Unidos llama a este mismo patrón “doom loops” (bucles sin salida), a menudo causados cuando un problema queda fuera de las capacidades limitadas del chatbot.
Cinco patrones de fallo causan la mayor parte del daño:
| Patrón de fallo | Qué vive el cliente | Por qué la nota de la conversación no lo ve | Señal del recorrido que conviene vigilar |
|---|---|---|---|
| “Quiero hablar con una persona” ignorado | Pide una persona y recibe más respuestas del bot, o un callejón sin salida | El bot fue educado y no se salió del tema, así que su conversación aprueba | Petición explícita de una persona sin ningún contacto humano en el recorrido |
| Bucle entre canales | El chat dice que llame, el teléfono dice que use el chat, nadie lo resuelve | Cada contacto derivó “correctamente” al cliente a otro sitio | Mismo problema, 2 o más cambios de canal, sin resolución |
| Contexto perdido en un traspaso | Repite el número de pedido, el problema, los pasos ya probados | El agente humano fue amable e hizo las preguntas correctas | El cliente da el mismo dato dos veces en un recorrido |
| Recontacto | El problema estaba “resuelto” y vuelve días después | La primera conversación terminó con una respuesta segura | Nuevo contacto sobre el mismo problema dentro del plazo |
| Abandono silencioso | Se rinde a mitad del recorrido, quizá cancela o se da de baja | Sin queja, sin encuesta, el ticket se cierra como resuelto | El recorrido termina sin resolución y sin más contactos |
En los foros públicos de soporte, los clientes describen el bucle entre canales en una frase: el chat los manda al teléfono y el teléfono los devuelve al chat o cuelga. Ni la transcripción del chat ni la llamada, evaluadas por separado, suspenderían. Para los fallos dentro de una sola conversación con IA que los dashboards cuentan como éxitos, consulte nuestra guía sobre fallos silenciosos de los agentes de IA.
¿Cómo se define un recorrido del cliente para el QA?
Defina un recorrido del cliente como todos los contactos del mismo cliente sobre el mismo problema dentro de un plazo fijo, por ejemplo 7 días desde el primer contacto. Necesita tres reglas por escrito antes de revisar nada: cómo reconoce al mismo cliente, cómo reconoce el mismo problema y cuándo se considera terminado un recorrido.
El mismo cliente. Use el identificador más fiable que tenga: el ID de cliente o el número de cuenta, después el email verificado y después el número de teléfono. Cuente los chats anónimos por separado en lugar de adivinar.
El mismo problema. Haga la correspondencia por la etiqueta de intención, el número de pedido o de caso, o un ticket vinculado. Si las etiquetas no son fiables, pida antes a un revisor que confirme las correspondencias en una muestra.
El plazo. Elíjalo por tipo de problema y después manténgalo fijo:
| Tipo de problema | Plazo sugerido | Por qué |
|---|---|---|
| Preguntas sencillas de uso o de cuenta | 3 días | Si vuelve más tarde, suele ser una pregunta nueva |
| Pedidos, entregas, devoluciones | 7 días | Cubre la espera de una entrega o de un reembolso |
| Facturación, reembolsos, disputas | 14 días | Una respuesta errónea aparece en el siguiente extracto o pago |
| Reclamaciones, bajas, casos regulados | 30 días | Procesos largos con varios pasos obligatorios |
Estos plazos son nuestras reglas de partida, no un estándar del sector. Represente los días entre el primer y el segundo contacto sobre el mismo problema y fije el plazo donde ya han llegado la mayoría de los seguimientos reales.
Cómo termina un recorrido. Resuelto (el problema real se resolvió y no hubo nada más dentro del plazo), abandonado (el cliente se detuvo sin resolución) o abierto (revíselo más tarde). La resolución en el primer contacto (en inglés) usa el mismo plazo de recontacto, pero solo pregunta por el primer contacto; el QA del recorrido juzga todo el camino.
¿Qué métricas del recorrido conviene medir?
Mida siete métricas del recorrido: la proporción de recorridos resueltos correctamente, los contactos por recorrido, la tasa de traspasos fallidos, la tasa de contexto perdido, las peticiones de una persona atendidas, la tasa de abandono silencioso y el tiempo de resolución del recorrido. Juntas muestran si los clientes quedan resueltos, cuánto esfuerzo les cuesta y qué punto de unión se rompe más. Infórmelas por tipo de problema y por canal de entrada.
| Métrica | Cómo calcularla | Regla de partida (nuestra, ajústela a su línea base) |
|---|---|---|
| Recorridos resueltos correctamente | Recorridos en los que el problema real se resolvió correctamente / recorridos cerrados | Investigue cualquier tipo de problema por debajo del 85% |
| Contactos por recorrido | Todos los contactos, en todos los canales / recorridos | Investigue cualquier tipo de problema por encima de 1,5 |
| Tasa de traspasos fallidos | Traspasos que perdieron el contexto, llegaron tarde o devolvieron al cliente al punto de partida / traspasos revisados | Objetivo: menos del 5% |
| Tasa de contexto perdido | Recorridos con varios contactos en los que el cliente repitió un dato / recorridos con varios contactos | Investigue por encima del 5% |
| Peticiones de una persona atendidas | Peticiones explícitas de una persona seguidas de un contacto humano / todas esas peticiones | Objetivo: 95% o más |
| Tasa de abandono silencioso | Recorridos terminados sin resolver y sin queja / recorridos cerrados | Revise una muestra cada semana, sea cual sea la tasa |
| Tiempo de resolución del recorrido | Del primer contacto a la resolución, mediana y percentil 90 | Vigile el percentil 90 |
Una tasa de contención (en inglés) alta puede esconder un mal recorrido: un cliente que deja el bot y llama al teléfono sigue contando como contenido. Los contactos por recorrido lo detectan. Y separe “resuelto” de “resuelto correctamente”: una respuesta errónea dada con seguridad parece resuelta hasta que llega el recontacto. Nuestra auditoría de la tasa de resolución de los agentes de IA explica cómo comprobarlo.
La scorecard del recorrido (cópiela)
La scorecard del recorrido es un conjunto breve de criterios que solo tienen sentido a lo largo de un recorrido completo. Cada criterio tiene una condición de suspenso clara e indica los datos que necesita el revisor. Evalúe cada conversación con su scorecard habitual, como siempre, y evalúe el recorrido con estos criterios además, de modo que una nunca sustituya a la otra.
| # | Criterio del recorrido | Qué cuenta como suspenso | Datos necesarios |
|---|---|---|---|
| 1 | El problema real quedó resuelto correctamente al final | Problema sin resolver, mal resuelto o “resuelto” y de vuelta dentro del plazo | Todos los contactos del plazo, el resultado final, la política o el artículo de conocimiento aplicable |
| 2 | Se atendieron las peticiones de una persona (crítico) | El cliente pidió una persona y no la obtuvo, o solo la obtuvo tras pedirla 2 o más veces | Transcripciones del bot y del agente de IA, registro de escalamientos |
| 3 | Sin bucles entre bots, canales o equipos (crítico) | El cliente fue devuelto a un canal o agente que ya había probado para el mismo problema | Canal y gestor de cada contacto, registro de enrutamiento |
| 4 | El contexto pasó en cada traspaso | El cliente repitió un identificador, el problema o los pasos ya probados | Transcripciones a ambos lados de cada traspaso, resumen del traspaso si existe |
| 5 | El escalamiento ocurrió con el disparador correcto | Escaló demasiado tarde (tras varias respuestas fallidas) o pasó a una persona sin indicar el motivo | Reglas de escalamiento, transcripción en el momento del traspaso |
| 6 | Respuestas coherentes entre canales y gestores | Dos contactos dieron al cliente respuestas distintas sobre la misma política | Todas las respuestas dadas, la política aplicable |
| 7 | Se cumplieron las promesas | Una llamada de vuelta, un reembolso o un seguimiento prometido en un contacto no ocurrió | Promesas en las transcripciones, sistema de pedidos o de casos |
| 8 | El esfuerzo fue proporcionado | Más contactos o días de los que requiere el tipo de problema (por encima de su regla de contactos por recorrido o de tiempo) | Número de contactos, marcas de tiempo |
| 9 | El final fue explícito | El recorrido terminó en silencio con el problema sin resolver (abandono silencioso) | Último contacto, resultado, cualquier baja o cancelación |
Regla de evaluación. Un recorrido suspende si falla el criterio 1, 2 o 3 (los críticos). Si no, cuente los demás suspensos: 0 es un aprobado, 1 es un aprobado con una observación, 2 o más es un suspenso. Registre un solo segmento de causa raíz por cada suspenso: el bot, un agente de IA concreto, la regla de enrutamiento o de traspaso, un canal, un agente humano, o el contenido de políticas o de conocimiento. Esa atribución es lo que convierte la nota de un recorrido en una corrección.
El criterio 4 es la misma comprobación de continuidad que nuestra guía para evaluar la derivación entre la IA y el agente humano trata en detalle, un punto de unión cada vez. Para los recorridos en los que varios agentes de IA se pasan un caso, nuestra guía de orquestación de agentes de IA explica los patrones de enrutamiento que hay detrás de los criterios 3 y 5.
¿Cómo se elige la muestra y se revisan recorridos completos?
Elija la muestra de recorridos en dos capas: revise cada recorrido que active una señal de riesgo (una petición de una persona ignorada, 3 o más contactos, 2 o más canales, un bucle o un abandono) y añada una muestra aleatoria de recorridos normales para medir la tasa de fallo real. Revise cada recorrido en orden cronológico, en una sola línea de tiempo, con todos los contactos uno junto a otro.
Capa 1: recorridos activados por riesgo. Aquí se concentran los fallos, así que léalos todos, o un número fijo por disparador y semana:
- Una petición explícita de una persona (“agente”, “humano”, “persona”, “representante”) en una transcripción del bot o del agente de IA.
- 3 o más contactos, o 2 o más cambios de canal, sobre el mismo problema.
- Un recontacto después de un contacto marcado como resuelto.
- Un recorrido que termina sin resolver y sin más contactos.
Capa 2: una muestra aleatoria. Los disparadores indican dónde mirar, no con qué frecuencia fallan las cosas. Para informar de una tasa de fallo que pueda defender, añada una muestra aleatoria de recorridos cerrados; entre 150 y 400 al mes dan un margen de error útil para un tipo de problema. Nuestro artículo sobre estadística del muestreo de QA (en inglés) explica por qué las muestras más pequeñas engañan.
Cómo revisar un recorrido. Reconstruya la línea de tiempo: cada contacto por fecha, con su canal y su gestor (bot, agente de IA, persona, menú telefónico). Lea el primer y el último contacto antes que los intermedios; la distancia entre lo que pidió el cliente y lo que obtuvo al final es el veredicto. Después recorra cada punto de unión. Las llamadas necesitan una transcripción o un resumen para entrar en la misma línea de tiempo; muchos contact centers ya evalúan una muestra de llamadas, y la revisión del recorrido las sitúa junto a los contactos de chat y de bot.
La plantilla de revisión del recorrido
Cópiela en una hoja de cálculo o en un formulario de revisión. Un bloque por recorrido.
| Campo | Qué rellenar |
|---|---|
| ID del recorrido | Su propio ID, o el número del primer ticket |
| Cliente y problema | Identificador del cliente, tipo de problema, número de pedido o de caso |
| Plazo | Fecha del primer contacto, duración del plazo, estado final (resuelto, abandonado, abierto) |
| Línea de tiempo | Una fila por contacto: fecha y hora, canal, gestionado por (bot, agente de IA concreto, persona, menú telefónico), qué pasó en una línea, contexto recibido (sí o no), resultado |
| Disparadores de riesgo | Qué disparadores de la capa 1 se activaron, si los hay |
| Scorecard del recorrido | Aprobado o suspenso en los criterios 1 a 9, con el número de contacto como evidencia |
| Veredicto | Aprobado, aprobado con observación, suspenso |
| Segmento de causa raíz | Bot, agente de IA (nombre), regla de enrutamiento o de traspaso, canal, agente humano, políticas o conocimiento |
| Responsable y corrección | Quién es responsable de ese segmento, la corrección acordada, la fecha en que se aplica |
| Nueva comprobación | La fecha en que volverá a revisar el mismo tipo de recorrido |
Un ejemplo práctico (ilustración, cifras inventadas para mostrar el cálculo)
Un equipo de soporte gestiona 50.000 contactos al mes entre un chatbot, un agente de IA en chat y email, una línea telefónica y agentes humanos. Agrupados en recorridos con un plazo de 7 días, esos contactos forman 38.000 recorridos:
- 31.800 recorridos (84%) tienen un solo contacto.
- 6.200 recorridos tienen dos o más, con 18.200 contactos entre todos (2,94 de media).
- Contactos por recorrido en total: 50.000 / 38.000 = 1,32.
El QA de conversaciones parece sano: el 91% de las conversaciones de la muestra aprueba. Entonces la responsable de QA revisa una muestra aleatoria de 150 recorridos con varios contactos. Suspenden 48 (32%):
| Causa raíz | Recorridos suspendidos | Proporción de suspensos |
|---|---|---|
| Contexto perdido en el traspaso del bot a la persona | 17 | 35% |
| Petición de una persona ignorada o retrasada | 12 | 25% |
| Bucle entre chat y teléfono | 9 | 19% |
| Resolución errónea, el cliente volvió | 6 | 13% |
| Respuestas distintas sobre la política en el chat y por teléfono | 4 | 8% |
| Total | 48 | 100% |
Dentro de esos 48 recorridos suspendidos hay 141 conversaciones, y 118 de ellas (84%) aprobaron la scorecard de conversaciones. Los recorridos suspendieron mientras la mayoría de sus conversaciones aprobaban.
A escala, el 32% de 6.200 son unos 1.980 recorridos suspendidos al mes. El margen de error al 95% es de unos ±7,5 puntos (1,96 × √(0,32 × 0,68 / 150) = 0,075), así que el número real está entre unos 1.520 y 2.450. Cualquiera de los dos extremos merece una corrección. Y 29 de los 48 suspensos (60%) vienen de dos puntos de unión, el contenido del traspaso y la regla de petición de una persona, así que ahí van las primeras correcciones.
Véalo con sus propias conversaciones. Kaizo evalúa el 100% de sus conversaciones de soporte, humanas y de agentes de IA, con su propia scorecard, y enlaza cada nota con la evidencia en la conversación. Reserve una demo.
¿Quién debe ser responsable de la calidad del recorrido del cliente?
Una sola persona debe ser responsable de la calidad del recorrido de principio a fin, normalmente el Head of Support o el responsable de Support Operations, porque ningún responsable de canal o de agente ve el camino completo. Esa persona gestiona las métricas del recorrido y la revisión semanal. Después, cada recorrido suspendido va al responsable del segmento que lo causó.
| Rol | Responsable de | Actúa sobre |
|---|---|---|
| Responsable del recorrido (Head of Support o Support Ops) | Las métricas del recorrido, la scorecard del recorrido, la revisión semanal | Prioridades entre equipos; escala cuando una corrección se estanca |
| Responsable del agente de IA (por bot o agente de IA) | Las instrucciones, el conocimiento y los disparadores de escalamiento del agente | Suspensos atribuidos a ese agente: respuestas erróneas, peticiones de una persona ignoradas |
| Responsable del enrutamiento y de los traspasos | Reglas de enrutamiento, contenido del traspaso, transferencia entre canales | Bucles, contexto perdido, escalamiento tardío |
| Responsables de canal (chat, email, teléfono) | El proceso y la plantilla de cada canal | Bucles entre canales, llamadas de vuelta fallidas, respuestas incoherentes |
| Responsable de QA | Muestreo, calibración de revisores, la plantilla de revisión | Notas del recorrido fiables; nuevos patrones de fallo |
| Responsable de conocimiento y políticas | El contenido a partir del cual responden las personas y los agentes de IA | Respuestas incoherentes entre canales |
Dos reglas evitan que esto se convierta en una reunión para buscar culpables. Cada recorrido suspendido recibe exactamente un segmento de causa raíz; registre el resto como observaciones secundarias. Y la corrección depende de quién falló: una persona recibe coaching, un agente de IA recibe un cambio en sus instrucciones, su conocimiento o sus disparadores. Consulte coaching de personas frente a corregir agentes de IA.
¿Cómo se corrigen los fallos que encuentra el QA del recorrido?
Corrija los fallos del recorrido en el punto de unión que los causó, no en la conversación donde salieron a la luz. La mayoría de las correcciones son cambios de reglas: un disparador de escalamiento, el contenido de un traspaso, una política que indique cuándo se atiende siempre una petición de una persona, o una sola respuesta para una política en todos los canales. Después vuelva a revisar el mismo tipo de recorrido para confirmar que la corrección se mantiene.
| Fallo encontrado | Corrección habitual | Para saber más |
|---|---|---|
| “Quiero hablar con una persona” ignorado | Una regla fija: una petición explícita, o una segunda respuesta fallida, traspasa con un resumen | Guardrails para agentes de IA |
| Bucle entre canales | Elimine las respuestas “llámenos” o “use el chat” para problemas que el otro canal tampoco puede resolver; ofrezca una llamada de vuelta o un ticket | Por qué fallan las conversaciones con IA |
| Contexto perdido en el traspaso | Un contenido de traspaso fijo: ID de cliente, problema, pasos probados, lo que quiere el cliente | Evaluar la derivación a agente humano |
| Respuestas incoherentes | Una sola fuente de políticas, versionada, de la que responden tanto las personas como los agentes de IA | Gestión de políticas para agentes de IA |
| Resolución errónea, recontacto | Limite lo que el agente de IA puede resolver solo; audite sus resoluciones | Niveles de autonomía de los agentes de IA |
| Abandono silencioso | Revise cada semana los recorridos abandonados; añada un seguimiento para los problemas de alto riesgo sin resolver | Monitorización de agentes de IA |
Pruebe cada cambio antes de que llegue a los clientes y después mídalo en producción. Nuestra guía de evaluación de agentes de IA cubre ambas cosas: conjuntos de pruebas antes del lanzamiento y evaluación de las conversaciones reales después.
¿Cuándo no le conviene el QA del recorrido?
El QA del recorrido no compensa el esfuerzo de ponerlo en marcha cuando la mayoría de los problemas se resuelven en un contacto y no tiene ningún bot ni agente de IA en primera línea. Si los contactos por recorrido rondan 1,1, los clientes rara vez cambian de canal y gestiona unos cientos de contactos a la semana, el QA de conversaciones más una simple cifra de resolución en el primer contacto ya le muestra lo que necesita.
Es prematuro cuando no puede vincular los contactos a un cliente: si la mayoría de los chats son anónimos y las llamadas no llevan ningún identificador de cliente, corrija eso primero. Mientras tanto, lea cada transcripción con una petición explícita de una persona, que no requiere ninguna vinculación. Y el QA del recorrido nunca sustituye al QA de conversaciones: uno muestra dónde se rompió el camino, el otro qué salió mal dentro de un contacto.
Cómo empezar esta semana
Puede empezar el QA del recorrido esta semana con una hoja de cálculo y un tipo de problema. El objetivo de la primera semana no es un dashboard. Es encontrar el punto de unión que rompe más recorridos, para que la primera corrección compense el esfuerzo.
- Elija un tipo de problema de gran volumen en el que un bot o un agente de IA atienda el primer contacto, como el estado del pedido o los reembolsos.
- Escriba las tres reglas: qué identificador, qué etiqueta de problema o número de caso, qué plazo.
- Extraiga 30 recorridos: 20 que activen un disparador de riesgo y 10 al azar.
- Revíselos con la scorecard y la plantilla del recorrido, con un segmento de causa raíz por suspenso.
- Nombre al responsable del peor punto de unión y acuerde una corrección con fecha.
- Repita la semana siguiente con el mismo tipo de problema para ver si la corrección se mantuvo.
Cuando la revisión manual confirme el patrón, automatice lo que escala. El QA para agentes de IA de Kaizo evalúa las conversaciones de agentes de IA y de personas con la misma scorecard, incluido si el agente escaló con el disparador correcto y transmitió el contexto, y AutoPilot evalúa cada conversación en cuanto se resuelve en Zendesk o Salesforce. Agrupar esas conversaciones en recorridos depende de los datos de su helpdesk: tickets vinculados, IDs de cliente y etiquetas de problema. Para la visión de conjunto, consulte nuestra guía sobre atención al cliente agéntica.
Preguntas frecuentes
¿Cuál es un buen número de contactos por recorrido?
No hay una referencia universal, porque depende del tipo de problema. Use su propia línea base por tipo de problema e investigue todo lo que suba. Como regla de partida, las preguntas sencillas deberían estar cerca de 1,0, y cualquier cifra por encima de 1,5 merece revisar los recorridos que hay detrás.
¿El QA del recorrido del cliente es lo mismo que el mapa del customer journey?
No. El mapa del customer journey diseña el camino que quiere que sigan los clientes, a menudo para marketing o diseño de servicios. El QA del recorrido comprueba los caminos que los clientes siguieron de verdad, contacto a contacto, y juzga si cada uno resolvió el problema sin bucles, sin contexto perdido y sin peticiones de una persona ignoradas.
¿Se pueden revisar juntos los recorridos de voz y de chat?
Sí, si cada llamada tiene una transcripción o un resumen escrito en el mismo lugar que sus contactos de chat y email. La revisión del recorrido sitúa entonces la llamada en la misma línea de tiempo que los contactos del bot y del chat y aplica los mismos criterios del recorrido. Sin transcripción ni resumen, el revisor solo puede juzgar la llamada por su resultado.
¿El QA del recorrido es lo mismo que la monitorización de agentes de IA?
No. La monitorización vigila señales en vivo de un agente de IA, como la tasa de escalamiento, los errores y la deriva, y avisa cuando cambian. El QA del recorrido revisa recorridos terminados entre todos los bots, agentes, canales y personas, y juzga si se resolvió el problema del cliente. La monitorización le dice que algo cambió; el QA del recorrido le dice lo que le costó al cliente.
¿Cómo se detecta el abandono silencioso?
Busque recorridos que terminaron sin resolver y sin más contactos: una conversación con el bot que se detuvo a mitad del flujo, un escalamiento al que el cliente nunca respondió, una llamada de vuelta que nunca llegó a conectar. Algunos de esos clientes lo resolvieron por otra vía; otros cancelaron. Revise una muestra semanal y, cuando pueda, compruebe las cancelaciones o bajas de las semanas siguientes.
