Casos de éxito
Automatización Integraciones Infraestructura
Resolvier LegalTech

De automatizaciones en Zapier a una infraestructura operativa en n8n

Sus automatizaciones funcionaban. El problema aparecía al intentar escalarlas. En vez de migrarlas tal cual, revisamos cómo estaban construidas y las reconstruimos sobre una arquitectura propia, preparada para seguir creciendo.

Sector
Reclamaciones de consumo
Proyecto
Migración y arquitectura
Núcleo
n8n + PostgreSQL

La migración

Antes

1.500 tareas/mes

En Zapier, cada acción completada de un Zap cuenta como una tarea. Pasado el límite, el exceso se factura aparte.

Ahora

Sin límite de ejecuciones

n8n autoalojado: se paga la infraestructura, no el volumen de ejecuciones.

Lo que añade la arquitectura

Idempotencia Componentes reutilizables Trazabilidad Recuperación ante fallos

Referencia de límites y precios: plan Pro de Zapier, 1.500 tareas/mes (58,50 US$/mes).

resolvier.com

Si quieres saber más sobre Resolvier y lo que hacen, puedes visitar su web.

02 — EL PUNTO DE PARTIDA

Las automatizaciones ya existían

Resolvier ya utilizaba automatizaciones para conectar diferentes partes de su operativa. Formularios, HubSpot, Google Drive, Google Docs, contactos y comunicaciones internas dependían de distintos flujos construidos principalmente sobre Zapier.

Y funcionaban. El problema no era que fallaran, sino que habían crecido alrededor de necesidades concretas: cada proceso nuevo sumaba su propia lógica, y con ella, más dependencias y más coste de mantenerlo todo junto.

Una misma persona puede iniciar varias reclamaciones a lo largo del tiempo, y cada una se gestiona como un proceso independiente. Cuando un caso avanza, entran en juego el CRM, la documentación, las comunicaciones y el resto de procesos internos.

El proceso de negocio

El reto no era automatizar una acción aislada. Era coordinar correctamente todo el recorrido.

Un flujo por proceso

Representación simplificada del problema: procesos distintos que comparten pasos intermedios (marcados con borde discontinuo). Cada cambio en esa lógica había que repetirlo en cada flujo.

03 — EL PROBLEMA

El problema aparecía al escalar

A medida que crecía el número de procesos automatizados, crecían también los efectos secundarios de tenerlos todos construidos por separado — y el coste de ejecutarlos.

Los errores de una integración eran más difíciles de aislar del resto del proceso
La misma lógica se repetía en varios workflows; cambiarla significaba tocarlos todos
Cada integración quedaba atada a su workflow, difícil de reutilizar en otro proceso
Entender el recorrido completo de un proceso requería seguir su lógica a través de distintos workflows

El coste de escalar

Pago por tareas Límite alcanzado

Tareas incluidas en el plan

Excesose factura aparte

Zapier cobra por tareas: cada acción completada de un Zap cuenta como una (no así los disparadores ni herramientas integradas como filtros o formateo). Un Zap sencillo que procesa diez registros consume diez tareas, y cada paso adicional multiplica ese consumo. Pasado el límite del plan, el exceso se factura a un precio por tarea mayor. n8n cuenta de otra forma: la unidad es la ejecución completa del workflow, tenga dos pasos o doscientos. Autoalojado, el coste deja de crecer con el volumen y pasa a depender de la infraestructura.

Modelo de facturación según la comparativa de n8n frente a Zapier y la página de precios de Zapier.

04 — EL ENFOQUE

No copiar workflows. Revisarlos.

Una migración puede hacerse de dos formas: reproduciendo exactamente lo que ya existía, o aprovechando el cambio para revisar la arquitectura.

Elegimos la segunda. Cada automatización se analizó antes de reconstruirse: qué duplicaba, de qué dependía, quién era responsable de cada paso y qué pasaba cuando algo salía mal.

Una automatización no termina cuando ejecuta una acción; termina cuando puede comprobar que esa acción se ha realizado correctamente.

05 — CÓMO FUNCIONA

Capas, no flujos sueltos

Cada capa tiene una responsabilidad. Eso evita workflows monolíticos donde la lógica de negocio, las APIs y el control técnico se mezclan en una sola automatización difícil de mantener.

  1. Entrada Formularios (Tally), procesos programados y eventos internos
  2. Orquestación n8n sobre infraestructura propia
  3. Procesos de negocio Workflows especializados por proceso
  4. Componentes Integraciones reutilizables · Numeración · Idempotencia
  5. Sistemas HubSpot · Google Drive · Google Docs · Google Contacts
  6. Persistencia PostgreSQL · Data Tables · Logs
  7. Monitorización Detectar → Normalizar → Registrar → Alertar → Diagnosticar

Arquitectura modular

Los canales pueden cambiar. La lógica del negocio no tiene por qué duplicarse.

Para incorporar una nueva fuente de entrada, se adapta su información al contrato común y se reutiliza la lógica que ya existe.

06 — QUÉ CONSTRUIMOS

Los componentes del sistema

Infraestructura propia

El sistema no depende de los límites de una plataforma de terceros: corre en infraestructura propia, desplegada en Hostinger, con PostgreSQL como capa de persistencia.

Componentes reutilizables

En lugar de reimplementar una búsqueda de HubSpot en cada workflow, hay componentes con contratos de entrada y salida definidos que devuelven respuestas normalizadas.

Validación de resultados

Una ejecución correcta no siempre significa que el resultado sea el esperado. En operaciones críticas, el sistema valida la respuesta antes de continuar y trata como error los resultados que no cumplen las condiciones definidas.

Una misma operación, una sola ejecución

No responde a incidencias previas: se incorporó para que el sistema siga siendo fiable a medida que crece el volumen. Si un proveedor reenvía un evento o un proceso se reintenta, comprueba primero si esa operación ya fue procesada antes de ejecutar acciones críticas.

Así se evita que un reintento o un evento duplicado genere contactos, negocios, documentos, carpetas o comunicaciones repetidas, o deje los sistemas en estados inconsistentes. Aplicado en las operaciones críticas donde corresponde.

Un flujo central de monitorización

Cuando un proceso falla, el sistema captura el workflow afectado, la ejecución, el momento del error, el nodo donde se produjo, el mensaje y el contexto disponible. La incidencia se registra en PostgreSQL y puede utilizarse para generar alertas operativas, en lugar de depender de revisar cada workflow a mano.

Backups automáticos en GitHub

Mediante una ejecución programada, un flujo copia de forma periódica todos los workflows de n8n a un repositorio de GitHub, un archivo por workflow. Solo se genera un nuevo commit cuando el workflow ha cambiado de verdad, y si se le cambia el nombre el historial se conserva, sin duplicados. Si el backup falla, la ejecución queda marcada como fallida y entra en la monitorización central. n8n solo integra el control de versiones con Git en sus planes Business y Enterprise; aquí se resuelve con un flujo propio.

LA DIMENSIÓN DEL SISTEMA

Algunos procesos que gestiona la infraestructura

No se construyó una automatización aislada. Se construyó la base sobre la que se ejecutan, se verifican y se registran los procesos del negocio.

Captación

Entrada desde formularios
Procesos programados

HubSpot

Gestión de contactos
Negocios y asociación con contactos

Documentación y contactos

Numeración y carpetas en Drive
Documentos desde plantillas y archivado
Plantillas de email
Sincronización con Google Contacts

Control operativo

Control de idempotencia
Monitorización de errores
Backup de la infraestructura

Un recorrido completo, de principio a fin

Formulario Localización del contacto Control de idempotencia Numeración Creación de carpeta Generación de documento Creación de negocio Asociación con el contacto Archivo de documentación Verificación Cierre

El usuario inicia una operación. La infraestructura coordina el resto.

07 — EL IMPACTO

De automatizaciones independientes a infraestructura operativa

La diferencia no está solo en haber sustituido una herramienta por otra, sino en cómo se diseñan los procesos a partir de ese momento.

Antes

  • Automatizaciones construidas alrededor de necesidades concretas
  • Lógica repetida entre distintos workflows
  • Integraciones ligadas a procesos específicos, difíciles de reutilizar
  • Menor visibilidad cuando un proceso fallaba o se reintentaba
  • Coste ligado al volumen de tareas ejecutadas, con el techo del plan

Ahora

  • Arquitectura organizada por responsabilidades
  • Componentes reutilizables para integraciones comunes
  • Protección frente a ejecuciones duplicadas en operaciones críticas
  • Errores registrados y monitorizados de forma centralizada
  • Sin límite de ejecuciones: el coste es la infraestructura propia, no el volumen

Resolvier pasa de una colección de automatizaciones que habían crecido con las necesidades del negocio a una infraestructura organizada por responsabilidades, con componentes reutilizables y reglas comunes. Las integraciones se reutilizan en vez de reconstruirse, y el sistema puede seguir creciendo sin levantar cada automatización desde cero.

Confiabilidad antes que complejidad

No todos los procesos necesitan inteligencia artificial y no todos los problemas necesitan un agente. Buena parte del valor de este proyecto está en algo menos visible: una infraestructura determinista y confiable para ejecutar correctamente procesos empresariales. La IA puede incorporarse después, donde aporte una ventaja real. La base debe funcionar primero.

08 — STACK

Tecnologías utilizadas

  • n8n
  • PostgreSQL
  • Hostinger
  • GitHub
  • HubSpot
  • Kommo
  • SMTP
  • Google Drive
  • Google Docs
  • Google Sheets
  • Google Contacts
  • WhatsApp
  • Tally

La entrega incluye convenciones de responsabilidad y nomenclatura para diferenciar procesos de negocio, integraciones y componentes de sistema. El objetivo no es entregar una caja negra, sino una infraestructura que pueda mantenerse, diagnosticarse y seguir evolucionando.

¿Tus automatizaciones también han crecido más rápido que su arquitectura?

Si tienes workflows duplicados, procesos difíciles de mantener o automatizaciones que cada vez cuesta más modificar sin afectar a otras partes del sistema, podemos revisar cómo está construida tu operativa actual.

Revisar mi situación

Revisaremos cómo están conectados tus procesos, detectaremos posibles puntos de mejora y veremos si tiene sentido reorganizar la arquitectura antes de seguir añadiendo automatizaciones.

Ver todos los casos de éxito