Tecnoszubia,
tres días para salvar un cliente .
Resumen del proyecto
De crisis de cliente a feature en días.
Marco visual del proyecto
Al borde del churn.
Tecnoszubia, uno de nuestros mejores clientes en Vidiv, estaba camino de ser churn. El agente funcionaba bien técnicamente pero, cada vez que necesitaban ajustar precios o cambiar una casuística en su base de conocimiento, tenían que abrir un ticket, esperar a que el partner lo escalara a nosotros, y esperar días para un cambio que ellos conocían mejor que nadie.
Tecnoszubia tenía una base de conocimiento compleja: múltiples variables de precios, decenas de casuísticas diferentes, categorías con sinónimos que el agente interpretaba mal. No había un CRM del que recoger contenido y parsear su web quedaba descartado por la complejidad del proceso. Las actualizaciones, constantes, dependían de ellos en primera instancia.
El ciclo vicioso era claro: cliente frustrado porque el agente comunica mal un precio → contacta al partner → partner escala a nosotros → hacemos cambios manuales → validación en tres a cinco días.
Una decisión difícil, tres días de ejecución.
Nunca habíamos dejado que los clientes editaran directamente la base de conocimiento de sus agentes. Los riesgos eran obvios: una configuración mal hecha podía romper el agente completamente. Pero el riesgo de perder un cliente de alto valor y referente sectorial era mayor.
Confiaba en este cliente. Estaban satisfechos con todo excepto con la fricción operativa. Debíamos demostrarles que podíamos resolver el problema. Diseñé y desarrollé una aplicación web conectada al agente mediante webhook. Cada vez que se iniciaba una conversación, el agente consultaba la base de conocimiento actualizada por el cliente en tiempo real.
Interfaz minimalista, con foco en usabilidad. Herramientas para partners (importación y exportación en formato JSON). Conexión mediante endpoint al pre-webhook del agente. Actualización instantánea, sin deploys.
Lo que antes pedía abrir un ticket, escalarlo, editar manualmente, desplegar y validar durante tres a cinco días, ahora lo hacía el cliente editando directamente en la aplicación: dos minutos.
Los clientes que resuelven sus problemas sin esperar, se quedan.
Decisiones.
-
Romper la regla interna.
Nunca habíamos dejado que los clientes editaran directamente la base de conocimiento. Esta vez sí. La regla existía por un motivo — una configuración mal hecha podía romper el agente — pero el riesgo de perder un cliente de alto valor y referente sectorial era mayor. Aceptamos el nuevo riesgo conscientemente y diseñamos alrededor de él.
-
Validar con el mejor cliente, no con un A/B test.
A veces la mejor forma de validar una feature de alto impacto no es un A/B con cientos de usuarios, ni un roadmap de tres meses, ni un análisis exhaustivo de requisitos. Es construir una solución custom para tu mejor cliente en 72 horas y ver si funciona. Si funciona, la escalas. Si no, aprendiste rápido y barato.
-
Usabilidad antes que poder técnico.
Los competidores ofrecían bases de conocimiento editables que obligaban al cliente a entender la arquitectura. Nosotros pusimos el foco en usabilidad y sencillez de uso. Interfaz minimalista, lenguaje cercano al del cliente, herramientas para el partner detrás pero fuera del camino del usuario final.
-
Seguimiento cercano para aprender del agente.
Durante las primeras semanas en las que el cliente se acostumbraba a usar la aplicación, me aseguré de hacer un seguimiento totalmente personalizado. Juntos detectamos y aprendimos el origen de muchos errores del agente: alucinaciones por categorías con sinónimos críticos (maestro/profesor), mala jerarquía en la base de conocimiento, cosas útiles de entender sobre cómo funciona un LLM en producción. Este feedback mejoró el producto core y nuestro know-how más allá de este cliente.
-
De rescate a feature.
Lo que empezó como rescate de emergencia se probó con un segundo cliente, se consolidó, y hoy está camino de ser feature estándar de plataforma. La decisión importante no fue construirlo, sino no dejarlo morir como parche y llevarlo al producto core.
Lo que se quedó.
Cliente salvado del churn. Tickets de soporte continuos que pasan a ser prácticamente cero. Una relación tensa que se convierte en excelente. El partner liberado para aportar valor a otros clientes. La aplicación operativa en dos clientes enterprise y en consolidación como parte del producto core.
La revelación fue contraintuitiva: dar más control al cliente no aumenta el riesgo, aumenta la adherencia. Y el mayor aprendizaje de metodología fue otro: a veces construir rápido para un cliente específico enseña más sobre tu producto que semanas de planificación. La ejecución bajo presión revela qué importa realmente.