Internalizar las automatizaciones de tu agencia: qué exigir antes de cortar

Tres señales de que no eres dueño de tus automatizaciones aunque las pagues

La propiedad de un sistema automatizado no la decide la factura. La decide dónde corre, a nombre de quién están las llaves y si alguien ajeno al que lo montó puede entenderlo. Hay tres señales que aparecen siempre, y las tres se comprueban en una tarde sin avisar a nadie.

• No puedes entrar solo. Si para ver cómo va un proceso tienes que pedirle una captura a alguien, no tienes acceso: tienes un intermediario. La prueba es literal: entra hoy, sin avisar, y mira la última ejecución.
• No sabes qué decide. Si nadie de tu equipo puede explicar por qué un caso concreto acabó en la cola de revisión y otro parecido no, la regla de negocio no es tuya. Está funcionando, pero no la posees.
• No puedes cambiar de proveedor sin parar. Si la única respuesta a «¿y si mañana no seguimos con ellos?» es «se para todo», lo que has contratado no es un servicio: es una dependencia con factura mensual.

Ninguna de las tres implica mala fe. La mayoría de las veces son el resultado natural de haber empezado rápido: se montó en la cuenta del que lo montaba porque era lo ágil, se conectó con las credenciales que había a mano y la regla se acordó por teléfono. Funciona. Y sigue funcionando hasta el día en que quieres moverlo. Por eso esto se comprueba cuando todo va bien, no cuando ya has decidido cortar.

La cuenta y las credenciales: dónde vive el sistema y a nombre de quién

Es el punto que más veces se salta y el único que, si falla, invalida todo lo demás. Hay dos capas y se confunden constantemente: la cuenta de la herramienta donde corren los flujos, y las credenciales de cada servicio al que esos flujos se conectan.

• La cuenta de la plataforma. El espacio de trabajo de Make, la instancia de n8n, el proyecto de Zapier. Tiene que estar a nombre de una dirección de correo de tu dominio —no la personal de nadie—, con tu método de pago y con al menos dos administradores de tu lado. Si el plan lo paga el proveedor y te lo refactura, no es tuya.
• Las credenciales de cada conexión. El acceso a tu CRM, a tu ERP, a la bandeja de correo, a la pasarela de pago. Cada una debería estar creada por ti, idealmente como usuario de servicio con permisos acotados, y no como la cuenta personal de un consultor que un día se irá.
• El dominio y los webhooks. Las URLs a las que otros sistemas te empujan datos. Si apuntan a un dominio del proveedor, cambiar de proveedor obliga a tocar la configuración de terceros, y eso es la parte lenta de cualquier migración.

La comprobación honesta es una pregunta: si mañana cambias la contraseña de administrador, ¿sigue funcionando todo? Si la respuesta es que no, o que no lo sabes, ahí tienes el trabajo pendiente. Y no es un trabajo de negociación: es una migración técnica de un par de días bien hecha, que además te deja las credenciales inventariadas, que es exactamente lo que pide cualquier control serio sobre lo que la automatización puede tocar.

Exportar los flujos: qué se lleva un fichero y qué se queda fuera

Aquí es donde casi todo el mundo se relaja antes de tiempo. Recibes un fichero JSON con los flujos, lo guardas y das el asunto por cerrado. El fichero es necesario, pero no es el sistema: es el plano. Y hay una parte del plano que las plataformas dejan fuera por diseño.

• En Make, el blueprint del escenario es un JSON con los módulos, su configuración y los valores mapeados; las conexiones no viajan dentro, así que quien lo importa tiene que volver a autorizar cada servicio con sus propias cuentas.
• En n8n, el JSON del flujo incluye el nombre y el identificador de la credencial, pero no su contenido; las credenciales se exportan aparte por línea de comandos y salen cifradas, y solo se descifran en una instancia que tenga la misma clave de cifrado.
• En todas, lo que no está en el fichero es el entorno: variables, cabeceras, límites de peticiones acordados con un proveedor, cuentas de correo autorizadas para enviar. Es la parte que hace que el mismo flujo funcione aquí y falle allí.

Por eso la entrega no se acepta contra un fichero, se acepta contra una ejecución. La prueba es simple y no admite matices: importar los flujos en una cuenta tuya y verlos completar un caso real de punta a punta, con tus credenciales, antes de que nadie firme nada. Si el proceso mueve dinero o compromisos con cliente, esa prueba se hace en un entorno de pruebas primero, con la misma disciplina con la que se prueba cualquier cambio sin romper la automatización.

La regla de negocio: lo que no aparece en ningún export

Un flujo exportado te dice qué hace el sistema. No te dice por qué. Y el porqué es lo caro: el umbral de los 3.000 euros, la lista de cinco clientes que nunca pasan por aprobación automática, el motivo por el que los correos de un dominio concreto se ignoran desde marzo. Nada de eso está en el JSON. Está en decisiones que alguien tomó y no escribió.

La forma de recuperarlo no es pedir «documentación» —esa palabra produce PDFs que nadie lee—. Es pedir una lista de decisiones, que es un artefacto mucho más pequeño y mucho más útil.

• Cada bifurcación del flujo, con su umbral y su motivo. Una línea por cada «si… entonces…»: qué compara, contra qué valor y de dónde salió ese valor.
• Las excepciones con nombre. Clientes, proveedores o casos que reciben un trato distinto, y quién autorizó ese trato.
• Qué hace el sistema cuando algo falla. A quién avisa, qué se reintenta, qué se queda esperando a un humano.
• Qué NO hace a propósito. La lista de cosas que se decidió dejar fuera es la que evita que el equipo nuevo «arregle» algo que estaba bien así.

Si el proveedor no puede producir esa lista en un par de horas, no es mala voluntad: es que el sistema nunca se documentó y la regla vive en una cabeza. Es un riesgo tuyo, no suyo, y se resuelve con el mismo método con el que se documenta cualquier automatización que ya está en producción: reconstruir el porqué mirando las ejecuciones reales, no la memoria.

El histórico de ejecuciones: el activo que nadie pide y todos echan de menos

Es la petición que se olvida en el 90% de los traspasos y la que más se echa de menos al mes siguiente. El histórico —qué se ejecutó, cuándo, con qué datos, con qué resultado— es lo que convierte una automatización en algo medible en vez de en un acto de fe.

• Es tu línea base. Sin saber cuántas ejecuciones al día había y qué porcentaje fallaba, no puedes demostrar que el sistema internalizado va igual o mejor. Vas a discutirlo de memoria, y la memoria siempre dice que antes iba mejor.
• Es tu detector de casos raros. Los casos que rompen un flujo no aparecen en la documentación: aparecen en el registro de errores de los últimos seis meses. Esa lista vale más que el manual.
• Caduca. La mayoría de plataformas conservan el detalle de ejecución un tiempo limitado según el plan. Si lo pides tres meses después de cortar, ya no existe.

Pídelo antes de anunciar el cambio y guárdalo fuera de la plataforma: una exportación del registro, aunque sea en bruto. Es también el material que necesitas para saber qué se cayó y qué hay que reprocesar si la migración deja un hueco.

El solape: cómo se corta sin cortar el servicio

Un traspaso bien hecho no tiene día D. Tiene una ventana en la que los dos sistemas conviven y solo uno manda. El error clásico es al revés: fecha de fin de contrato, apagón, y el equipo nuevo descubriendo en caliente que el flujo de facturación tenía una condición que nadie contó.

• Primero espejo, luego mando. El sistema nuevo corre en paralelo sin escribir en producción —o escribiendo en un destino de prueba— y se comparan resultados durante varios días. Lo que discrepa se investiga antes de tocar nada.
• Corte por tramos, no de golpe. Se traspasa un flujo, se verifica una semana, se traspasa el siguiente. El proceso que mueve dinero va el último, nunca el primero.
• El sistema viejo se apaga, no se borra. Queda desactivado y accesible durante el solape. Un flujo borrado el día del corte es un puente quemado con el único que sabía cómo funcionaba.
• Un ciclo completo antes de cerrar. Si hay cierre mensual, el solape incluye un cierre entero. Los casos raros no aparecen los martes: aparecen el día 30.

La lógica es la misma que la de cualquier migración de plataforma bien planteada —es exactamente el método que se usa para migrar de una herramienta a otra sin parar el servicio—, con una diferencia: aquí no cambias solo de herramienta, cambias de dueño del conocimiento. Y esa parte no se importa con un JSON.

Un apunte de honestidad para cerrar: internalizar no siempre es la respuesta. Traer los flujos a casa significa que alguien de tu equipo se queda con la guardia, con las actualizaciones de las APIs y con el mantenimiento continuo, que es un trabajo real con coste real. La pregunta correcta no es «¿lo hago dentro o fuera?», es «¿soy dueño de esto en cualquiera de los dos casos?». Cuando la respuesta es sí, seguir con un proveedor es una decisión económica tranquila. Cuando es no, no estás contratando un servicio: estás alquilando tu propio proceso. Si quieres esa comprobación hecha por alguien de fuera —inventario de cuentas, export probado, regla de negocio reconstruida y plan de solape—, eso es exactamente lo que hacemos en automatización de operaciones.