Qué automatizar y qué no (el mapa antes de tocar ninguna herramienta)

Voy a empezar por lo que no vas a leer en esta nota: que la IA va a transformar tu negocio. Puede que sí, pero esa conversación no ayuda a decidir nada un martes por la mañana.

Lo que sí ayuda es una pregunta incómoda: de todo lo que haces a mano cada semana, ¿qué merece automatizarse? Y la respuesta honesta casi nunca es “todo”.

La regla que uso

La traigo de automatizar pruebas de software, donde el mismo error cuesta caro: automatizar lo que no tocaba y acabar manteniendo un monstruo que nadie se atreve a borrar.

Un proceso merece automatizarse cuando cumple las cuatro:

1. Se repite. Si pasa una vez al trimestre, automatizarlo cuesta más de lo que ahorra. Vale más escribir cómo se hace.
2. Es estable. Si los pasos cambian cada mes, automatizarás una foto de algo que ya no existe.
3. Las reglas se pueden escribir. Si depende de “según cómo lo veamos”, no es automatizable todavía: primero hay que decidir el criterio.
4. Duele. O cuesta horas, o genera errores que cuestan dinero, o se hace tarde y mal porque nadie quiere hacerlo.

Si falla una, el resultado típico es un flujo que se rompe a las tres semanas y que nadie sabe arreglar.

Antes de automatizar: escribir el proceso

Suena poco espectacular, pero es donde aparece el valor. Sentarse a describir un proceso paso a paso hace que salten a la vista dos o tres cosas absurdas que se hacen “porque siempre se ha hecho así”. A veces el trabajo termina ahí: el proceso se simplifica y ya no hace falta automatizar nada.

Automatizar un proceso malo solo consigue hacerlo mal más rápido, y además lo congela: una vez montado, cuestionarlo cuesta más.

Dónde encaja la IA, y dónde no

La parte de IA de todo esto es más pequeña de lo que parece en las presentaciones. En un flujo normal, casi todo son cosas aburridas y deterministas: recoger un formulario, mirar si ese cliente ya existe, escribir en una hoja, avisar por correo. Eso no necesita un modelo: necesita una conexión bien hecha.

La IA aporta en los puntos donde antes hacía falta una persona leyendo: clasificar mensajes que llegan sin estructura, resumir una conversación larga, extraer cuatro datos de un documento, redactar un primer borrador que alguien revisará.

Y hay una regla que no me salto: si el resultado no se puede revisar, no se automatiza. Un modelo que clasifica correos se equivoca de vez en cuando; eso es asumible si el error se ve y se corrige. Un modelo que manda respuestas a clientes sin que nadie las lea, no.

Cómo lo hago yo

Aquí toca ser claro, porque en esto no tengo veinte años de oficio: automatización de procesos de negocio con n8n es mi línea más nueva y todavía no la he aplicado en ningún proyecto. Lo que sí llevo tres años haciendo es automatizar pruebas y tareas en entornos de desarrollo: suites que corren solas en cada despliegue, y scripts que sustituyeron recogidas de datos y traspasos que antes se hacían a mano.

La mecánica es la misma, y el reflejo que traigo de ahí es el que de verdad importa aquí: un flujo automático es código que nadie mira hasta que falla. Por eso lo monto como montaría una suite de tests:

• Se prueba antes de activarlo, con casos normales y con los raros.
• Avisa cuando falla, en lugar de fallar en silencio. Un flujo roto que nadie detecta es peor que no tener flujo.
• Queda documentado: qué hace, qué toca y cómo se para.

Y empiezo por un proceso pequeño, con precio cerrado, para que puedas ver si esto te sirve sin jugarte nada. Si al terminar el primero no ves el valor, no hay un segundo.