CRM y RevOps

Precedencia en el enrutado de leads: al propietario de la cuenta, no al round robin

El campo de propietario de vuestro CRM es un recibo, no un propietario de cuenta. Construid en HubSpot una escalera de precedencia que gane al round robin.

En resumenEnrutad un lead de inbound al propietario de la cuenta con una escalera de precedencia, no comprobando si Contact Owner tiene valor. Primero asociad el contacto a la empresa correcta y después enrutad por deal abierto, cliente, propietario con reunión, territorio, round robin como desempate y una cola de la casa. Registrad qué peldaño se activó en cada asignación.

Oriol Serra21 sep 2026 · 8 min de lectura

Todas las guías de enrutado de leads de internet coinciden en una cosa: cuando un lead de inbound viene de una empresa que un rep ya trabaja, ese rep debería quedárselo. La propiedad de la cuenta gana al round robin. La oportunidad abierta gana al territorio. Bien. Nadie lo discute.

Y luego todo el mundo lo construye mal, porque implementa la regla como «si Contact Owner tiene valor, para». Eso no es enrutar al propietario de la cuenta. Eso es enrutar a quien sea que el CRM haya escrito en un campo, que en la mayoría de portales es el recibo de una inscripción en una secuencia de hace cuatro meses que nunca recibió respuesta.

La asignación es un evento. La propiedad es un estado. La mayoría de portales automatizan el evento y nunca mantienen el estado. Montad una escalera de precedencia sobre un campo de propietario degradado y no habréis arreglado el enrutado. Habréis automatizado la entrega equivocada y la habréis hecho más rápida.

Qué pasa de verdad cuando alguien rellena el formulario

Recorred la secuencia en un portal real. Una VP de Operaciones de una cuenta a la que ya estáis vendiendo rellena un formulario de demo a las 14:02.

HubSpot crea o actualiza el contacto. Salta vuestro workflow de enrutado. Comprueba Contact Owner. Hay un valor, así que se detiene y asigna a ese rep. Hecho en menos de cinco minutos, SLA en verde, dashboard contento.

Hay tres cosas mal en ese resultado, y ninguna aparece en ningún informe que tengáis ahora mismo.

Primero, el propietario de ese campo puede ser un SDR al que el conector de Instantly marcó como propietario del contacto al crearlo hace once semanas. Ese rep mandó tres emails y no recibió nada. Un rep que nunca recibió respuesta no es dueño de un lead. Es dueño de un envío.

Segundo, hay un deal abierto en el registro de la empresa, de otro AE, que ha tenido dos llamadas con el CTO este mes. El lead fue al SDR. El AE se entera cuando el prospect lo menciona en la siguiente llamada.

Tercero, puede que el contacto no tenga ninguna empresa asociada, así que la comprobación a nivel de empresa nunca se ejecutó. Si tenéis desactivada la creación y asociación automática nativa de empresas, como deberíais, cada vía de entrada que no es outbound (formularios, reservas de reunión, creación manual) produce contactos con un dominio de empresa perfectamente válido y sin empresa asociada. Vuestra rama de enrutado por cuenta no tiene nada con lo que hacer match y cae en silencio al round robin.

La precedencia es una escalera, y la barrera va primero

El orden de abajo es el que construimos. Como lista no es nada nuevo. Lo que importa es que cada peldaño lleva una condición de calificación, no solo una comprobación de que hay valor.

Peldaño 0, la clave de cuenta. Antes de que se ejecute ninguna rama, el contacto tiene que estar asociado a la empresa correcta. Un solo workflow se encarga de la asociación de empresa sea cual sea la vía de entrada: inscribid con dominio de empresa válido más tipo de cuenta real más ninguna empresa asociada, buscad por el dominio normalizado, asociad a la empresa canónica si existe, cread una si no existe y retened para revisión manual si el dominio es genérico o compartido. Nunca hagáis match por nombre de empresa. El match por nombre suprime Acme y manda Acme Group SL al round robin.

Si Clay crea empresas en la vía de outbound y un workflow de HubSpot las crea en todas las demás, los dos tienen que compartir la misma normalización de dominio y la misma lógica de selección de la empresa canónica. Si no, no tenéis un modelo de empresas, tenéis dos, y vuestra escalera de enrutado resuelve distinto según la puerta por la que entró el lead.

Peldaño 1, deal abierto. Si la empresa asociada tiene un deal abierto, enrutad al propietario del deal. Es el único peldaño que debería ser casi incondicional. Un deal abierto es una conversación comercial viva con una persona con nombre al otro lado, y meter a un segundo rep en ella es la forma más rápida de perder un deal que ya estabais ganando.

Peldaño 2, cliente. Si la empresa es cliente, enrutad al propietario de la cuenta o al CSM, y marcadlo como expansión y no como negocio nuevo. Los leads self-serve de cuentas que ya son clientes son lo que más a menudo los equipos enrutan como negocio nuevo, y así los ingresos de expansión acaban atribuidos a quien tocara después en la rotación.

Peldaño 3, propiedad de contacto calificada. Aquí es donde la escalera se gana el sueldo. No ramifiquéis por «Contact Owner tiene valor». Ramificad por una propiedad derivada que responda si esa propiedad fue real alguna vez. Nuestra jerarquía: una reunión gana a un intercambio de emails en los dos sentidos, que gana a nada. Un envío en un solo sentido no es, explícitamente, un intercambio. El fallo habitual es ramificar por número de emails enviados, lo que convierte cada inscripción en una secuencia en propiedad de la cuenta.

El orden de construcción importa. Derivad primero «qué rep tuvo la última reunión con alguien de esta empresa» en su propia propiedad, alimentada por la actividad de reunión de HubSpot más vuestra herramienta de grabación, y después ramificad por esa propiedad. Nunca ramifiquéis por actividad en bruto dentro del workflow de enrutado. Ramificar por actividad en bruto es ilegible al cabo de un mes e imposible de probar desde el primer día.

Peldaño 4, territorio. Zona, código postal, región, segmento. Aquí viven la mayoría de modelos industriales y de servicio de campo. En el proyecto de Elesa+Ganter, el propietario por zona y código postal con SLA y escalado funciona a nivel de sede, no de grupo, y esa distinción es estructural: los ingresos suben a la matriz, la supresión sube a la matriz, pero el propietario, el territorio y el SLA no suben. Un registro de grupo no tiene por qué sobrescribir al propietario de territorio de una sede. Si vuestra estructura matriz y filial está metiendo a un propietario de grupo en el peldaño 4, estáis enrutando mal cada cuenta con varias entidades del portal.

Peldaño 5, round robin. El round robin es solo un desempate dentro de un grupo de reps igualmente válidos y disponibles. Nunca es la lógica principal. El round robin como regla de enrutado de primer nivel es un generador de números aleatorios con un relato de equidad pegado encima.

Peldaño 6, la cola de la casa. Algo tiene que recoger lo que no se resuelve. Un único propietario de reserva con nombre, o una cola de la casa con su propio SLA. No un campo de propietario vacío, y no una inscripción silenciosa en la rotación, porque un lead que se cae por un peldaño roto y un lead que de verdad es nuevo no deberían ser indistinguibles en vuestros informes.

Las tres propiedades que lo hacen auditable

Una escalera de precedencia que no se puede auditar es una escalera de precedencia en la que nadie confía, y un modelo de enrutado en el que nadie confía se sobrescribe a mano antes de que acabe el trimestre.

Escribid tres propiedades en cada asignación, sin excepciones:

  • owner_assigned_date
  • owner_assignment_reason
  • previous_owner, copiado antes de sobrescribirlo

owner_assignment_reason es la que importa aquí. Guarda qué peldaño se activó: deal abierto, cliente, propietario con reunión, territorio, round robin, casa. Congelad esos valores como congeláis cualquier conjunto de etiquetas. Una vez definidos, no los redefináis nunca. Añadid los nuevos con nombres nuevos. Si no, nunca podréis leer qué peldaño está cargando de verdad con vuestro enrutado, y no notaréis cuando el peldaño 5 empiece en silencio a llevarse el sesenta por ciento del volumen porque el peldaño 0 se rompió.

Ese último punto es toda la razón para instrumentarlo. Una escalera de enrutado no falla haciendo ruido. Se cuela.

No confundáis los dos relojes

Cinco minutos es el reloj del enrutado. El primer contacto humano es otro reloj, dentro de una hora e idealmente en quince minutos. Los equipos que reportan un solo número casi siempre reportan el reloj del enrutado, porque es el que controla la automatización, y luego se preguntan por qué las mejoras en speed-to-lead no han generado pipeline.

Imponed el segundo reloj con automatización, nunca con la vigilancia del rep. Si un lead enrutado sigue sin tocar dentro de la ventana del SLA, avisad al manager y reenrutad. Si no pasa nada en veinticuatro horas, escalad. Poned marca de tiempo a cada asignación para que «no vi ese» se convierta en un evento medible en lugar de un encogimiento de hombros.

Dónde os va a plantar cara HubSpot

Dos limitaciones honestas, para que dimensionéis esto bien.

HubSpot detecta duplicados por la propiedad de email y el ID interno del registro, no expone ninguna lógica de match personalizada y no avisa a los reps al crear a mano. HubSpot no tiene un problema de duplicados, tiene un problema de match que no os deja arreglar. Por eso el peldaño 0 vive en un workflow y en vuestra capa de enrichment, aguas arriba, no en la herramienta de fusión.

Y la ramificación nativa de workflows es un árbol de decisión, no un clasificador. Aguanta bien unas veinte ramas de «contiene». Una escalera de seis peldaños está muy por debajo de eso. Una escalera de seis peldaños cruzada con catorce territorios y cuatro segmentos no lo está, y ese es el punto en que la lógica tiene que ir a una acción de código personalizado con las reglas guardadas fuera del código, no en un lienzo que nadie puede leer.

Haced esta auditoría antes de construir nada

Cuatro filtros, quince minutos, en vuestro propio portal:

  1. Contactos creados en los últimos noventa días con dominio de empresa y sin empresa asociada. Ese es el peldaño 0 perdiendo agua.
  2. Contact Owner tiene valor Y última actividad hace más de noventa días Y sin deal abierto Y no es cliente. Ese es vuestro número de propiedad caducada, y su sitio está en el mismo dashboard que vuestro informe de rendimiento de reps. Si sube, vuestra lógica de reasignación no está funcionando.
  3. Envíos de formularios de inbound del último trimestre en los que la empresa asociada tenía un deal abierto de otro rep en el momento del envío. Cada uno de ellos es un enrutado equivocado que ya habéis pagado.
  4. Deals creados en los dos últimos trimestres en empresas que ya eran clientes, agrupados por propietario. Si la expansión está cayendo en reps de negocio nuevo, el peldaño 2 no existe.

A la mayoría de equipos el tercer filtro les resulta incómodo. Suele ser el que paga la reconstrucción por sí solo, porque el coste de un enrutado equivocado no es una respuesta lenta, es un segundo rep entrando en un deal vivo.

No necesitáis otra herramienta de enrutado

Los proveedores que venden match de lead a cuenta resuelven el peldaño 0 y os cobran por los peldaños 1 a 6, que son una decisión que tenéis que tomar igualmente y que ninguna herramienta puede tomar por vosotros. Lo que necesitáis es un orden de precedencia por escrito, una clave de cuenta en la que confiéis y un campo de propietario que refleje quién trabajó de verdad la cuenta y no quién la inscribió una vez.

Esa reconstrucción es lo que instala nuestro módulo Lead Scoring & Routing Engine: encaje e intención puntuados como dos números separados, la escalera de precedencia construida y documentada, el SLA impuesto por automatización y el rastro de auditoría conectado para que podáis demostrar qué peldaño se activó. Si preferís conocer primero el tamaño del problema, los cuatro filtros de arriba os dirán casi todo en una tarde.