Cómo auditar la tasa de resolución que te vende tu proveedor de IA

La escena se repite en casi todas las empresas que contratan IA para soporte: se firma confiando en el número de la demo, y seis meses después, en la reunión de renovación, nadie del equipo puede decir si ese número sigue siendo real. El primer mes se mide con entusiasmo, alguien arma un slide, y después el dashboard del proveedor pasa a ser la única fuente, sin que nadie lo vuelva a contrastar con lo que en verdad pasó con esos tickets.

Qué preguntar antes de firmar ya lo cubrimos en qué preguntar en la demo de un agente de IA. Lo que sigue es la otra mitad: cómo verificarlo tú mismo con tus propios datos, cuando el contrato ya está firmado y el bot ya está trabajando.

El dashboard del proveedor no es una fuente independiente

El dashboard mide lo que al proveedor le conviene mostrar, y en varios casos el mismo proveedor cobra por resolución y define qué cuenta como resuelta. No hace falta que haya mala fe para que el número salga inflado: si el bot cuenta como éxito cualquier conversación que se cierra sin transferencia a un humano, un cliente que se cansó de insistir y se fue a reclamar por otro lado también entra en la columna de “resuelto”. La única forma de saber qué pasó es mirar las conversaciones, no el resumen que el proveedor construyó sobre ellas.

El método de las 100 conversaciones

No necesitas una herramienta de analytics para esto. Necesitas una tarde y una muestra.

Primero, pide (o exporta) una muestra tomada al azar de conversaciones que el sistema marcó como resueltas por IA en el último mes. Al azar es la palabra que importa: si eliges tú cuáles revisar, vas a mirar las que ya recuerdas como buenas. Con 100 conversaciones alcanza para un equipo chico; con 300, el número ya es representativo para casi cualquier volumen.

Segundo, lee cada una entera, no el resumen automático que el bot generó de sí mismo. Y clasifícalas en tres categorías, no en dos:

• Resuelto de verdad: el cliente obtuvo lo que pidió y no volvió a escribir por lo mismo.
• Abandono disfrazado de éxito: el cliente dejó de responder sin confirmar que el problema se resolvió.
• Fuga a otro canal: la conversación se cerró aquí, pero el mismo cliente reclamó lo mismo por WhatsApp, email o una llamada.

La segunda y la tercera categoría son las que el dashboard del proveedor cuenta como resolución y que, miradas de cerca, no lo son.

La ventana de reapertura no es opcional

Un ticket que hoy figura como cerrado y que el mismo cliente reabre a los cuatro días no se resolvió, se pospuso. Define una ventana (7 días para consultas simples, 14 para las que involucran plata o un proceso de varios pasos) y cuenta como reapertura cualquier caso donde el mismo cliente vuelva a escribir por el mismo motivo dentro de ese plazo. Si tu herramienta no te deja filtrar por “mismo cliente, mismo motivo, dentro de X días” de forma automática, hazlo a mano sobre la muestra de 100: es tedioso, pero es la parte que más cambia el número final.

Cruzar los canales antes de contar

Si el chat de IA vive en una herramienta y el email o WhatsApp en otra, un mismo cliente insatisfecho puede generar dos casos que nadie relaciona entre sí: uno que el bot cerró como éxito, y otro que abrió tu equipo humano tres días después sin saber que ya había pasado por la IA. Antes de auditar cualquier número, confirma que estás mirando todos los canales del mismo cliente juntos y no una porción. Es el mismo problema que aparece cuando la atención multicanal crece sin una bandeja común, solo que aquí contamina directamente la medición del proyecto de IA.

Qué pedirle al proveedor para poder auditar

En la negociación, la mayoría pide referencias y casos de éxito. Lo que te va a servir después es otra cosa:

• Acceso para exportar conversaciones crudas, no solo el resumen del panel.
• Un filtro por fecha y por si hubo reapertura, no un número único ya promediado.
• Una respuesta clara sobre si el número que muestran ya descuenta las reaperturas o no.

Un proveedor que no puede darte esos tres puntos antes de firmar es un proveedor que tampoco va a poder dártelos después, cuando el número empiece a importar porque toca decidir si renuevas.

Por qué esto es más fácil cuando el bot y los tickets viven en el mismo lugar

Si usas MelonHelp, la auditoría de arriba se hace con dos filtros en la bandeja. El primero es el estado Escalated: cada conversación que MIA no pudo cerrar queda marcada así, con la transcripción completa adjunta al ticket, de modo que la columna de abandonos se llena leyendo, no reconstruyendo. El segundo es el contacto: si Camila vuelve a escribir a los cuatro días por el mismo cobro duplicado, su mensaje cae en el ticket que ya existía, y la reapertura aparece en el historial en lugar de inflar la cuenta de resueltos. Con eso, la muestra de 100 se arma en una tarde y sin planilla. Cómo se asigna y prioriza ese ticket una vez que llega lo explicamos en cómo priorizar tickets de soporte.

Preguntas frecuentes