Tu cola de tickets es un registro de defectos
¿Quieres hablar de este ensayo? Escríbeme: amitkvint@gmail.comcopiado· o escríbeme por LinkedIn
Durante mucho tiempo, la respuesta natural a una cola de soporte que crece era hacer crecer el equipo con ella.
En WPML tenía sentido. WordPress crecía rápido, cada vez más gente usaba WPML y, naturalmente, eso significaba más gente necesitando soporte. En nuestro punto más alto atendíamos unos 4.000 reportes de soporte al mes con unas 30 personas repartidas entre el primer, segundo y tercer nivel.
El enfoque funcionaba. Íbamos al ritmo del crecimiento.
Pero en algún momento empecé a preguntarme si ir al ritmo era realmente lo mismo que mejorar. Si el producto sigue creciendo y la respuesta a más trabajo de soporte es siempre más gente, puedes acabar dedicando muchísimo tiempo a los mismos problemas una y otra vez.
Eso llevó a un cambio en cómo miraba la cola: en lugar de ver los tickets solo como trabajo que había que responder, empezamos a tratarlos como una fuente de información sobre qué se podía mejorar.
Si una persona tiene que responder la misma pregunta una y otra vez, probablemente hay algo aguas arriba que podría estar mejor. Quizá la documentación no es lo bastante clara. Quizá el onboarding confunde. Quizá un mensaje de error no le dice al cliente lo que de verdad necesita saber.
Cuando empezamos a mirar el soporte así, tres cosas se volvieron especialmente importantes.
Medir antes de automatizar. Construimos una capa de analítica propia sobre nuestros datos de soporte que clasificaba los tickets por el problema de fondo y ordenaba los problemas recurrentes por volumen y por el esfuerzo que costaba resolverlos.
Antes de eso teníamos muchas opiniones sobre qué nos consumía el tiempo. Después, teníamos una lista ordenada de verdad.
Y no era la lista que esperábamos. Sinceramente, creo que estas listas nunca lo son.
Tiempo protegido para mejorar. Dejé de pedirle a la gente que trabajara en estos problemas "cuando la cola esté tranquila", porque la cola casi nunca está tranquila.
En su lugar, el equipo tenía tiempo dedicado cada semana para trabajar en lo más alto de la lista. A veces era mejorar la documentación o construir una automatización. A veces era darle a ingeniería suficiente evidencia para mirar un problema del producto.
Esto fue más difícil de mantener de lo que suena. Nuestro primer intento de tiempo protegido fue desapareciendo dentro de la cola al cabo de un par de meses. El instinto del equipo era comprensible: si hay clientes esperando, ayudas a los clientes. Un proyecto interno de mejora siempre puede esperar un día más.
Solo empezó a funcionar de verdad cuando el trabajo de mejora pasó a contar en cómo medíamos la contribución de cada persona, junto a su trabajo normal en la cola. Y, igual de importante, cuando yo dejé de ser el primero en cancelarlo cada vez que las cosas se ponían feas.
Arreglar las cosas en el origen. Algunos de los elementos más valiosos de la lista no eran realmente problemas de soporte. Eran problemas del producto que aparecían en el soporte.
Esa distinción importaba. Decir "los clientes no paran de preguntar por esto" es útil, pero no siempre basta para convencer a un equipo de producto o de ingeniería de que algo tiene que cambiar. Tener los datos de cuántas veces pasaba, cuánto tiempo de soporte consumía y cuál era el problema de fondo construía un caso mucho más sólido.
El autoservicio asistido por IA lo añadimos después, deliberadamente en ese orden.
Para entonces entendíamos mucho mejor la cola, nuestros problemas recurrentes estaban documentados y muchos de los casos comunes ya tenían caminos de resolución definidos. Eso le daba a la IA algo útil con lo que trabajar.
También dejaba mucho más claro el papel de la IA. No estaba ahí simplemente para hacer desaparecer la cola de soporte. Era otra forma de reducir la cantidad de trabajo repetitivo por el que tenían que pasar clientes y supporters.
Mirando atrás, el cambio más grande no fue realmente de contratación, de automatización ni de IA. Fue cambiar lo que pensábamos que era un ticket de soporte.
Un ticket no es solo un problema que alguien de soporte tiene que resolver.
Si suficientes clientes hacen la misma pregunta, también es una señal de que algo aguas arriba necesita atención.
Tu cola ya te está diciendo qué mejorar. La pregunta es si la estás escuchando, o solo intentando vaciarla.