n8n para equipos B2B: arquitecturas reales, no hola-mundo.
Cómo usamos n8n para conectar GoHighLevel, ERPs locales, WhatsApp Business API y Paid Media en empresas B2B de LATAM. Tres arquitecturas reales, con patrones de producción.
Si tu empresa B2B tiene más de tres sistemas vivos — un CRM, un ERP, WhatsApp Business, email marketing — ya necesitas n8n. Lo que no necesitas es otro tutorial de “cómo crear tu primer flow”. El problema real no es aprender a conectar dos nodos; es saber qué arquitectura sostiene tu operación cuando pasas de 10 leads diarios a 100, cuando el ERP colombiano del cliente no tiene SDK oficial, cuando el bot recibe un audio de 3 minutos y hay que clasificarlo antes de que el paciente se vaya.
Este post no es un tutorial. Asume que ya sabes qué es n8n, que distingues un trigger de una acción, y que has tocado un HTTP Request node. Lo que vas a encontrar son tres arquitecturas reales que corren hoy en producción en clientes míos — una constructora en Colombia, una clínica de estética, un distribuidor en Florida — y los patrones que aplicamos en todas.
Qué n8n NO es, para quitarlo del medio.
Antes de arquitecturas, confusiones. Las escucho todas las semanas.
n8n no es un CRM. Es un motor de orquestación. Si guardas contactos y pipeline dentro de n8n, lo usas mal — esa data vive en GoHighLevel, HubSpot o Pipedrive. n8n solo mueve información entre ellos.
n8n no reemplaza un ERP. Lo conecta. Si tu constructora factura con Cinco, tu retail con SAP Business One, o tu importadora con World Office, n8n es el cable que pasa contactos calificados del CRM al ERP y trae de vuelta el estado de facturación.
n8n no es “Zapier más barato”. Zapier es plug-and-play para equipos no técnicos. n8n requiere que alguien del equipo entienda HTTP, JSON y webhooks, y pueda leer documentación de APIs. Si nadie en tu empresa puede escribir un POST con headers de autenticación, n8n no es para ti hasta que contrates a alguien que sí pueda.
Y n8n self-hosted no es “gratis”. Es barato, pero necesitas un VPS, backups automáticos, monitoreo de uptime y un proceso para restaurar workflows. Gratis es el binario; la operación cuesta.
Cuándo sí usar n8n: cuando tienes un stack B2B real con más de tres sistemas y necesitas sincronización confiable, no scripts sueltos que nadie revisa.
Arquitectura 01 — CRM y ERP sin triple digitación.
Caso: constructora en Colombia con 40 obras simultáneas y equipo comercial de ocho personas. Stack: GoHighLevel para captura y pipeline, Cinco (ERP local colombiano) para facturación y contabilidad.
El problema era la triple digitación. El mismo cliente entraba por WhatsApp, la asesora lo copiaba al ticket interno y luego al CRM, y cuando se convertía, el backoffice lo volvía a digitar en Cinco para poder facturar. Tres veces el mismo dato, con tres versiones distintas del NIT. Costo real: facturas rechazadas por DIAN, cobros atrasados, y una asesora dedicando el 30% de su jornada a digitar.
La solución con n8n tiene cinco nodos y cabe en una pantalla:
[Webhook GHL] → [Validate Fields] → [HTTP Cinco Create Client] → [Update GHL Tag] → [Slack Notify]
↓ on fail
[Retry 3× backoff] → [Alert Staff]El trigger es un webhook de GoHighLevel que dispara cuando un contacto pasa a la etapa “calificado” del pipeline. Un nodo Set valida que existan los campos mínimos obligatorios en Cinco — NIT, razón social, email, teléfono, ciudad — y arma el payload en el formato exacto que espera el endpoint de creación de terceros:
// Node: Set (Map GHL → Cinco)
return [{
json: {
nit: $json.customField.nit,
razonSocial: $json.companyName || $json.fullName,
email: $json.email,
telefono: $json.phone,
ciudad: $json.customField.ciudad,
tipoTercero: "cliente",
externalId: $json.contactId // clave para idempotencia
}
}];Un HTTP Request con autenticación Bearer pega contra el API de Cinco y crea el tercero. Otro nodo actualiza el tag del contacto en GHL a cinco-creado con el ID del ERP guardado en un custom field. Y si todo salió bien, un mensaje corto a Slack para que el equipo comercial vea que el cliente ya está en el sistema contable.
Lo interesante está en la rama de error. Si el HTTP Request falla — el ERP colombiano a veces se cae a las 9am cuando todo el mundo factura —, el nodo entra en un bloque de reintentos con backoff exponencial: 30s, 60s, 120s. Si al tercer intento sigue fallando, se dispara una alerta al canal de Slack del equipo técnico con el payload completo y el error, y el contacto queda marcado en GHL con el tag cinco-pendiente para que alguien lo resuelva a mano.
Este flujo lleva seis meses corriendo sin intervención manual. La asesora no digita dos veces más. El tiempo desde que un lead se califica hasta que puede recibir su primera factura bajó de 48 horas a menos de dos minutos.
Arquitectura 02 — Bot WhatsApp con IA que escala a humano.
Caso: clínica de estética en Colombia, cinco especialistas, 12 tratamientos, 80 conversaciones diarias por WhatsApp. Stack: WhatsApp Business API (YCloud), n8n, OpenAI GPT-4, Whisper, GHL y Agenda Pro.
El problema no era “no tener bot”. Ya tenían uno, genérico, basado en palabras clave, y estaba perdiendo pacientes. Las pacientes mandan audios de dos minutos describiendo su historia; el bot viejo respondía con un menú numérico. Pedían disponibilidad para “la semana que viene con cualquier doctora”, y el bot exigía fecha exacta. Tasa de abandono: brutal.
La arquitectura nueva vive en un único workflow de n8n con siete nodos principales:
[Webhook YCloud] → [Switch tipo] → texto ─────────────────┐
→ audio → [Whisper] ──→ [Classify Intent]
→ imagen → [Vision] ↓
[Switch intent]
├─ agendar → [Agenda Pro]
├─ costos → [GHL lookup]
└─ queja → [Escalate Human]El switch inicial clasifica por tipo de contenido. Si es audio, el archivo pasa por un HTTP Request contra la API de Whisper, se transcribe, y la transcripción entra al mismo pipeline de texto. Si es imagen — una paciente mandando una foto de una cicatriz o una zona del cuerpo — se procesa con GPT-4 Vision y se describe en texto. Todo converge en un clasificador de intención.
El clasificador es un nodo Code en JavaScript que arma un prompt corto a GPT-4 con los últimos 10 mensajes de la conversación (guardados en Redis con TTL de 24 horas) y devuelve uno de cuatro intents: agendar, costos, queja, consulta_general. Nada más. No genera respuestas libres; solo clasifica.
Según el intent, el flujo se ramifica:
Si es agendar, un nodo consulta la API de Agenda Pro con el tratamiento detectado y los próximos siete días, filtra por las especialistas habilitadas para ese procedimiento, y responde con tres slots reales. Si la paciente confirma uno, se crea la cita en Agenda Pro y se mete el lead en el pipeline de GHL con el tag agenda-auto.
Si es costos, n8n consulta el custom field plan_paciente en GHL — nueva, recurrente, premium — y responde con el rango de precios correspondiente, no con una lista genérica.
Si es queja o si el intent es consulta_general con baja confianza, el bot hace algo crítico: escala. Manda un mensaje a la paciente diciendo que una asesora humana va a contactarla en minutos, crea un lead caliente en GHL con toda la transcripción de la conversación, y dispara una notificación por WhatsApp al número personal de la asesora comercial con el contexto resumido. Nunca inventa. Nunca dice “creo que cuesta tanto”.
Los bots que alucinan pierden clientes.
Ese principio define el diseño entero. Preferimos un bot que escale demasiado, a uno que responda con información inventada. La clínica pasó de 30% de conversaciones abandonadas al día a menos del 8%, y las asesoras humanas ahora atienden solo conversaciones calientes con contexto completo.
Arquitectura 03 — Reactivación multi-canal de base dormida.
Caso: distribuidor B2B en Florida con catálogo industrial y unos 600 leads en GHL que no habían tenido actividad en más de 45 días. Stack: GoHighLevel, n8n, Twilio (SMS), WhatsApp Business API y un proveedor de llamadas con voz IA para el último intento. Presupuesto del cliente para rescatar base dormida: bajo. Objetivo: reactivar al menos un 12% antes de marcar como perdidos.
El flujo es un cron diario en n8n:
# Cron trigger
schedule: "0 10 * * *" # 10:00 AM hora local del cliente
timezone: "America/New_York"A las 10am se dispara un HTTP Request contra el API de GoHighLevel que pide 20 contactos con el tag reactivation-pending y última actividad mayor a 45 días. Por qué 20 y no 600: porque el objetivo es tocar leads de forma humana, no quemarlos en una ráfaga. Un SplitInBatches itera uno por uno.
Por cada lead, el flujo agenda tres toques en canales distintos, con 72 horas entre cada uno:
El primer toque es WhatsApp. Un template aprobado con oferta personalizada según el segmento del cliente (extraído de un custom field de GHL). El mensaje incluye un reply button que, si el cliente toca, dispara un webhook que elimina el tag reactivation-pending y mete al lead en pipeline de venta activa.
Si a las 72 horas no hubo respuesta, el segundo toque es SMS vía Twilio. Un HTTP Request con el endpoint de Messages, un texto corto — máximo 160 caracteres — con un link acortado que, si se abre, también dispara webhook de reactivación.
Si a las 72 horas tampoco hubo respuesta, el tercer toque es una llamada automatizada con voz IA. Un HTTP Request a la plataforma de llamadas, script corto de 40 segundos, y si la persona descuelga y dice “no me interesa” en cualquier momento, la plataforma marca el resultado y n8n elimina el tag. Si no contesta, el lead pasa a reactivation-failed.
Cada lead reactivado recibe un tag dinámico con el mes: reactivated-2026-04. Eso alimenta reportes nativos de GHL que el gerente revisa cada lunes sin necesidad de dashboards externos.
Tres meses después, la base de 600 leads rindió 94 reactivaciones — 15,6% — que entraron a pipeline activa. El costo variable total (SMS, llamadas, templates) fue menor al margen de una sola venta promedio.
Patrones de producción que usamos siempre.
Estas tres arquitecturas comparten ocho prácticas que aplico en todo flujo que pasa a producción. Saltarse cualquiera es deuda que explota a los tres meses.
Uno, webhooks firmados con HMAC. Ningún webhook queda expuesto sin una llave que el emisor firme y n8n verifique en el primer nodo.
Dos, idempotencia. Todo flujo usa un ID externo — el contactId de GHL, el orderId del ERP — como clave de deduplicación. Si el webhook llega dos veces, no se crea el cliente dos veces en Cinco.
Tres, reintentos con backoff. Tres intentos, esperas de 30s, 60s y 120s. Si falla las tres, es estructural y vale la alerta humana.
Cuatro, alertas estructuradas a Slack o Telegram. No “algo falló”. El mensaje incluye workflow, nodo, código de error, payload truncado y link directo a la ejecución en n8n.
Cinco, logs estructurados en PostgreSQL. Cada workflow crítico escribe una fila por ejecución con timestamp, input hash, output hash, duración y status. Cuando el cliente pregunta “¿cuándo entró este lead al ERP?”, la respuesta es una query.
Seis, separación production y staging. Dos instancias distintas; los webhooks de staging apuntan a sandboxes de cada API. Este punto me ha evitado más incidentes que todos los demás juntos.
Siete, backups diarios del export de workflows. Un cron sube los JSON a S3 o Backblaze. Si la VPS muere, restauras en 20 minutos.
Ocho, monitoreo de consumo de APIs. OpenAI, Whisper, Twilio y WhatsApp cobran por uso. Un dashboard simple con gasto diario por workflow te avisa cuando un bug quema USD 40 por hora antes de que sean USD 40k en el mes.
Cuándo n8n no es la herramienta.
Ser honesto con el cliente cuando n8n no encaja ahorra problemas a todos.
Si el volumen total de ejecuciones es menor a 100 por día y los flujos son simples — un webhook dispara un email —, Zapier o los workflows internos de GoHighLevel son más fáciles de mantener y te evitan operar un VPS.
Si necesitas latencia menor a 500 milisegundos — por ejemplo, scoring en vivo durante checkout —, n8n no es la herramienta. Es una plataforma de orquestación, no un motor de tiempo real. Ahí va Temporal, una Lambda directa o código propio.
Si tu equipo no tiene a nadie que pueda leer documentación de APIs y escribir JSON a mano, n8n va a convertirse en deuda técnica rápido. Contrata consultor externo para el build o quédate en plug-and-play hasta que puedas.
Si lo que necesitas es un script one-shot que se corre una vez al mes para migrar datos entre dos sistemas, eso es Python o Node en crontab, no n8n.
Stack que usamos para self-host.
Para clientes que pasan volumen serio, self-host gana a n8n Cloud por costo y control. El stack que repito:
VPS de 4GB de RAM mínimo. DigitalOcean droplet, Hetzner CX21 o un VPS local de proveedor latinoamericano si hay razones de latencia regional. Docker Compose con tres contenedores: n8n oficial, PostgreSQL 15 para persistencia de workflows y ejecuciones, y Redis para colas y memoria conversacional de bots.
Reverse proxy Caddy, que resuelve SSL automático contra Let’s Encrypt y ahorra media tarde de configuración. Dominio propio — nunca la IP cruda — con subdominio dedicado (automation.cliente.com).
Backups: pg_dump diario a las 3am, cifrado, subido a S3 o Backblaze B2. Retención de 30 días.
Monitoreo: Uptime Kuma en otro VPS chico apuntando al endpoint de salud de n8n, con alerta por Telegram si cae más de dos minutos. Complementado con los propios mensajes de error de workflows.
El costo total típico para esta infra, sin contar el tiempo del ingeniero: entre USD 25 y 50 al mes. Ridículamente barato para lo que sostiene.
Cuándo conversamos.
Si tu empresa B2B tiene más de tres sistemas vivos, volumen real de leads y la sensación de que cada nueva integración multiplica el caos, lo que describí arriba es lo que hacemos cada semana. No con plantillas, sino mirando tu stack, tu ERP, tus canales y tu equipo. Hay un formulario corto de diagnóstico de 30 minutos en mis sistemas y los casos documentados en la home. Si tiene sentido trabajar juntos, lo vemos en esa llamada; si no, te dejo el plan escrito igual.