El soporte también es producto
Por qué las plataformas internas se construyen tanto en el Help Center como en el roadmap
Cuando hablamos del valor de una plataforma interna, casi siempre nos referimos a la tecnología. De runtimes, de fiabilidad, de escalabilidad y de la siguiente mejora técnica que, en teoría, nos permitirá ir más rápido. Pero con bastante frecuencia dejamos de lado una de las palancas más claras para construir una buena plataforma: el soporte.
El soporte no es solo una función operativa ni un coste inevitable para que todo siga funcionando. Es una herramienta fundamental para construir confianza con quienes usan la plataforma a diario. Confianza en que el sistema es fiable, en que el equipo detrás responde cuando algo falla y en que hay una preocupación real por la experiencia de uso, no solo por la arquitectura o la tecnología de moda.
Esa confianza se construye, en gran parte, estando cerca de los usuarios. El soporte pone al equipo de plataforma en contacto directo con los problemas reales, con los puntos de fricción que no aparecen en los diagramas y con decisiones de diseño que parecían razonables, pero que, en la práctica, generan complejidad innecesaria. Cuando eso ocurre, la conversación deja de ser teórica y pasa a estar anclada en el uso real de la plataforma.
La gestión de incidentes es el ejemplo más evidente. No solo importa cómo se resuelven desde el punto de vista técnico, sino también cómo se comunican, cómo se analizan después y qué acciones se toman para evitar que vuelvan a repetirse. Para los equipos que dependen de la plataforma, esa respuesta define gran parte de la percepción de fiabilidad y madurez del equipo que la mantiene.
Pero el soporte no se limita a los incidentes. También está en el acompañamiento diario, en cómo se responde a una duda, en si alguien siente que hay un equipo al otro lado que escucha y se preocupa. Ese tipo de interacción transmite algo muy potente: que la plataforma existe para servir a los equipos de producto y no al revés.
Y en este punto, siempre suele aparecer la misma conversación dentro de los equipos de ingeniería. No suele pasar en una reunión formal ni en un documento bien estructurado, sino en una charla cualquiera con alguien del equipo. Pongamos que se llama Raúl, nombre ficticio:
Raúl: Vale, pero si nos centramos en soporte, no vamos a desarrollar ninguna feature nueva
João: Eso es cierto si el soporte se convierte en apagar fuegos sin parar
R: Exacto, es justo lo que me preocupa. Que acabemos viviendo en el Help Center
J: Entonces el problema no es el soporte, sino qué hacemos con él. Si solo cerramos tickets, no aprendemos nada
R: ¿Y qué propones? Porque los tickets no se van a resolver solos
J: Que cada ticket sea una señal. Algo que nos dice dónde falta automatización, dónde la documentación no funciona o dónde el producto obliga a hacer cosas a mano
R: Pero eso sigue quitando tiempo
J: A corto plazo, sí. A medio plazo, no. Si usamos ese feedback para eliminar clases enteras de problemas, el volumen de soporte baja
R: ¿Y de verdad pasa eso?
J: Pasa cuando dejamos de ver el soporte como trabajo reactivo y lo usamos para tomar decisiones de producto y plataforma
R: Entonces el objetivo no es hacer más soporte, sino necesitar menos
J: Exacto. Menos tickets y más tiempo para construir las features que realmente hacen la vida más fácil a quienes usan la plataforma
Ahí está, para mí, el punto clave. El soporte no debería competir con el desarrollo de nuevas capacidades. Debería ser uno de los principales factores para decidir qué construir, qué mejorar y qué dejar de hacer.
Cuando se trata de esta forma, ocurre algo casi contraintuitivo. A medida que la plataforma mejora de forma estructural, la carga de soporte disminuye. Y con menos fricción, el equipo gana foco y tiempo para invertir en las mejoras que de verdad aportan valor.
Por eso creo que, en plataformas internas, el soporte no es una distracción del trabajo importante. Es una de las formas más claras de asegurarse de que ese trabajo importa de verdad.
— João