Un proceso manual tiene un testigo. Una automatización sin vigilancia, no. Esa es toda la diferencia, y es más grande de lo que parece.
Piénsalo. Cuando una persona mete los leads a mano en el CRM, esa persona es, sin proponérselo, un sistema de monitorización bastante decente. Nota que hoy llegan menos. Nota que uno viene sin teléfono. Nota que el formulario del anuncio nuevo trae los campos cambiados. Es lento, es caro y no escala, pero ve.
El día que automatizas ese proceso, ganas velocidad y pierdes al testigo. Si no pones nada en su lugar, no has automatizado: has apagado la luz.
El fallo silencioso no es un fallo, es una hemorragia
Una automatización que se rompe del todo es casi una buena noticia. Todo se para, alguien se queja en una hora, se arregla esa tarde. Molesta y ya está.
La que hace daño de verdad es la que sigue ejecutándose y deja de hacer bien su trabajo. El flujo corre, la herramienta lo marca en verde, y por dentro mete el campo vacío, se salta un paso o duplica el envío. Desde el punto de vista del sistema no ha pasado nada raro. Desde el punto de vista del negocio llevas tres semanas perdiendo los leads de un canal.
Y aquí está lo que más me revienta: casi siempre el que descubre el fallo es el cliente. Escribe alguien preguntando por qué no le ha llegado su acceso, o por qué le habéis cobrado dos veces, y en ese momento no estás arreglando un flujo. Estás gestionando una reclamación con toda la información en contra.
El coste real de ese tipo de fallo tiene tres capas. Está lo que se pierde mientras dura. Está lo que cuesta reconstruirlo después, si es que se puede. Y está la tercera, la que nadie presupuesta: la confianza. Cuando el equipo descubre dos o tres veces que “la automatización no iba”, empieza a comprobarlo todo a mano por su cuenta. En ese momento has pagado la automatización y sigues haciendo el trabajo manual. Enhorabuena, ahora tienes los dos costes.
Por qué pasa: nadie construye para el día malo
No pasa por dejadez. Pasa porque el incentivo, mientras montas, empuja justo en dirección contraria.
Cuando estás construyendo un flujo, tu objetivo es que funcione. Lo pruebas con dos registros, sale bien, sientes el chute y pasas a lo siguiente. Pensar en el fallo es aburrido, alarga el trabajo y no se ve en la demo. Así que se deja “para después”, y después es un sitio que no existe en la agenda de nadie.
Hay algo más profundo. La monitorización tiene un problema de percepción: cuando funciona, no pasa nada. Nadie te felicita por la alerta que no saltó. Es el mismo motivo por el que los backups no se prueban y los seguros dan pereza. Solo se convierte en prioridad la semana siguiente al susto, y para entonces ya has pagado el susto.
Y luego está la trampa de creerse cubierto. “Tenemos las notificaciones de error activadas.” Vale. Eso te avisa de lo que la herramienta reconoce como error. Un formulario que cambia un campo, un webhook que nunca llega, un paso que se ejecuta a medias: nada de eso genera un error. No hay ejecución fallida que notificar. El silencio no es señal de que todo va bien; en la mayoría de los casos, el silencio no es ninguna señal.
Qué exijo antes de dar por terminada una automatización
Tengo una regla que no negocio con nadie: un proceso crítico sin logs no está terminado. Da igual que funcione en la demo. Si no puedo saber qué hizo ayer, no lo puedo operar, y si no lo puedo operar, no lo he entregado.
Encima de eso, tres cosas más.
La primera es una alerta con dueño. No una alerta a un canal genérico donde se mueren las notificaciones. Una persona con nombre que recibe el aviso y sabe que es suyo. Una alerta que no tiene dueño no es una alerta, es ruido que enseñas en una reunión para decir que hay monitorización.
La segunda es una comprobación de resultado, no de ejecución. Es la que casi nadie pone y la que caza el 80% de los fallos silenciosos: contar lo que entra y contar lo que sale. Si ayer hubo 120 registros en el formulario y en el CRM hay 114, algo pasó, aunque las 120 ejecuciones estén en verde. La pregunta correcta no es “¿se ejecutó?”, sino “¿está el resultado ahí?”.
La tercera es el latido: un aviso cuando un flujo lleva demasiado tiempo sin correr. Porque el fallo más silencioso de todos es el que no produce ninguna ejecución, y ahí no hay nada que se ponga rojo. Un flujo muerto es invisible por definición.
El detalle técnico de cómo se monta todo esto —logs, reintentos seguros, idempotencia, reconciliación diaria— lo tienes en automatizaciones que fallan en silencio. Aquí me interesa el criterio anterior a la implementación.
La pregunta que hago antes de automatizar nada
¿Cuánto tardaríamos en enterarnos si esto dejara de funcionar hoy?
Si la respuesta es “semanas”, ese proceso no está listo para funcionar solo. No importa lo bien construido que esté el flujo. Y si la respuesta es “depende de si un cliente se queja”, entonces tu sistema de monitorización son tus clientes, que es la forma más cara de monitorizar que existe.
Automatizar un proceso no es delegarlo y olvidarlo. Es cambiar trabajo de ejecución por trabajo de supervisión. Ese cambio es un negocio buenísimo, pero solo si haces la segunda parte. Si te quedas con la primera, lo que has hecho no es ahorrar trabajo: es esconderlo hasta que el coste aparezca de golpe.
Si algo se te escapa, es porque no lo sabes.
