12 ejemplos de automatizaciones con n8n para empresas

# 12 ejemplos de automatizaciones con n8n para empresas

Los doce ejemplos están más abajo, cada uno con su disparador, su cadena de nodos y el punto exacto por el que se rompe en producción. Pero antes conviene un número que cambia la forma de leer cualquier lista de ejemplos de n8n, incluida esta. El 4 de septiembre de 2026 leímos una a una 199 plantillas de la biblioteca pública de n8n: la mediana es de 13 nodos por flujo, el 72 % pasa de diez y solo el 5 % prevé qué hacer cuando algo falla.

Es decir: la automatización que se describe en una frase se construye con trece piezas. Ninguno de los artículos que hoy ocupan el top 10 de esta búsqueda dice eso, porque ninguno enseña un flujo por dentro.

Lo que de verdad tiene dentro un flujo de n8n

n8n publica una biblioteca de plantillas que cualquiera puede consultar. Son flujos que alguien construyó, publicó y otros han copiado. Es la muestra más honesta que existe de lo que la gente automatiza de verdad, así que la medimos antes de escribir los ejemplos.

Cómo lo hicimos

Descargamos el listado de la biblioteca pública desde `api.n8n.io`, sin credenciales, el 4 de septiembre de 2026. En ese momento contenía 12.024 plantillas. Sacamos una muestra aleatoria de 200 y pedimos el detalle de cada una, que devuelve el flujo completo. Se pudieron leer 199. Descartamos las notas adhesivas, que son comentarios y no pasos.

Un aviso metodológico que nos costó una cifra falsa, por si alguien repite el ejercicio: el buscador de esa API devuelve un campo de nodos que viene agrupado por tipo, no es el flujo. La plantilla 11807 aparece ahí con 17 y en realidad tiene 91 nodos. Los números de abajo salen del detalle de cada plantilla, uno por uno.

Lo que salió

Los tres hallazgos, por orden de importancia para quien va a montar esto en su empresa.

Trece nodos, no tres. La distancia entre «cuando llegue una factura, guárdala en Drive y anótala en una hoja» y el flujo que hace eso de verdad son diez pasos más: comprobar que el fichero es lo que dice ser, extraer los datos, validar que el importe es un número, decidir qué pasa si el proveedor no existe todavía, evitar duplicar la fila si el correo llega dos veces. Esos pasos no aparecen en ninguna lista de ejemplos porque no se pueden contar en una frase.

La mitad del flujo no conecta con ninguna aplicación. En la mediana, la mitad de los nodos son fontanería: mover un campo de sitio, decidir por dónde sigue el flujo, partir una lista, esperar, llamar a una URL genérica. De hecho el nodo más usado de toda la muestra es HTTP Request, con 285 apariciones, por delante de cualquier integración con nombre propio. Los tres siguientes son Set, Code y Google Sheets. Conviene saberlo antes de comprar la promesa de conectar cientos de aplicaciones sin escribir código: se conectan, y luego hay que pegarlas.

Uno de cada veinte prevé el fallo. Solo el 5 % de las plantillas declara qué hacer cuando algo se rompe. Como copiar plantillas es la forma normal de empezar, la consecuencia práctica es que casi cualquier flujo que importes nace sin red. Volvemos sobre esto al final, porque es lo que separa un experimento de algo que puede sostener un proceso de negocio.

Lo que esta medición no prueba

Son plantillas publicadas, no flujos en producción dentro de empresas. Están sesgadas hacia lo que la gente considera presentable y hacia lo que estaba de moda cuando se publicó: el 70 % de la muestra incluye algún nodo de inteligencia artificial, y eso dice más del momento que de lo que necesita una pyme. Tampoco medimos si funcionan ni cuánto tiempo ahorran. Lo que sí sostiene la muestra es el tamaño y la forma de un flujo real, que es justamente lo que los artículos de ejemplos omiten.

Si lo que necesitas es decidir la plataforma antes que el flujo, lo comparamos con datos de precios y operaciones en n8n frente a Make. Y si todavía estás en la fase anterior, la de saber qué procesos merece la pena tocar, el criterio está en ejemplos de workflows y cuáles automatizar. Nosotros montamos estos flujos como servicio de automatización con n8n y Make.

Cómo leer los doce ejemplos

Cada ficha trae tres cosas y ninguna más, porque son las tres que hacen falta para saber si te sirve.

1. El disparador. Qué hace que el flujo empiece. Sin esto no hay automatización, hay una lista de tareas.
2. La cadena de nodos. Los pasos con los nombres reales de n8n, en orden. Es lo que verás en el lienzo.
3. Dónde se rompe. El punto concreto por el que este flujo falla en producción, que casi nunca es el que uno espera.

Los nombres de nodos que aparecen abajo son los que salieron en la medición, así que existen y se usan. El número de nodos de cada ficha es orientativo: cuenta el camino principal, sin las ramas de excepción.

Los doce ejemplos

1. Alta de cliente nuevo desde un formulario

Disparador. El formulario de alta de la web, recogido con un nodo Webhook.

Cadena. Webhook, Set para normalizar los campos, un If que comprueba si el cliente ya existe consultando el CRM con HTTP Request, la rama de alta que crea el registro, Google Sheets para dejar la traza, Gmail con la bienvenida y Slack para avisar al comercial que le toca.

Dónde se rompe. En la comprobación de duplicados. Si el cliente rellena el formulario dos veces, cosa que hace más de lo que parece, acabas con dos fichas y dos comerciales llamando a la misma persona. La comprobación se hace por un campo estable, normalmente el correo o el identificador fiscal en minúsculas y sin espacios, nunca por el nombre.

2. Facturas recibidas por correo

Disparador. Un buzón vigilado con el nodo de correo entrante.

Cadena. Disparador de correo, un If que filtra por remitente o asunto, Extract from File para sacar el texto del PDF, un nodo de extracción de datos que devuelve emisor, número, fecha y total, Set para dar formato, Google Sheets para anotar la fila, Google Drive para archivar el fichero y un aviso a contabilidad.

Dónde se rompe. En el PDF. Las facturas escaneadas sin capa de texto no devuelven nada y el flujo continúa alegremente con campos vacíos. Hace falta un If después de la extracción que compruebe que hay importe y que sea un número, y una rama que aparte lo que no cumple para revisión humana en vez de meterlo en la hoja.

3. Lead de la web al CRM, con enriquecimiento

Disparador. Webhook del formulario o del chat.

Cadena. Webhook, Set, HTTP Request contra el servicio de enriquecimiento por dominio, un If que separa empresa de particular, creación del registro en el CRM, Google Sheets como respaldo y notificación por Slack con los datos ya enriquecidos.

Dónde se rompe. En el servicio externo. Cuando el proveedor de enriquecimiento devuelve un error o tarda, el flujo se cae y el lead se pierde sin que nadie lo sepa. El enriquecimiento tiene que ir después de crear el registro, no antes, para que el peor caso sea un lead pobre y no un lead perdido.

4. Clasificación y reparto de tickets

Disparador. Ticket nuevo, por webhook del sistema de soporte o por programador si no hay webhook.

Cadena. Disparador, lectura del ticket, un nodo de modelo con un parser de salida estructurada que devuelve categoría, urgencia e idioma, un Switch que reparte por categoría, actualización del ticket con la etiqueta, asignación al equipo y aviso al canal correspondiente.

Dónde se rompe. En la salida del modelo. Si no la fuerzas a un esquema, un día devuelve «Facturación» y otro «facturacion» y el Switch manda el ticket a ninguna parte. Por eso en la muestra el parser de salida estructurada aparece 48 veces: es el nodo que convierte una respuesta en un valor con el que se puede decidir. Y la rama por defecto del Switch nunca se deja vacía.

5. Informe semanal a un canal de equipo

Disparador. Schedule Trigger, los lunes a primera hora.

Cadena. Schedule Trigger, varias llamadas HTTP Request a las fuentes de datos, Merge para juntarlas, Code para calcular las variaciones contra la semana anterior, Set para redactar el mensaje y Slack o correo para enviarlo.

Dónde se rompe. En la comparación con la semana anterior. Si el flujo no guarda en algún sitio los datos de la semana pasada, no hay contra qué comparar, y si los guarda en una hoja hay que decidir qué pasa cuando una ejecución falla y deja un hueco. La solución simple es escribir siempre la fila con su fecha y calcular la variación leyendo la fila anterior por fecha, no por posición.

6. Publicación de contenido en varios canales

Disparador. Fila nueva o marcada en una hoja de cálculo, leída con Schedule Trigger.

Cadena. Schedule Trigger, Google Sheets, un If que comprueba que la pieza está aprobada, adaptación del texto a cada canal, descarga de la imagen desde Google Drive, una llamada HTTP Request por red social, Merge de los resultados y actualización de la hoja con la fecha de publicación y el enlace.

Dónde se rompe. En que la mitad de las redes no tiene nodo propio y se publica con HTTP Request contra su API, que cambia. Es el ejemplo más largo de los doce por eso: cada canal es su propia rama con su propio formato. Este es el típico caso donde conviene empezar por un solo canal y no por cinco.

7. Aviso de stock bajo al proveedor

Disparador. Schedule Trigger diario.

Cadena. Schedule Trigger, HTTP Request al sistema de inventario, Split Out para tratar cada referencia por separado, un Filter que se queda con las que están por debajo del mínimo, Set para armar la línea de pedido, agrupación por proveedor y un correo por proveedor.

Dónde se rompe. En la repetición. Si la referencia sigue bajo mínimos mañana, el proveedor recibe el mismo aviso otra vez. Hace falta una hoja o una tabla que registre qué se avisó y cuándo, y un If que no repita el aviso antes de que pase un plazo razonable.

8. Recordatorio de firma de presupuesto

Disparador. Schedule Trigger diario.

Cadena. Schedule Trigger, consulta de presupuestos enviados y sin firmar, un Code que calcula los días transcurridos, un Switch con los tramos de recordatorio, Gmail con el mensaje que corresponde a cada tramo y anotación en el CRM de que se ha enviado.

Dónde se rompe. En el tono y en el freno. Sin un contador de recordatorios enviados, el flujo persigue al cliente indefinidamente. El límite se pone en el propio flujo, no en la cabeza de quien lo montó: tres recordatorios y a partir de ahí una tarea para que llame una persona.

9. Sincronización de dos sistemas sin integración

Disparador. Schedule Trigger cada pocas horas.

Cadena. Schedule Trigger, HTTP Request a los dos sistemas, Code para casar los registros por su identificador, Compare Datasets o un Code que separa altas, bajas y cambios, Split In Batches para no saturar la API de destino y las llamadas de escritura.

Dónde se rompe. En los límites de la API de destino y en el sentido de la sincronización. Sin lotes, la API corta a mitad y te quedas con medio sistema actualizado. Y sin decidir cuál de los dos sistemas manda cuando el mismo campo ha cambiado en los dos, la sincronización se pisa a sí misma. Se decide antes de montar nada, y se escribe.

10. Respuesta de primer nivel con base de conocimiento

Disparador. Mensaje entrante por webhook, por Telegram o desde el formulario de contacto.

Cadena. Disparador, Set, recuperación de los fragmentos relevantes de la documentación, un nodo de modelo con memoria de la conversación, un If que decide si la respuesta es suficiente o hay que escalar, envío al usuario y creación del ticket en la rama de escalado.

Dónde se rompe. En el escalado. Un flujo que siempre responde acaba dando respuestas inventadas a preguntas que no cubre la documentación. La condición de escalado tiene que ser explícita y generosa: ante la duda, a una persona. Y la conversación se guarda entera, porque sin traza no se puede auditar lo que el sistema le dijo a un cliente.

11. Alta de empleado en las herramientas internas

Disparador. Formulario aprobado por la persona responsable.

Cadena. Disparador, Set con los datos normalizados, creación de la cuenta de correo, alta en las herramientas mediante HTTP Request una por una, un If por cada herramienta que solo aplica a ciertos puestos, Google Sheets con el inventario de accesos concedidos y un correo de bienvenida con lo que necesita el primer día.

Dónde se rompe. En los permisos por puesto. Un flujo que da los mismos accesos a todo el mundo es un problema de seguridad servido con eficiencia. La matriz de qué puesto lleva qué herramienta va en una hoja que puede editar recursos humanos, no dentro del flujo, o cada cambio de política es un cambio de código.

12. Vigilancia de una página y aviso de cambios

Disparador. Schedule Trigger, cada hora o cada día.

Cadena. Schedule Trigger, HTTP Request a la página, Code o HTML para quedarse solo con la parte que interesa, comparación contra el último valor guardado en Google Sheets, un If que solo continúa si hay cambio, aviso por Slack o correo y actualización del valor guardado.

Dónde se rompe. En qué se considera un cambio. Si comparas el HTML entero, cualquier identificador de sesión o marca de tiempo dispara un aviso falso y en tres días nadie mira las notificaciones. Se compara un dato concreto, no la página.

Tres cosas que no conviene montar en n8n

La lista honesta también dice que no. Estos tres aparecen en casi todos los artículos de ejemplos y son los que más proyectos han hecho encallar.

Un proceso que todavía no está escrito. Si no puedes describir el flujo con su disparador, sus pasos y sus puntos de decisión en una servilleta, automatizarlo consiste en congelar un desorden. Primero el proceso, después la herramienta.

Un cálculo de negocio complejo. Nóminas, precios con muchas reglas, contabilidad. Se puede hacer con nodos Code encadenados y acaba siendo un programa escrito en el peor editor posible, sin control de versiones ni pruebas. Cuando la lógica pesa más que las conexiones, no lo montes en n8n: hazlo en el sistema que ya tiene esa lógica y usa n8n para moverla de sitio.

Cualquier cosa que decida sobre personas sin revisión. Descartar candidaturas, cerrar cuentas, aplicar sanciones. El flujo puede preparar la decisión y ponerla delante de alguien; tomarla él es un riesgo legal y reputacional que no compensa el minuto que ahorra.

Lo que se rompe en producción

Vuelvo al dato del principio, que es el que separa un experimento de un proceso: solo el 5 % de las 199 plantillas que leímos declara manejo de errores. Cuatro cosas que sí conviene tener, ninguna de las cuales aparece en las plantillas que vas a copiar.

1. Un flujo de error. n8n permite designar un flujo que se ejecuta cuando otro falla. Con uno solo para toda la instancia, que avise a un canal con el nombre del flujo y el mensaje, ya sabes que algo se rompió en lugar de enterarte por el cliente.
2. Idempotencia. Que ejecutar dos veces no haga el trabajo dos veces. Es el fallo más caro y el más silencioso: correos duplicados, facturas dobles, dos altas del mismo cliente. Se resuelve guardando qué se procesó ya y comprobándolo al principio.
3. Lotes y esperas. Las APIs cortan cuando les llegan cien peticiones seguidas. Split In Batches y un Wait entre tandas convierten un flujo que falla al crecer en uno que solo tarda un poco más.
4. Traza. Una hoja o una tabla donde el flujo apunte qué hizo y cuándo. Cuando alguien pregunte por qué un cliente recibió ese correo, esa hoja es la respuesta.

Sobre el ahorro que producen estos flujos no vamos a dar cifras, porque no las hemos medido en tu empresa y nadie puede. El método para calcularlo con tus propios datos está en el post de workflows, y si lo que quieres es ver casos ya medidos, están en seis automatizaciones con resultados.

Por dónde empezar

Uno solo, y aburrido. El primer flujo que funciona compra permiso para el segundo; el primero que falla delante de todo el mundo cierra el tema durante un año.

Elige un proceso que ocurra a diario, que hoy consista en copiar datos de un sitio a otro y en el que un error no tenga consecuencias graves. De los doce de arriba, los candidatos son el aviso de stock, el recordatorio de firma y la vigilancia de una página: son cortos, el disparador es un horario y lo peor que puede pasar es que no salte un aviso.

Móntalo, déjalo correr dos semanas mirando cada ejecución, y solo entonces añade el siguiente. Si en esas dos semanas no ha fallado ninguna vez, es que no lo has probado con datos suficientemente feos.

Preguntas frecuentes sobre ejemplos de n8n

¿Cuántos nodos tiene una automatización normal?

En nuestra medición sobre 199 plantillas públicas, la mediana es de 13, con la mitad de los flujos entre 9 y 20 nodos. Un flujo de tres pasos existe, pero es el 30 % del que cabe esperar cuando el proceso llega a producción con sus excepciones.

¿Se puede usar n8n sin saber programar?

Se puede empezar, y llega un punto en que ayuda mucho. En la muestra, el nodo Code aparece 230 veces y es el tercero más usado. No hace falta ser programador, pero sí perder el miedo a un bloque de diez líneas que renombra campos.

¿Merece la pena copiar plantillas de la biblioteca?

Para aprender, mucho: son flujos reales que puedes abrir y leer. Para producción, con cuidado, porque el 5 % declara manejo de errores y ninguna conoce tus casos raros. Una plantilla es un punto de partida, no un entregable.

¿Cuánto se tarda en montar uno de estos ejemplos?

Depende del número de sistemas implicados y de si tienen nodo propio o hay que ir por HTTP Request. Lo que sí es constante es el reparto: la primera versión sale rápido y las excepciones se llevan la mayor parte del tiempo. Si alguien te da un plazo sin haber visto tus datos reales, no lo ha contado.

¿Hace falta un servidor propio?

No para empezar. La decisión entre la versión gestionada y la instalación propia depende de volumen de ejecuciones, de datos sensibles y de quién va a mantenerla, y la desarrollamos con los precios y los límites reales en n8n frente a Make.