Leads por territorio
Webhook lead → regla territorio → owner CRM → Slack.
Asignación de leads por territorio con n8n: owner por zona. Workflow JSON para CRM comercial en España. Logixb2b España. Para España y la UE. Sin SaaS caro.
Descarga el workflow
JSON listo para importar en n8n (Import from File). Sustituye solo REEMPLAZA_* y credenciales.
Qué resuelve la asignación de leads por territorio
Cuando el equipo comercial se organiza por zonas geográficas, el reparto de leads suele quedar en manos de quien recibe el formulario: mira el código postal a ojo, adivina la provincia y reenvía el contacto a quien cree que le corresponde.
Este flujo automatiza esa parte mecánica del reparto. Recibe el lead por un webhook, cruza el código postal o la provincia contra una tabla de territorios que tú defines, y decide en el momento quién es el propietario: si la zona tiene un único comercial, se lo asigna directamente; si tiene varios, reparte entre ellos con una rotación simple para que no siempre gane el mismo.
Está pensado para funcionar de forma independiente, sin credenciales de CRM: puedes probarlo y usarlo solo con Slack y la respuesta del webhook.
Cuándo conviene automatizar el reparto por zona
Tiene sentido activarlo en cuanto el equipo comercial supera una o dos personas por región y el volumen de leads hace inviable revisar cada formulario a mano para decidir a quién le toca.
Es especialmente útil si más de una fuente genera leads con formato de dirección distinto, un formulario web, una landing de campaña, una integración con un partner, porque el flujo normaliza el dato de código postal o provincia antes de decidir el territorio, en vez de depender de que cada fuente lo mande exactamente igual.
No lo instales tal cual si vuestro criterio de reparto es más complejo que la geografía, por ejemplo, si depende del tamaño de la empresa, del sector o de una combinación de varias señales. En ese caso puedes usar este flujo como base y ampliar el nodo de código con esas reglas adicionales, pero no esperes que un mapa de territorios puro resuelva una lógica de asignación multicriterio.
Importar el flujo y publicar el webhook
Descarga el archivo e impórtalo en n8n desde ⋯ a Import from File.
Copia la URL de producción del nodo Webhook Lead y apúntala desde el origen del lead: el action de tu formulario, la automatización de tu landing o el paso previo de otra herramienta que ya tengas montada. Mientras el flujo esté en modo prueba, usa la URL de test para no mezclar ejecuciones reales con las de configuración.
Antes de nada, sustituye el `slackWebhookUrl` de ejemplo por el webhook entrante real de vuestro canal de ventas, y decide qué valor de `crmMode` corresponde a vuestra herramienta (`hubspot`, `pipedrive` o `generic` si no encaja en ninguna de las dos).
Cómo rellenar el territoryMap sin liarla
El campo `territoryMap` es un texto con formato JSON donde cada clave es un territorio y cada valor es una lista de emails de los comerciales responsables. Puedes usar como clave los dos primeros dígitos del código postal (por ejemplo `"28"` para Madrid capital) o directamente el nombre de la provincia tal y como llega en el formulario (`"Barcelona"`, `"Sevilla"`). El flujo prueba primero por código postal y, si no encuentra nada, por provincia.
Si una zona tiene un solo comercial, pon un único email en el array.
Incluye siempre una clave `_default` con al menos un email; es la que se usa cuando el lead no trae código postal reconocible ni provincia que coincida con ninguna entrada del mapa.
Probar el reparto antes de conectarlo a producción
Envía manualmente un par de peticiones de prueba al webhook con distintos códigos postales: uno que sepas que tiene match directo en tu `territoryMap` y otro inventado que no coincida con nada, para comprobar que cae correctamente en `_default`. Revisa en cada caso el mensaje que llega a Slack y el JSON que devuelve el webhook: ambos deben indicar el mismo propietario y el mismo motivo.
Si configuraste una zona con varios responsables, prueba con dos o tres emails de lead distintos y confirma que el reparto no asigna siempre a la misma persona; no es una rotación estricta por turnos, sino una distribución basada en el email del lead, así que lo relevante es comprobar que varía entre contactos distintos, no que siga un orden fijo.
Aprovecha esta fase para revisar también el payload que genera el Set de CRM.
Poner en marcha y qué revisar la primera semana
Activa el flujo cuando las pruebas te convenzan y conecta el webhook real a la fuente de leads definitiva.
Si detectas que una zona concreta recibe muchos más leads que las demás, es buen momento para añadir un segundo responsable a ese territorio dentro del `territoryMap`, en vez de esperar a que el equipo se queje de la carga desigual. El cambio es literalmente editar una lista dentro de un nodo, sin tocar el resto del flujo.
Cuando quieras dar el salto a actualizar el propietario directamente en el CRM, añade un nodo HTTP Request después del Set de Payload CRM, apuntando al endpoint de tu HubSpot, Pipedrive o CRM interno, con tus credenciales guardadas como credencial de n8n, nunca escritas a mano en el propio flujo.
RGPD, Make/Zapier y límites del reparto automático
El `territoryMap` contiene datos de vuestro propio equipo (emails de comerciales), no de clientes, pero aun así conviene limitar quién puede editar el flujo en n8n.
En Make o Zapier, el equivalente se monta con un webhook de entrada, un módulo de tipo Router o una tabla de búsqueda (Lookup Table) que haga de territoryMap, y una acción de Slack al final.
Este reparto por hash reduce que un mismo comercial reciba siempre los leads de una zona, pero no garantiza un equilibrio perfecto si el volumen es muy bajo; revisa de vez en cuando cuántos leads recibió cada persona y ajusta el mapa si ves una diferencia consistente. Para el contexto completo de esta automatización, consulta el artículo /automatizar-asignacion-leads-territorio-crm.
Importar, configurar y producción 24/7
En n8n: ⋯ → Import from File → el JSON de este recurso. El flujo llega inactive. Abre el sticky INSTRUCCIONES del lienzo y el nodo Config/Set: URLs, umbrales y placeholders. Enlaza credenciales reales (HTTP Header Auth, OAuth Google Sheets, Slack Incoming Webhook, CRM Private App) — nunca dejes tokens en el archivo versionado.
Prueba una ejecución Manual o un evento de test (formulario, webhook, cron forzado). Revisa CRM, Sheets o Slack. Solo entonces Active. Timezone del workflow: Europe/Madrid.
Para que corra solo hace falta n8n online. Self-hosted UE: VPS Hetzner/OVH/IONOS (o panel con Docker) → Ubuntu → Docker Compose (n8n + Postgres) → HTTPS con Caddy/Nginx → N8N_HOST, WEBHOOK_URL, GENERIC_TIMEZONE=Europe/Madrid, N8N_ENCRYPTION_KEY. Alternativa: n8n Cloud (importas, conectas credenciales y Active; vigila límites). Make/Zapier: mismo mapa mental; este JSON es el esqueleto n8n.
EU AI Act y RGPD: qué es y por qué tu empresa debe aplicarlo
El Reglamento (UE) 2024/1689 (EU AI Act) ya está en vigor. Si tu empresa usa n8n con nodos de IA (Gemini, OpenAI, Claude, etc.) en ventas o operaciones, actuáis como desplegadores (deployers): no hace falta ser el fabricante del modelo. Desde el 2 de febrero de 2025 el Artículo 4 exige alfabetización en IA del personal que opera estos sistemas; en agosto de 2026 se refuerza la supervisión (AESIA en España) y la trazabilidad.
En paralelo, el RGPD (AEPD) aplica porque el flujo trata datos de contacto B2B. Base jurídica, minimización y, si hay perfiles automatizados a escala, evaluación de impacto. AI Act y RGPD se acumulan: un fallo puede implicar ambas autoridades.
Este recurso ayuda en la práctica: placeholders sin secretos, Europe/Madrid, opción self-hosted en VPS UE (soberanía de datos), registro de ejecuciones en n8n (logs) y espacio para human-in-the-loop (aprobación antes de acciones sensibles). Detalle: /uso-responsable-de-ia-y-transparencia. Texto informativo, no asesoramiento legal.
Preguntas frecuentes
¿Necesito credenciales de CRM para empezar a usar este flujo?
No. Funciona de forma completa solo con Slack y la respuesta del webhook; la actualización del owner en el CRM es un paso opcional que añades después con tu propio nodo y tus credenciales.
¿Qué pasa si un lead no tiene código postal ni provincia reconocible?
Cae en la clave `_default` del territoryMap, así que siempre debe tener al menos un email configurado para que ningún lead se quede sin propietario.
¿El reparto entre varios comerciales de una misma zona es aleatorio?
No es aleatorio, es determinista: se calcula a partir de un hash del email del lead, así que el mismo contacto siempre cae en la misma persona, pero leads distintos se distribuyen entre todo el equipo de esa zona.
¿Puedo usar nombres de provincia y códigos postales a la vez en el territoryMap?
Sí. El flujo prueba primero por prefijo de código postal y, si no encuentra coincidencia, busca por nombre de provincia, así que puedes combinar ambos criterios en el mismo mapa.
¿Cómo conecto este flujo con HubSpot o Pipedrive de verdad?
El nodo Payload CRM ya genera el JSON con el formato adecuado según el `crmMode` elegido; solo tienes que añadir un nodo HTTP Request con tus credenciales reales apuntando al endpoint de actualización de owner de tu CRM.