Muchas empresas empiezan a usar IA en soporte por la parte vistosa: redactar respuestas más rápido. Tiene sentido, pero suele saltarse el atasco de verdad. Antes de contestar, alguien tiene que entender qué ha pasado, si falta información, a quién afecta y quién debe resolverlo.
En una empresa de Donostia - San Sebastián, Gipuzkoa o Euskadi, ese triaje suele vivir repartido entre correo, formularios, WhatsApp interno, llamadas, CRM, tickets y memoria de quien lleva años apagando fuegos. La IA puede ayudar ahí, pero no como piloto de "responde automáticamente a todo". Mejor empezar por algo más sobrio: leer la incidencia, ordenar los datos mínimos, proponer categoría y urgencia, y dejar una ficha clara para que una persona decida.
Este post propone un checklist práctico para diseñar ese primer piloto. Al final tienes un PDF descargable para bajarlo a una reunión con soporte, operaciones, administración o atención comercial.
El problema: tickets que nacen mal
Un ticket mal abierto no solo molesta. Retrasa el trabajo de todo el mundo.
A veces falta el número de pedido. A veces el cliente describe un síntoma, no el problema. A veces una incidencia urgente entra por un canal que nadie mira hasta la tarde. Otras veces se marca como urgente algo que puede esperar, mientras un caso serio queda mezclado con consultas normales.
La IA no elimina esas situaciones. Pero puede hacer una primera lectura ordenada y pedir lo que falta antes de que el equipo pierda media mañana reconstruyendo el contexto.
Qué debería hacer la IA en el primer piloto
Yo no empezaría permitiendo que cierre incidencias. Empezaría con cuatro tareas bastante controladas:
- resumir qué pide la persona;
- extraer datos mínimos como cliente, pedido, producto, fecha, canal y sistema afectado;
- proponer categoría, urgencia y responsable;
- señalar dudas o información pendiente.
Eso ya cambia mucho el trabajo diario. El equipo recibe una ficha revisable, no un hilo largo lleno de ruido. Y si la IA se equivoca, el error se corrige antes de tocar al cliente o al sistema interno.
Datos mínimos antes de clasificar
El triaje mejora cuando la IA sabe qué buscar. Conviene definir una ficha corta, no veinte campos obligatorios. Por ejemplo:
- quién reporta la incidencia;
- empresa, sede o departamento afectado;
- pedido, contrato, máquina, usuario o expediente relacionado;
- descripción breve del problema;
- impacto observable: parado, retrasado, duplicado, bloqueado, cobrado mal;
- canal de entrada y hora;
- documentación adjunta o capturas.
Si esos campos no existen, la IA debería decirlo. Parece básico, pero evita una mala costumbre: clasificar con seguridad una incidencia que todavía está incompleta.
Urgencia no es lo mismo que enfado
La IA puede confundir tono con prioridad si no se le dan reglas. Un mensaje escrito con enfado no siempre es urgente. Una frase seca puede esconder un problema crítico.
Mejor separar urgencia en criterios visibles: cliente bloqueado, impacto económico, parada de producción, plazo legal, error repetido, número de personas afectadas o riesgo de pérdida comercial. Después la IA puede proponer una prioridad, pero la regla tiene que venir de la empresa.
Para equipos pequeños, tres niveles suelen bastar al principio:
- alta: hay bloqueo, impacto económico o plazo crítico;
- media: afecta al trabajo, pero existe una alternativa temporal;
- baja: consulta, mejora o incidencia sin impacto inmediato.
No hace falta sofisticarlo más hasta tener datos reales.
Dónde entra la revisión humana
El punto de control debería estar antes de ejecutar acciones. La IA puede preparar una ficha, sugerir categoría, redactar una respuesta inicial o recomendar escalado. Pero alguien debe validar cuando la incidencia implica dinero, cliente sensible, cambios en ERP/CRM, datos personales, compromisos comerciales o una respuesta que pueda crear obligación.
Una regla simple ayuda: la IA propone, la persona confirma, el sistema registra. Si más adelante el piloto funciona bien, se pueden automatizar casos de bajo riesgo. Pero no conviene empezar por ahí.
Métricas que sí dicen algo
Medir solo "tickets procesados por IA" no sirve de mucho. Una mala clasificación también cuenta como procesada.
Mira métricas más útiles:
- porcentaje de incidencias con datos mínimos completos;
- tiempo hasta primera clasificación;
- porcentaje de casos reabiertos por mala categoría;
- escalados corregidos por una persona;
- tiempo hasta primera respuesta útil;
- satisfacción del equipo que recibe los tickets.
Con dos o tres semanas de datos ya se ve si el piloto ordena el trabajo o solo añade otra capa.
Descarga el checklist básico
El PDF incluye una plantilla corta para definir categorías, datos mínimos, reglas de urgencia, puntos de revisión humana y métricas. Sirve para preparar un piloto sin conectar la IA a más sistemas de los necesarios.
Descarga el how-to básico
PDF breve para pasar de correos, formularios o tickets sueltos a un triaje con IA: categorías, urgencia, datos mínimos, escalado humano y métricas de seguimiento.
Cuándo tiene sentido pedir ayuda
Si recibes pocas incidencias al mes, quizá baste con mejorar el formulario y las categorías. Si el volumen crece, hay varios canales de entrada o cada responsable clasifica de una forma distinta, un piloto de triaje con IA puede ahorrar bastante fricción.
La clave es empezar por una parte pequeña del flujo. Por ejemplo, soporte B2B, incidencias de facturación, solicitudes internas de IT o consultas postventa. Un mes de piloto bien medido vale más que una demo que promete atenderlo todo.