Cuando no hay playbook, construye la pieza que falta: la fricción repetida en soporte es un requerimiento de producto

Cuando distintos clientes se atoran en el mismo punto y soporte repite la misma explicación, el problema no es de soporte: es un requerimiento de producto que nadie ha escrito. En este caso, en lugar de esperar a que ingeniería lo priorizara, el equipo construyó un proyecto de .NET con las clases de integración listas, lo que redujo entre 10 y 15% el tiempo de integración de los clientes y casi eliminó las sesiones de soporte repetidas.

En los primeros años, cada semana era la primera vez

En los primeros años de una startup SaaS en la que fui parte del equipo fundador, éramos el equipo de implementación y soporte. No había playbook. Construíamos el proceso y lo documentábamos al mismo tiempo que acompañábamos a los clientes a integrarse con la plataforma. Cada semana era, literalmente, la primera vez que hacíamos algo.

El problema que se veía como "soporte normal"

La plataforma solo exponía endpoints de API, tal cual. Cada cliente tenía que construir desde cero sus propias clases de integración alrededor de esos endpoints. En el papel, era razonable: la API estaba documentada, y la integración era responsabilidad del cliente.

En la práctica, generaba confusión y sesiones de soporte repetidas. Distintos clientes se atoraban en el mismo punto: no en el negocio, no en la configuración, sino en entender cómo armar esas clases. Y cada sesión se resolvía con la misma explicación que ya habíamos dado la semana anterior a otro cliente.

Pro Tip #1 — Cuando la misma pregunta llega de clientes distintos, deja de tratarla como ticket. Una fricción que se repite no es un problema de soporte: es un requerimiento de producto que todavía nadie ha escrito.

La decisión con información incompleta

No sabíamos con certeza cuántos clientes más iban a pasar por lo mismo, ni si ingeniería iba a priorizar una solución pronto. Podíamos esperar a que alguien lo pusiera en el roadmap, o podíamos resolverlo nosotros.

Decidí no esperar. Construimos un proyecto de .NET listo para usar, con las clases de integración ya armadas alrededor de esos endpoints, y se lo entregamos directamente a los clientes. No era una guía más ni otra página de documentación: era la pieza que les faltaba, funcionando.

Pro Tip #2 — Un proyecto de ejemplo que funciona vale más que diez páginas de documentación. La documentación explica cómo construir algo; un proyecto base elimina la necesidad de construirlo.

Pro Tip #3 — Si tienes lo necesario para resolverlo, no esperes a que otro equipo lo priorice. Esperar también es una decisión, y la pagan tus clientes en cada sesión repetida.

El resultado

El tiempo de integración de los clientes bajó entre un 10 y un 15%, y se redujeron de forma importante las sesiones de soporte en las que un cliente estaba atorado solo tratando de entender cómo construir esas clases. El equipo pudo dedicar ese tiempo a lo que sí necesitaba acompañamiento.

Lo que queda de esta historia

Cuando no tienes playbook, es tentador esperar a tener toda la información antes de decidir. Pero muchas veces el camino más rápido no es esperar a que alguien más se haga cargo, sino construir tú mismo la pieza que falta. Paradójicamente, así es como se empieza a escribir el playbook.

Preguntas frecuentes

¿Cómo saber si un ticket repetido es un problema de producto? Si la misma duda llega de clientes distintos y se resuelve siempre con la misma explicación, deja de ser un caso aislado: es una fricción del producto que conviene resolver en el producto.

¿Es mejor documentar o construir un proyecto de ejemplo? La documentación explica cómo construir algo; un proyecto base funcionando elimina la necesidad de construirlo. Cuando la fricción es técnica y repetida, el proyecto base suele reducir más el soporte.

¿Soporte debe esperar a que ingeniería priorice la solución? No siempre. Si Operaciones tiene lo necesario para resolver una fricción recurrente, esperar también es una decisión, y la pagan los clientes en cada sesión repetida.