El día del lanzamiento empieza la parte que no se puede simular: volumen, excepciones y clientes reales. En los primeros 90 días se descubre qué hace bien el sistema, dónde duda y qué excepciones aparecen.
La primera semana
La primera semana no va de crecer. Va de mirar casos reales. Lee las conversaciones, revisa las trazas y comprueba qué hizo el sistema cuando no sabía. Los primeros días producen las mejores pruebas porque el equipo todavía no ha aprendido a esquivar los fallos.
No cambies el sistema cada hora. Recoge los casos, agrupa los patrones y arregla primero lo que más fricción genera. Un cambio pequeño y bien probado vale más que diez ajustes de prompt sin evaluación.
El primer mes
Durante el primer mes, el sistema empieza a operar con volumen real. Aparecen los acentos, las prisas, los clientes que cambian de tema y las herramientas que devuelven datos raros. Es normal. La pregunta no es si aparecen excepciones, sino si el equipo sabe qué hacer con ellas.
La revisión semanal debería mirar cuatro cosas: qué resolvió el sistema, qué derivó, qué hizo mal y qué costó. Con eso se decide dónde invertir la siguiente semana. Sin esa revisión, el sistema se queda quieto o se rompe sin que nadie lo note.
El segundo mes
El segundo mes es el momento de ampliar solo lo que ha demostrado que funciona. Si el sistema resuelve bien un tipo de llamada, prueba un tipo cercano. Si falla en un canal, no añadas otro canal. La ampliación tiene que apoyarse en una base estable.
También es el momento de revisar el coste y la latencia. Un sistema que funciona pero tarda demasiado o cuesta más de lo que ahorra no está listo para crecer. Ajustar el modelo, el contexto o la caché puede ser más valioso que añadir una función.
La decisión del día 90
A los 90 días toca una decisión clara: mantener, ampliar o parar. Mantener significa que el proyecto hace un trabajo útil y el equipo puede operar el sistema. Ampliar significa que hay una siguiente pieza con sentido. Parar significa que el sistema no ha demostrado lo suficiente y no merece más inversión.
Las tres decisiones son válidas. Lo que no es válido es dejar el proyecto en un piloto eterno, sin dueño, sin medida y sin fecha. Un proyecto que no se decide, se abandona.
Qué medir
Mide el trabajo, no el modelo. Tasa de resolución, tasa de derivación, tiempo hasta la primera respuesta, coste por caso, número de intervenciones humanas y satisfacción de la persona que recibe el resultado. Si una métrica no cambia ninguna decisión, sobra.
La métrica más importante es la que responde a la pregunta del responsable: ¿este sistema nos está quitando trabajo y lo está haciendo bien? Todo lo demás es contexto.
Qué no hacer
No añadas funciones para justificar el proyecto. No cambies de modelo cada semana sin una evaluación. No dejes la revisión en manos de quien nunca habla con el cliente. No confundas una demo que impresiona con un sistema que aguanta un martes por la mañana.
La reunión semanal
La revisión semanal no necesita una hora. Necesita una agenda corta y alguien que decida. Primero, los casos nuevos: qué ha pasado esta semana que no estaba en la evaluación. Después, las derivaciones: cuántas, por qué y si llegaron con contexto. Luego, los errores: qué falló, en qué paso y si se puede reproducir. Al final, el coste y la latencia: si el sistema se está volviendo más caro o más lento sin mejorar.
De cada reunión tienen que salir una o dos decisiones. Un caso que se añade a la suite, un límite que se ajusta, una herramienta que se arregla o una función que se deja para más adelante. Si la reunión termina sin decisiones, se convierte en una tertulia.
Sigue leyendo