El ecosistema de automatización que construí durante 18 meses y que hoy opera sin mí
La prueba más rigurosa de cualquier sistema de automatización no es que funcione cuando su creador está presente. Es que funcione cuando no lo está. En los 18 meses que tardé en construir el ecosistema completo de automatización, había tenido 2 vacaciones cortas donde el sistema había operado con supervisión del equipo técnico y con mi disponibilidad para consultas a distancia. La prueba real llegó cuando tomé 4 semanas de ausencia completa, sin acceso al email del trabajo y sin disponibilidad para consultas.
El ecosistema que dejé operando comprendía 23 flujos activos en 4 plataformas integradas: Make para la automatización de procesos entre sistemas, Dynamics 365 para la gestión de datos y alertas, Power BI para los dashboards de monitoreo en tiempo real y Copilot Studio para los agentes de conversación. Cada flujo tenía documentación actualizada, un sistema de monitoreo con alertas de fallo y un protocolo de corrección para los casos de error más frecuentes que habíamos documentado en los 18 meses de operación. Dos miembros del equipo técnico tenían capacitación suficiente para gestionar incidentes en mi ausencia.
En las 4 semanas de ausencia, el sistema tuvo 3 incidentes. El primero fue un fallo de conexión entre la plataforma de email y Make causado por un cambio de credenciales de la API que el proveedor de email había implementado sin notificación previa. El equipo técnico lo detectó a través del sistema de alertas de monitoreo, identificó la causa usando la documentación del flujo y lo corrigió en 2 horas. El segundo fue un flujo de nurturing que envió una versión desactualizada de un email de seguimiento después de que se había actualizado el template pero el flujo no había sido reconectado al template nuevo. Detectado en las alertas de monitoreo de contenido, corregido en 45 minutos.
El tercero fue el más significativo y el más interesante: una cuenta del segmento enterprise recibió una alerta de riesgo de churn con un score de 78 sobre 100, el más alto registrado en la historia del sistema para esa cuenta. El manager de customer success siguió el protocolo de intervención, programó una llamada de urgencia con el cliente y descubrió que la causa del score alto era que habían cambiado de sistema de facturación interno, lo que había afectado la sincronización de datos de uso con Dynamics produciendo una lectura incorrecta de los indicadores de actividad. No había riesgo real de churn. Era un artefacto de la migración de datos del cliente.
El ecosistema había funcionado durante 4 semanas con 3 incidentes, 2 de ellos resueltos por el equipo técnico con la documentación disponible y sin mi intervención, y 1 que reveló una limitación del sistema de scoring que requería un ajuste de la lógica de detección de artefactos de migración de datos del cliente. Ese último ajuste lo implementé en la semana de regreso. Fueron 4 semanas que demostraron que el ecosistema había alcanzado el nivel de madurez que permite a su creador alejarse de él sin que el sistema colapse. Ese nivel de madurez no se declara. Se gana con 18 meses de construcción, documentación, correcciones y transferencia de conocimiento al equipo.