Convierte la cifra del 67 % de resolución de IA en un rango de planificación defendible
Antes de implementar un piloto, convierte las cifras de resolución del proveedor en un rango bajo/base/alto usando la mezcla de tickets, la calidad de la base de conocimientos y las pruebas de fallo.
Estás a punto de poner en marcha un agente de soporte con IA, y la cifra de Intercom que tienes delante es una tasa media de resolución del 67 % para Fin. Los proveedores de soporte al cliente con IA publican tasas de resolución entre el 67 % y el 86 %. Los propios casos de estudio de Fin de Intercom se agrupan entre el 42 % y el 50 %. Una prueba independiente de 500 tickets en una pyme arrojó un 38 %. Antes de firmar, convierte ese 67 % en un rango bajo/base/alto construido a partir de tu mezcla de tickets, la calidad de tu base de conocimientos y las pruebas de fallo.
La dispersión es el precio de entrada
No preguntes si la cifra destacada del proveedor es cierta. Pregunta qué significaría para tu cola de tickets. Los restablecimientos simples de contraseña pueden hacer plausible una tasa de resolución alta. Las escalaciones B2B multiplataforma hacen que la misma cifra sea optimista: las implementaciones de soporte con IA en B2B rinden entre 17 y 25 puntos porcentuales por debajo de las tasas de resolución de referencia del proveedor.
La hoja de cálculo parte de la cifra del proveedor y resta las brechas que puedes ver. Usa el extremo bajo para el presupuesto, el extremo base para la dotación de personal y el extremo alto para el margen de mejora que no vas a prometer. El rango es lo que puedes defender en una revisión presupuestaria; la cifra de la demo, no.
Tu mezcla de tickets define el rango
- Etiqueta los tickets recientes por tema, complejidad y si un humano ya los resolvió. Detente cuando tengas una tabla simple con recuentos, no un relato.
- Divide los tickets en categorías seguras para IA y arriesgadas para IA. Seguro para IA significa que la respuesta está documentada, tiene bajo riesgo y es repetible. Arriesgado para IA significa que el cliente necesita criterio, contexto de la cuenta o una decisión de reembolso. Estás listo cuando las columnas emparejadas pueden resistir a un manager escéptico.
- Evalúa la calidad de la base de conocimientos en cobertura, vigencia y claridad. La cobertura pregunta si la respuesta existe. La vigencia comprueba si coincide con el comportamiento actual del producto. La claridad prueba si un modelo puede seguirla sin adivinar. El resultado es una nota breve que nombra las brechas, no una tabla de puntuación sin responsable.
- Fija el rango bajo/base/alto. Bajo asume que la IA solo gestiona los tickets documentados más sencillos. Base añade una proporción moderada de preguntas adyacentes al conjunto documentado. Alto pone a prueba si la cifra del proveedor resiste tu mezcla y la calidad de tu base de conocimientos. Termina con un rango vinculado a grupos de tickets nombrados.
- Aplica una prueba de fallo antes de firmar. Pide al proveedor que procese una muestra de tus tickets reales. El resultado es una lista escrita de respuestas incorrectas, acciones inseguras y fallos de escalación.
El error más común es tratar una demo del proveedor como producción. Una demo puede estar curada; tu cola, no. Incluso un despliegue puede cambiar de rumbo; Klarna volvió a contratar personal de soporte humano en 2025 tras haber afirmado antes que su IA realizaba el trabajo de 700 agentes.
Las pruebas de fallo deciden si el rango sobrevive
Una prueba piloto debe usar tus tickets, no el conjunto de demo del proveedor. Extrae una muestra reciente que incluya los casos incómodos: disputas de facturación, reembolsos parciales, datos faltantes y clientes que ya están molestos. Un proveedor que se niega a probar con tus datos es un dato de planificación, no una mera molestia.
No tomes confianza prestada de una muestra pública. AI Gear Base había publicado 1.342 reseñas tras tres años de funcionamiento, y ese número de reseñas no sustituye tu propia prueba de tickets.
Durante la prueba, busca tres modos de fallo: respuestas fluidas que no aciertan el problema, acciones no autorizadas como prometer un reembolso o cambiar un plan, y tickets que necesitan intervención humana que se quedan en el bucle de IA el tiempo suficiente como para generar otra queja.
Escribe la lista de fallos antes del contrato: tipos de tickets donde la IA debe detenerse, acciones que no puede realizar y el disparador de traspaso. El estado final es una hoja breve de salvaguardas que tanto el proveedor como tu equipo de soporte pueden firmar.
Si la cifra del proveedor se sitúa por encima de tu extremo alto, llámalo una discrepancia, no un problema. Vincula el rango al coste antes de escalar. Un caso base que solo ahorra una pequeña fracción del tiempo humano debería reducir el piloto, no ampliarlo. Una vez que el caso base supera tu umbral de coste, documenta las suposiciones y revísalo tras el piloto.
