Escalar soporte sin contratar
En WPML gestionábamos unos 5.000 reportes de soporte al mes. Debo decir de entrada que nada estaba roto cuando esto empezó - ni crisis de backlog, ni plataforma en llamas. Era mi propia convicción de que podíamos hacerlo considerablemente mejor, lo que hacía el caso más difícil de defender que un rescate.
Ocurrió en dos actos, y el orden es toda la historia.
Primer acto: el trabajo poco glamuroso
Antes de cualquier IA, construimos autoservicio, recogida automática de datos de depuración en el momento del reporte, y diagnósticos predefinidos para los casos recurrentes. En su momento aquello era simple higiene operativa. En retrospectiva, es lo que hizo posible todo lo demás: para cuando introdujimos un agente de IA, nuestros problemas comunes ya estaban documentados, los reportes ya llegaban con datos estructurados, y los casos recurrentes ya tenían caminos de resolución definidos.
La mayoría de los proyectos de IA en soporte fallan ahí, en mi opinión - no en el modelo, en el desorden. Los apuntan a una cola sin documentar y les piden magia.
Segundo acto: el agente
Dirigí la construcción y el despliegue de un agente de soporte con IA orquestado, por etapas: del 10% de las conversaciones entrantes al 100% en unos seis meses. Cuatro decisiones importaron más que cualquier prompt:
- Primero, un agente de triaje. Cada reporte se clasificaba como "listo para IA" o "necesita humano" antes de que nada más lo tocara. Los de humano iban directos a una persona - con los datos de depuración ya recogidos, para poder empezar a trabajar en lugar de empezar una conversación. Alrededor del 60% salía como listo para IA.
- Un agente de escalado. En torno al 30% de los casos "listos para IA" acababa igualmente con un humano - pero llegando con el historial completo de lo ya intentado. Un escalado que reinicia la conversación desde cero es un fallo por partida doble.
- Un control manual. Aparece un bug nuevo un martes, el agente no lo conoce, y va a seguir equivocándose con total seguridad en sí mismo. Construimos una vía para inyectar cambios repentinos directamente, el mismo día.
- Un ciclo de evaluación permanente. Cada semana, uno de mis supporters más veteranos y yo leíamos lo que el agente había dicho de verdad a los clientes y devolvíamos dónde fallaba. Ese ciclo nunca se quitó. Es el trabajo entero.
Qué cambió
Alrededor del 30% de la carga total - los problemas conocidos y los cómo-se-hace documentados - quedó absorbido por completo. El tiempo medio de resolución pasó de unas 24 horas a unas 10 a las pocas semanas del despliegue completo.
El equipo se hizo más pequeño, no más grande. La parte más interesante es que cambió de forma. Una vez desaparecidos los tickets rápidos, lo que quedaba para las personas era lo ambiguo y lo genuinamente difícil - así que la velocidad dejó de ser una medida justa de un supporter. Algunas de las personas menos técnicas se movieron a otros departamentos y otras se fueron; la gente que contratamos después era más técnica que la que contratábamos antes. Hubo nervios durante el proceso, y yo lo trataría como un coste normal del cambio, no como algo que esquivar.
Qué haría distinto
Dos cosas.
Le daría al equipo humano un copiloto antes de poner el agente delante de los clientes - para que la gente se acostumbre a trabajar a su lado, y para aprender de casos reales dónde está de verdad la línea de "listo para IA", en lugar de adivinarla y descubrirla en producción.
Y desplegaría más despacio. Fuimos más rápido de lo que yo habría elegido, y no me planté lo suficiente. Los tropiezos iniciales eran arreglables técnicamente, pero mucho más difíciles de arreglar en cómo clientes y supporters se sentían respecto al agente. Esa percepción tardó mucho más en repararse que los bugs.
Escalar sin contratar resultó ir menos de la IA y más de lo que la IA hereda. La nuestra heredó dos años de clasificación, documentación y datos estructurados. Apunta una a un desorden, y escalarás el desorden.