La mayoría de los portales de HubSpot rutan leads de la misma manera: un Workflow masivo, una docena de ramas if/then anidadas, una acción "Rotate record to owner", una notificación de email genérica y una oración. Funciona hasta que alcanza unos 10 comerciales y 3 territorios. Después se rompe, en silencio, de forma costosa y de maneras que no aparecen en ningún dashboard.
El problema no es el utillaje de HubSpot. Las primitivas son sólidas. El problema es la arquitectura. Los equipos tratan el routing como una configuración puntual cuando en realidad es un sistema que necesita clasificación, asignación, aplicación y medición, cada una como una preocupación independiente.
Esta guía explica cómo construir un routing de leads en HubSpot que sobreviva a su próxima reorganización.
Qué significa realmente "Lead Routing" en HubSpot
Antes de construir nada, tenga claro qué objeto está rutando. HubSpot usa "lead" de forma imprecisa, y eso importa:
- Contacts: el destino de routing más habitual para inbound. Está estableciendo el Contact Owner.
- Objeto Leads: usado en el Sales Workspace para el seguimiento de la calificación. Requiere Sales Hub Professional o Enterprise.
- Tickets: para routing de soporte, con herramientas nativas más ricas de equilibrio de capacidad.
Cada uno tiene propiedades de owner distintas, tipos de Workflow distintos y reporting distinto. Si su Workflow de routing establece el campo de owner equivocado, su atribución y sus métricas SLA están equivocadas desde el primer día.
Cinco cosas que el routing debe hacer
La asignación es la parte fácil. Un sistema de routing que realmente funciona se ocupa de cinco cosas:
1. Speed-to-lead. HubSpot mide el tiempo de respuesta a leads como la diferencia entre la asignación y el primer contacto (email, llamada, reunión, finalización de tarea). El routing no termina cuando se establece un owner: termina cuando ocurre el primer contacto.
2. Encaje y especialización. El comercial equivocado en el deal equivocado crea seguimiento lento y baja conversión. Rute por territorio, interés de producto, tamaño de empresa, score, lo que se ajuste a su motion de venta.
3. Distribución justa. El round-robin parece simple hasta que la rotación se reinicia porque añadió un comercial. Más sobre esto abajo.
4. Claridad de propiedad. Las disputas "¿de quién es esto?" matan deals. La asignación automatizada basada en reglas elimina la ambigüedad.
5. Medibilidad. Si no puede medir el rendimiento del routing, no puede mejorarlo. HubSpot le da analítica de Workflow, tiempo de respuesta a leads y la propiedad Contact unworked?. Use las tres.
El antipatrón del mega-Workflow
Esto es lo que se rompe a escala: un Workflow intenta hacer todo. Clasificación, mapeo de territorios, round-robin, notificación, monitorización de SLA, todo en un único flujo con más de 15 ramas anidadas.
Los modos de fallo son predecibles:
- Añadir un nuevo territorio implica editar un Workflow en producción que rutea todos sus ingresos
- Un error en la lógica de una rama envía silenciosamente leads a nadie
- Sin aplicación de SLA, solo una notificación genérica de email que los comerciales ignoran
- Sin catch-all para los registros que no encajan en ninguna rama
- Las nuevas incorporaciones tienen miedo de tocarlo porque nadie ha documentado la lógica
La solución: routing modular. Tres Workflow, cada uno con un único trabajo.
La arquitectura de tres Workflow
Workflow 1: Clasificación
Normaliza los datos de entrada y establece propiedades de routing. Aquí no se realiza ninguna asignación.
- Se dispara al enviar un formulario, crear vía API o importar
- Establece Territory code según país/estado/región
- Establece Sales segment (SMB, Mid-Market, Enterprise) según número de empleados o ingresos
- Establece Product interest a partir de campos de formulario o URL de página
- Establece Routing status en
new
Check branches in order: US: NY, NJ, PA, MA, CT, VA..., US: CA, WA, OR, CO, TX, AZ..., UK, DE, FR, NL, CH, AT..., AU, NZ, SG, JP, KR, IN..., and None met.
Check branches in order: Is less than 50, Is between 50 and 500, Is greater than 500, and None met.
Set Routing status to new
Este Workflow existe para que su lógica de asignación no necesite 20 ramas para descubrir quién es un lead. Lee datos de entrada desordenados y escribe campos de routing limpios.
Workflow 2: Asignación
Lee las propiedades de routing limpias y asigna un owner. Es el único Workflow que toca el Contact Owner.
- Se dispara cuando Routing status =
new - Primera rama: ¿Tiene este contacto ya un owner? Si sí, omitir rotación. La tarea posterior a la rama de primer contacto gestiona el seguimiento
- Segunda rama: ¿Hay una empresa asociada con un owner? Si sí, asignar al owner de la empresa (routing por cuenta)
- Tercera rama: Routear por Territory code usando ramas value-equals, con una acción "Rotate record to owner" por equipo de territorio
- Rama catch-all: Rotar a un pool global de SDR
- Establece Routing status en
routed, Routing timestamp en ahora - Crea una tarea de seguimiento: "Primer contacto en 15 minutos"
- Envía una notificación de Slack o email
Check branches in order: Contact owner is known, Associated company owner is known, Territory code is US-EAST, Territory code is US-WEST, Territory code is EMEA, Territory code is APAC-ANZ, and None met.
Set Routing status to routed
Set Routing timestamp to now
Create task First-touch within 15 minutes
Send Slack notification to #new-leads channel
Workflow 3: Aplicación de SLA
Monitoriza si los leads asignados realmente se están trabajando. Es el Workflow que la mayoría de equipos omiten, y el que más importa.
- Se dispara cuando Routing status =
routed - Retraso de 15 minutos (o su umbral SLA)
- Comprueba Contact unworked?: esta propiedad de HubSpot por defecto es
truecuando no se ha registrado actividad de ventas desde la última asignación de owner - Si está sin trabajar: crea una tarea de escalado, notifica al manager
- Opcional: retrasar otros 45 minutos, comprobar de nuevo, después reasignar a un pool de respaldo
Wait 15 minutes
Check branches in order: Contact unworked? is Yes and Contact was worked.
Sin este Workflow, tiene asignación. No tiene routing.
Configurar su modelo de datos
Antes de construir workflows, cree estas propiedades de contacto:
| Propiedad | Tipo | Valores |
|---|---|---|
| Routing status | Desplegable | new, routed, reassigned, needs_review, do_not_route |
| Routing reason | Desplegable | territory_match, round_robin, account_match, high_score, manual_override, missing_data |
| Territory code | Desplegable | Sus territorios (p. ej., US-EAST, US-WEST, EMEA, APAC-ANZ) |
| Sales segment | Desplegable | SMB, Mid-Market, Enterprise |
| Routing timestamp | Fecha-hora | Se establece cuando se asigna la propiedad |
Estas propiedades cumplen dos propósitos: controlan la ramificación de los Workflow y alimentan los informes de routing. Sin ellas, depura el routing leyendo el historial de inscripciones a Workflow, lo cual es horrible.
Importante: Las reglas de validación de propiedades de HubSpot no se aplican cuando los valores se establecen vía Workflow. Construya sus comprobaciones defensivas dentro de las ramas del Workflow, no en las reglas de validación.
"Rotate Record to Owner": lo que necesita saber
Esta es la primitiva round-robin de HubSpot, y tiene comportamientos que hacen tropezar a casi todos los equipos:
La rotación es por acción, no global. Cada acción "Rotate record to owner" mantiene su propio contador. Si tiene dos acciones de rotación en distintos Workflow, siguen la distribución de forma independiente. Un comercial puede recibir 5 leads de una acción y 0 de la otra.
Añadir o eliminar comerciales reinicia la rotación. Si cambia el pool de owners en un Workflow en producción, el orden establecido se reinicia y la distribución vuelve a ser aleatoria. Trate los pools de rotación como configuración estable. No los edite a la ligera.
Solo se incluyen los miembros principales del equipo. Si un comercial es un miembro "extra" de un equipo, no recibirá leads rotados. Solo cuenta la pertenencia principal al equipo.
Requiere Sales Hub o Service Hub Professional+. Y solo los usuarios activados y de pago pueden recibir asignaciones rotadas.
Los usuarios desactivados se omiten silenciosamente. Cuando alguien se va y su cuenta se desactiva, la acción de rotación simplemente lo omite. Sin error, sin alerta. Añada "eliminar de los pools de routing" a su checklist de offboarding.
Routing por territorio sin un módulo de territorio
HubSpot no tiene un objeto Territory nativo. Lo que la mayoría de equipos llama "routing por territorio" es un patrón que usted construye:
- Defina territorios como valores desplegables en una Custom Property (p. ej., Territory code)
- Use su Workflow de Clasificación para establecer el territorio según geografía, tamaño de empresa o sector
- En su Workflow de Asignación, use ramas value-equals sobre Territory code: admiten hasta 250 ramas, generadas automáticamente a partir de una sola propiedad
- Cada rama rutea a un pool de rotación específico de territorio
Esto funciona bien. La disciplina clave: estandarizar en un único campo de routing. No ramifique por país Y estado Y región en una lógica if/then anidada. Normalice todo a un solo código de territorio primero, luego ramifique una vez.
Routing basado en cuentas: comprobar antes de rotar
Si un AE senior ha pasado meses cultivando una cuenta enterprise, rutar un nuevo lead inbound de esa empresa a un SDR aleatorio es un desastre. Conflicto de canal, prospección duplicada y un AE muy descontento.
Su Workflow de Asignación debe comprobar siempre la propiedad existente antes del round-robin:
- ¿El contacto ya tiene owner? Rutar al owner existente.
- ¿Hay una empresa asociada con un owner? Rutar al owner de la empresa.
- Solo entonces caer al round-robin.
Para jerarquías corporativas complejas con múltiples filiales y dominios, el matching nativo de HubSpot puede no ser suficiente. Aquí es donde entran herramientas de terceros como 0CodeTools o acciones de código personalizado, pero ponga primero la comprobación básica.
Lead Scoring como entrada de routing
Un lead score solo es útil si pasa algo cuando cruza un umbral. El fallo más habitual: los equipos construyen un modelo de scoring, fijan un umbral en 80 puntos y... nada. Ningún Workflow se dispara. Ningún owner se asigna. La brecha "puntuado pero sin owner" es donde el pipeline va a morir.
Qué construir:
- El score cruza su umbral MQL → disparar su Workflow de Asignación (establecer Routing status en
new) - Los leads de score alto reciben un SLA más corto (5 minutos en lugar de 15)
- Añada decaimiento temporal a sus criterios de scoring: "página de precios visitada en los últimos 7 días" importa más que "página de precios visitada hace 6 meses"
El modelo de scoring actual de HubSpot usa scores Fit y Engagement separados con propiedades de umbral (Low, Medium, High) en lugar de valores de puntos brutos. Use estos umbrales como triggers de inscripción para sus Workflow de routing.
El problema de la sincronización con Salesforce
Si ejecuta HubSpot y Salesforce juntos, la sincronización de propiedad es donde el routing se rompe.
El problema central: Cuando HubSpot establece un contact owner vía "Rotate record to owner", el cambio se sincroniza con Salesforce. Pero las reglas de asignación de Salesforce pueden dispararse en la creación de un nuevo lead y sobrescribir el owner, lo que después se sincroniza de vuelta a HubSpot y deshace su routing.
La solución: Elija un sistema como owner of truth para la asignación. Si HubSpot rutea leads, deshabilite las reglas de asignación de Salesforce para los registros creados en HubSpot. Si rutea Salesforce, no use las acciones de rotación de HubSpot.
HubSpot sincroniza las propiedades de owner por dirección de email (o por nombre si falta el email). Ambos usuarios deben existir en ambos sistemas o la sincronización falla silenciosamente. Audite esto regularmente.
Routing fuera de horario
Los ajustes de Workflow de HubSpot le permiten restringir la ejecución de acciones a ventanas horarias específicas. Los registros que alcancen una acción fuera de esas horas se reprograman al siguiente periodo disponible.
Esto es más limpio que construir ramas complejas de comprobación de horario. Pero conozca el matiz: los registros pueden seguir inscribiéndose y pasar por retrasos y ramas en días pausados, solo se pausan en el siguiente paso de acción. Tenga esto en cuenta en sus cálculos de SLA.
Modos de fallo a anticipar
| Fallo | Qué ocurre | Solución |
|---|---|---|
| Sin rama catch-all | Los leads que no encajan en ningún territorio quedan sin rutar para siempre | Termine siempre con una rama "None met" que asigne a un pool de respaldo y alerte a ops |
| Owner sobrescrito al reenviar el formulario | Los clientes existentes son reasignados a un SDR aleatorio | Ramifique primero: si el owner existe, no rotar |
| Datos malos impiden el routing | País vacío o sector mal escrito = sin coincidencia de territorio | Exija campos mínimos de routing en formularios; normalice en el Workflow de Clasificación |
| La reinscripción no se dispara | El contacto fue inscrito previamente y la reinscripción no está habilitada | Habilite triggers de reinscripción en los Workflow de Asignación y SLA |
| Scores altos obsoletos | Los leads puntuados hace 6 meses atascan la cola de alta prioridad | Use criterios de scoring con ventanas temporales para que los scores decaigan de forma natural |
Qué medir
Construya un dashboard de routing con cuatro secciones:
Salud del routing: total de routed en los últimos 7 días, % aterrizando en la rama catch-all (indicador de datos malos), número de errores de Workflow.
Velocidad y SLA: distribución del tiempo de respuesta a leads (p50 y p90), backlog sin trabajar por antigüedad usando la propiedad Contact unworked?.
Distribución y equidad: leads asignados por comercial y por territorio. Si un comercial tiene 3x el volumen de otro, su pool de rotación está mal configurado.
Calidad y resultados: tasa de conversión de routed a SQL, tiempo a reunión, tasa de entrada en pipeline. Esto le dice si el routing está enviando los leads correctos a los comerciales correctos.
El generador de informes personalizados de HubSpot y la suite de analítica de ventas cubren todo esto. Los informes se actualizan cada dos horas con actualización manual disponible.
La ruta de migración
Si está leyendo esto con un mega-Workflow ya en producción, no reconstruya todo a la vez.
- Auditoría. Mapee cada Workflow relacionado con routing. Use las herramientas de organización de Workflow de HubSpot: carpetas, filtros, vistas "Needs review" y "Unused".
- Construya primero el modelo de datos. Cree sus propiedades de routing y empiece a poblarlas manualmente o vía un Workflow ligero. Esto le da datos para probar.
- Construya los Workflow de Clasificación y SLA junto al routing existente. No tocan la propiedad, así que no hay conflicto.
- Cambie la Asignación. Una vez que la Clasificación esté poblando campos de routing limpios, construya su nuevo Workflow modular de Asignación. Pruebe con registros ficticios en cada territorio y segmento. Solo entonces apague el viejo mega-Workflow.
- Monitorice durante dos semanas. Vigile el volumen de la rama catch-all, el backlog sin trabajar y la distribución de razones de routing. Ajuste los mapeos de territorio y los pools de rotación según datos reales.
Referencia rápida: lo que necesita por nivel de HubSpot
| Lo que necesita | Nivel requerido |
|---|---|
| Workflow (inscripción, ramas, retrasos) | Professional o Enterprise (cualquier Hub) |
| "Rotate record to owner" | Sales Hub o Service Hub Professional+ |
| Ramas value-equals (hasta 250) | Professional o Enterprise |
| Acciones de código personalizado de Workflow | Operations Hub Professional o Enterprise |
| Lead Scoring | Marketing Hub Professional o Enterprise |
| Sales analytics (tiempo de respuesta a leads) | Sales Hub Professional o Enterprise |
| Equipos anidados | Enterprise (cualquier Hub) |
Constrúyalo bien la primera vez
El lead routing no es un Workflow: es un sistema. La clasificación, asignación, aplicación y medición necesitan cada una su propio Workflow, sus propias propiedades y su propio dashboard.
Los equipos que lo hacen bien no se limitan a rutar leads más rápido. Eliminan disputas de propiedad, aplican SLAs automáticamente y tienen los datos para demostrar qué funciona. Los equipos que no lo hacen acaban con un mega-Workflow que nadie quiere tocar y un canal de Slack lleno de mensajes de "¿de quién es este lead?".
Empiece con la arquitectura de tres Workflow. Añada propiedades de routing. Construya el Workflow de SLA. Mida todo.
¿Necesita un punto de partida más rápido? Nuestra biblioteca gratuita de plantillas de Workflow incluye plantillas listas para instalar para auto-asociación de contactos a deals, actualizaciones de etapa del ciclo de vida del lead y escalado de SLA.
Si necesita ayuda diseñando o implementando el lead routing en su portal de HubSpot, conozca nuestro soporte RevOps o hable directamente con nuestro equipo.
Guías relacionadas de Workflow de HubSpot
- Establecer un TTL para registros de HubSpot: encaja de forma natural con el Workflow de aplicación de SLA de arriba. Una vez que un lead incumple su SLA y envejece más allá de la ventana de recuperación, el TTL se ocupa de la limpieza.
- Retraso aleatorio y asociaciones en 0CodeTools: cuando la asignación round-robin se dispara para muchos leads a la vez, los retrasos aleatorios evitan problemas de rate-limit con notificaciones posteriores y acciones de Slack/email.
- Campos de Lookup en HubSpot: la guía definitiva: para routing basado en territorio que mapea un contacto a un owner de cuenta específico vía una propiedad de Lookup, en lugar de hacer malabares con la pertenencia a equipos.
- Plantillas gratuitas de Workflow de HubSpot: instale plantillas listas para usar para Auto-Assign Contact Owner, Set Lead Status on Form Submit, Update Lifecycle Stage to MQL, Reactivate Disqualified Leads y Disqualify Unresponsive Leads.