SaaS: por qué la primera línea de soporte va antes que desarrollo

Hay un mensaje que llega a todas las empresas de software y siempre está escrito igual: «no me funciona». No dice qué ha dejado de funcionar, ni desde cuándo, ni con qué cuenta. Y como nadie sabe si es un fallo del producto, un permiso mal puesto o una pantalla equivocada, acaba donde acaban todas las dudas: en el canal donde están los desarrolladores.

Los primeros meses eso se aguanta. Después el producto crece, los usuarios crecen, y la gente más cara de la empresa pasa media mañana explicando dónde se cambia una contraseña. La respuesta no es contestar más rápido. Es que ese mensaje no llegue así.

La mitad de lo que entra no es un fallo

Coge la bandeja de tu producto, clasifica una semana entera de mensajes y la lista se parecerá bastante a esta: incidencias de acceso —contraseñas, permisos, cuentas bloqueadas—, dudas de configuración, preguntas de uso que ya están contestadas en la documentación, errores conocidos reportados por décima vez y, al final, los fallos de verdad: los que necesitan que alguien toque código.

Solo el último grupo necesita a tu equipo de desarrollo. Los otros cuatro no, y son la mayoría. El problema es que llegan mezclados, y separarlos también cuesta tiempo: cuando el único que puede separarlos es quien está desarrollando, la separación se paga al precio de desarrollo.

Y el coste no es el rato de contestar. Es la interrupción. Sacar a alguien de un problema técnico para responder una duda de menú y devolverlo después no cuesta cinco minutos: cuesta cinco minutos más el tiempo de volver a entrar. Y pasa varias veces al día.

Es lo que resume la página de SaaS y software en una frase: tus desarrolladores no deberían ser tu primera línea, porque así ni se atiende bien ni se desarrolla.

Qué hace una primera línea de verdad

«Primera línea» suena a filtro, y un filtro que solo reenvía no sirve para nada: mueve el trabajo de sitio. Una primera línea que funciona hace cuatro cosas concretas, y en este orden.

Clasifica. Lo primero de la mañana no es contestar: es mirar lo que ha entrado y decidir qué es cada cosa. Duda de uso, problema de acceso, error conocido, fallo nuevo. Con eso hecho, la cola deja de ser un montón y pasa a ser cuatro colas con dueño distinto.

Resuelve accesos y configuración. Contraseñas, permisos, cuentas bloqueadas, opciones que el usuario no encuentra, integraciones mal conectadas. Es trabajo real y es la parte más grande del volumen. No exige saber programar: exige conocer tu producto y tener permiso para actuar.

Reproduce antes de escalar. Esta es la que cambia el resultado, y por eso tiene su propio apartado más abajo.

Documenta lo resuelto. Cada respuesta que se escribe dos veces es una respuesta que debería estar escrita una sola vez. Quien atiende todos los días ve las repeticiones y las convierte en artículo, en respuesta tipo o en un aviso de que hay algo que cambiar en el producto. Eso es lo que hace que la cola baje con los meses en vez de crecer al ritmo de los usuarios.

Ese es el contenido del trabajo tal y como lo publicamos en soporte técnico de nivel 1. Y el orden importa: si se hace lo cuarto sin lo primero, se documenta lo que uno recuerda en vez de lo que más entra.

Reproducir es el trabajo, no un trámite

Un fallo escalado sin reproducir es un fallo que vuelve. Desarrollo lo abre, no consigue verlo, pregunta, espera al usuario, el usuario contesta dos días más tarde con la mitad de la información, y el caso muere o se reabre. Se ha gastado tiempo de desarrollo para no arreglar nada.

Reproducir significa provocar el fallo a propósito y dejar escrito qué hace falta para verlo: los pasos exactos y en orden, la cuenta y el rol con el que ocurre, el navegador y el dispositivo, qué esperaba el usuario y qué pasó en realidad, y si ocurre siempre o solo a veces. Con eso delante, un desarrollador abre el caso y ya está dentro del problema.

Hay un efecto secundario que vale tanto como el ahorro: al intentar reproducirlos, una parte de los fallos se cae. No era un fallo, era un permiso, un dato mal introducido o una versión vieja en la caché del navegador. Ese caso no llega nunca a desarrollo y nadie tuvo que mirarlo dos veces.

Y hay un tercero, más silencioso: el usuario recibe antes la respuesta de alguien que está mirando su problema de verdad, en lugar de un «lo pasamos al equipo técnico» sin fecha.

Lo que no hace: no toca código

Conviene decirlo pronto, porque es la confusión más habitual cuando se habla de soporte técnico.

No escribe código. No entra en el repositorio. No despliega. No corrige errores en el producto y no decide qué entra en el roadmap. Su trabajo termina exactamente donde empieza el de un desarrollador: en un caso reproducido, documentado y abierto allí donde tu equipo lo trabaje.

Si lo que te falta son manos en el producto —mejoras, integraciones, automatizaciones—, eso es otra cosa y otra conversación: el pod Tech. Mezclar los dos produce la contratación fallida clásica: un perfil técnico al que se le pide contestar tickets y que acaba haciendo mal las dos cosas.

Qué gana tu equipo cuando existe la primera línea

Lo resume mejor que nadie la gente de producto: deja de recibir «no me funciona».

En concreto cambian cuatro cosas. Recibe casos reproducidos, con pasos, entorno y cuenta. Recibe menos casos, porque una parte no era un fallo. Los recibe en su propio gestor de incidencias y no en un mensaje directo a media tarde. Y recupera las horas seguidas, que es lo único que de verdad hace falta para desarrollar.

Al otro lado aparece un dato que nadie estaba mirando y que se ve solo con tener a alguien leyéndolo todo: qué se pregunta más. Tres usuarios distintos con la misma duda en la misma semana no son tres tickets; son un problema de producto o de documentación. Quien atiende todos los días lo ve. Quien entra a ratos, no.

Cómo saber si te toca ya

Cuatro señales, y no hacen falta las cuatro:

• Algún desarrollador contesta usuarios todos los días, aunque sea «solo un rato».
• Hay dudas que se responden por segunda y tercera vez sin que nadie las documente.
• Los fallos se escalan sin pasos para reproducirlos, y vuelven preguntando.
• El tiempo de primera respuesta depende de que alguien mire el canal por casualidad.

Si además tu producto es lo bastante complejo como para que la respuesta correcta dependa de saber cómo funciona por dentro, la primera línea no es un lujo: es lo que evita que cada duda se convierta en una interrupción.

Por dónde empezar

Mide una semana antes de decidir nada. Coge todo lo que entró, clasifícalo en los cinco grupos de arriba y cuenta cuántos hay de cada uno. Ese número —el porcentaje que no necesitaba a desarrollo— es el que toma la decisión, y no hace falta nada más para tenerlo.

Con el número delante, lo siguiente es acotar qué resuelve la primera línea y qué se escala siempre, y dejarlo escrito antes del día uno. La primera semana es formación sobre tu producto con revisión previa de todo lo que sale, y la autonomía suele rondar el 80% en la semana cuatro: cuánto tarda depende sobre todo de lo documentado que esté tu producto, no de la persona.

Si quieres ver el montaje completo, está en la página de soporte técnico. Y si no tienes claro que tu volumen dé para una persona a jornada completa, dilo en la llamada: media hora, y si no encajamos te lo decimos en esa misma conversación.