Escalar soporte sin contratar
¿Quieres hablar de este ensayo? Escríbeme: amitkvint@gmail.comcopiado· o escríbeme por LinkedIn
En el soporte de WPML atendíamos unos 5.000 reportes al mes. Nada estaba realmente roto cuando esto empezó. No había un gran backlog ni una crisis que nos obligara a actuar. Simplemente creía que podíamos hacerlo considerablemente mejor, lo que en realidad hizo el caso más difícil de defender de lo que habría sido durante una crisis.
El trabajo ocurrió en dos etapas, y el orden importó.
Primer acto: el trabajo poco glamuroso
Antes de introducir ninguna IA, trabajamos en lo básico: mejor autoservicio, recogida automática de datos de depuración cuando un cliente reportaba un problema y diagnósticos predefinidos para los casos recurrentes.
En su momento, esto era simplemente buena operación de soporte. Mirando atrás, fue también lo que hizo posible el proyecto de IA. Para cuando introdujimos un agente de IA, nuestros problemas comunes ya estaban documentados, los reportes llegaban con información técnica útil adjunta y los casos recurrentes tenían formas claras de resolverse.
En mi experiencia, aquí es donde se tuercen muchos proyectos de IA en soporte. No por el modelo, sino por el desorden que lo rodea. Apuntas la IA a una cola que nadie ha documentado bien y esperas que de alguna manera lo resuelva todo sola.
Normalmente no lo hace.
Segundo acto: el agente
Estuve muy involucrado en el despliegue de un agente de IA orquestado, llevándolo del 10% de las conversaciones entrantes al 100% en unos seis meses. Cuatro decisiones acabaron importando mucho más que cualquier prompt que escribimos.
- Primero, un agente de triaje. Cada reporte se clasificaba como "AI Ready" o "Needs Human" antes de que pasara nada más. Los casos Needs-Human iban directos a un supporter, con los datos de depuración ya recogidos, para que pudiera empezar a resolver el problema en lugar de dedicar los primeros mensajes a pedir información. En los primeros meses, alrededor del 60% de los reportes se clasificaba como AI Ready.
- Un agente de escalado. Alrededor del 30% de los casos AI Ready terminaba igualmente con una persona. La diferencia era que esa persona recibía el historial completo de lo que la IA ya había intentado. Si escalar significa empezar la conversación otra vez desde cero, básicamente has fallado dos veces.
- Un control manual. Aparece un bug nuevo un martes, el agente no lo conoce y puede pasarse el día entero dando la respuesta equivocada con total seguridad. Pedí una forma de meter información nueva directamente en el sistema cuando pasara algo así, en lugar de esperar al ciclo normal de actualización.
- Un ciclo permanente de evaluación. Cada semana, durante las primeras semanas, revisaba lo que el agente les había dicho realmente a los clientes y buscaba dónde se había equivocado. Esos hallazgos los devolvíamos al sistema. Ese ciclo nunca llegó a desaparecer. De hecho, creo que es la parte más importante de todo esto. Y que yo sepa, sigue en marcha.
Qué cambió
Alrededor del 30% del trabajo total - sobre todo problemas conocidos y guías documentadas - lo absorbió el agente por completo en las primeras semanas. Tras el despliegue completo, el tiempo medio de resolución bajó de unas 24 horas a unas 10.
El equipo se hizo más pequeño, no más grande. Algunas de las personas menos técnicas pasaron a otros departamentos y otras se fueron. Pero el cambio más interesante fue en lo que les quedó a los supporters.
Cuando los tickets fáciles y predecibles desaparecieron, los supporters se quedaron con los casos ambiguos y los problemas genuinamente difíciles. Eso hizo que la velocidad dejara de ser una forma especialmente justa de juzgar el trabajo de alguien.
Obviamente hubo cierto nerviosismo alrededor de todo esto. No creo que sea algo que se pueda gestionar del todo. Cuando le cambias a alguien el trabajo de forma tan drástica, va a tener sentimientos al respecto.
Qué haría diferente
Dos cosas.
Primero, le daría al equipo humano un copiloto antes de poner el agente delante de los clientes. Le daría tiempo a la gente para acostumbrarse a trabajar con la IA y permitiría aprender de casos reales dónde debería estar de verdad la línea de "AI Ready". Algunas de esas decisiones las estábamos tomando ya en producción.
Segundo, desplegaría más despacio. Fuimos más rápido de lo que yo habría elegido, y no me opuse con suficiente fuerza.
Los primeros problemas eran en su mayoría arreglables desde el punto de vista técnico. Lo difícil fue cómo se sentían clientes y supporters con el agente. Cuando la gente pierde la confianza en un sistema, arreglar el bug de fondo no arregla automáticamente esa confianza. Eso llevó mucho más tiempo.
Al final, escalar el soporte sin contratar resultó tener menos que ver con la IA en sí y más con lo que le das a la IA para trabajar.
La nuestra heredó años de clasificación, documentación y datos estructurados.
Si apuntas la IA a un desorden, lo más probable es que simplemente escales el desorden.