En HubSpot (2025), ¿cómo puedo auditar si mi lead scoring y

Respuesta

Audítalo desde el rastro, no desde la teoría: toma una muestra de MQL y SQL recientes, mira el historial de propiedades de Lifecycle Stage y del score, y localiza qué workflow, usuario o integración escribió cada cambio. En paralelo, crea listas de “anomalías” como MQL sin actividad o SQL sin deal para encontrar falsos positivos en minutos. Después, elimina infladores del scoring, corta reentradas peligrosas y define una única autoridad para cambiar etapas. Si lo haces en este orden, dejas de discutir definiciones y empiezas a ver causas concretas.

Define el problema: qué es un MQL/SQL falso y cómo se manifiesta Un MQL falso no es solo un lead “malo”. Es un contacto que HubSpot etiqueta como MQL por reglas que no representan intención real o encaje, o por automatizaciones que empujan etapas sin que haya señales humanas o comerciales detrás. Un SQL falso es la misma película con otro actor: aparece como SQL aunque ventas no lo haya aceptado, no exista un deal, no haya actividad o el lead sea un cliente existente reciclado por la automatización.

En la práctica se manifiesta con síntomas medibles. Ves picos de MQL sin que suban las oportunidades, cae la conversión MQL a SQL, y empiezan los “SQL fantasma” que no tienen owner claro o no generan seguimiento. También aparece el clásico carrusel de etapas: el Lifecycle Stage cambia varias veces en pocos días, como si el contacto estuviera jugando al ascensor.

Si quieres un diagnóstico rápido, quédate con 4 señales base. Primero, tasa de conversión MQL a SQL y SQL a oportunidad por cohorte semanal. Segundo, porcentaje de MQL con cero actividades de ventas en X días. Tercero, porcentaje de SQL sin deal asociado o sin owner. Cuarto, tiempo medio desde “Became a MQL” a primera actividad de ventas. Cuando esas métricas se rompen, casi siempre hay automatización escribiendo donde no debería y scoring premiando acciones baratas.

Preparar trazabilidad: propiedades y auditoría mínima antes de tocar nada Antes de cambiar reglas, asegúrate de que puedes reconstruir la historia de un lead sin adivinar. En HubSpot, la clave es usar el historial de propiedades y el timeline para ver quién cambió qué y cuándo. La auditoría mínima se apoya en estas propiedades, o sus equivalentes en tu portal: Lifecycle Stage, Lead Score o scores de HubSpot si usas el nuevo modelo, Lead Status si lo trabajas como estado operativo, Create date, Original source con detalle de UTM, Owner, y las fechas tipo “Became a lead”, “Became a MQL”, “Became a SQL” si están disponibles.

A partir de ahí, crea trazabilidad adicional con dos objetivos: saber el motivo del salto y saber el sistema que lo provocó. En muchos portales, el problema no es que el scoring sea malo, es que nadie puede explicar por qué alguien “se volvió MQL” sin abrir cinco pestañas.

Te recomiendo añadir propiedades auxiliares simples, aunque sean temporales durante la auditoría. “MQL reason” como texto o selección con 8 a 12 motivos típicos. “MQL source workflow” para guardar el nombre del workflow que lo promovió. “Scoring version” para saber qué versión de reglas estaba activa. “Last lifecycle change source” con valores como usuario, workflow, integración, importación. No es glamour, es trazabilidad.

Tip práctico 1: antes de hacer cambios masivos, exporta una muestra representativa de contactos y guarda un snapshot de estas propiedades. En soporte lo llamamos paracaídas: ojalá no lo uses, pero si lo necesitas te salva.

Muestreo inteligente: cómo encontrar ejemplos de falsos MQL/SQL en minutos No empieces revisando todos los workflows. Empieza encontrando ejemplos claros y repetibles, porque esos ejemplos te dirán qué automatización buscar. La forma más rápida es crear listas activas de anomalías y abrir 10 contactos de cada lista para revisar su timeline.

Aquí tienes un set de listas que casi siempre encuentran “falsos” rápido, adaptando los filtros a tus campos:

MQL en los últimos 30 días con cero actividades de ventas o cero tareas creadas.
SQL actuales sin deal asociado o con deal vacío de actividad reciente.
Contactos cuyo Lifecycle Stage cambió más de 2 veces en 14 días.
Contactos cuyo score subió más de X puntos en 24 horas.
MQL creados por importación o API que se vuelven MQL en menos de 5 minutos desde Create date.
MQL con email personal si tu ICP normalmente usa dominios corporativos.
SQL que provienen de una fuente de campaña concreta donde históricamente no hay intención, por ejemplo un sorteo o un descargable de bajo valor.

Cuando abras el timeline, busca tres cosas: el evento exacto que antecede al cambio de etapa, la automatización que se ejecuta a continuación, y si hay señales de intención reales como visita a página de precios, solicitud de demo, respuesta a secuencia o interacción con playbooks.

Tip práctico 2: añade una columna en la vista de lista con “Create date”, “Original source” y “Latest source”. Muchos falsos MQL son “reciclados” y te engañan porque el contacto es antiguo pero acaba de reactivar un disparador barato.

Auditoría de Lifecycle Stages: quién los cambia y por qué El Lifecycle Stage debería ser una señal de negocio, no un campo que cualquiera escribe “porque sí”. La auditoría empieza en el historial de la propiedad Lifecycle Stage de una muestra de falsos MQL y SQL. Tu objetivo es etiquetar cada cambio en una de estas categorías: cambio manual por usuario, cambio por workflow, cambio por integración, o cambio por importación.

Luego haces el mapa de escritores. Lista todos los workflows que tengan acciones tipo “set property value” sobre Lifecycle Stage, en contactos, empresas y deals. Revisa también herramientas de ventas como playbooks, porque pueden empujar campos operativos y, si están mal diseñados, mover etapas sin intención. En la comunidad de HubSpot se habla bastante de cómo organizar listas, scoring y workflows, y esa conversación suele revelar el patrón: varios equipos automatizan la misma propiedad sin una autoridad clara.

La regla operativa que recomiendo: una sola “autoridad” por etapa. Por ejemplo, marketing puede promover a MQL con criterios acordados, ventas promueve a SQL cuando hay aceptación, y customer success no toca Lifecycle Stage sino un estado de cliente separado. Si hoy tienes dos workflows que ponen MQL, uno por score y otro por formulario, ya tienes una lotería.

Error común: permitir que el Lifecycle Stage retroceda o se “reseteé” automáticamente cuando un lead se desuscribe, se recicla o cambia de owner. En lugar de eso, mantén Lifecycle Stage como historial de relación y usa Lead Status, pipeline stage del deal o una propiedad “Recycling status” para la operativa. Si necesitas volver a calificar, hazlo con un proceso explícito, no con un reseteo silencioso.

Auditoría del scoring: detectar infladores y señales duplicadas El scoring falla por dos motivos típicos. Primero, infladores, que son acciones que suman muchos puntos con poco significado, como aperturas de email o visitas repetidas a contenido genérico. Segundo, duplicación, cuando la misma intención se premia varias veces por rutas distintas, por ejemplo un formulario que añade puntos y además inscribe en un workflow que añade más puntos por la misma conversión.

Revisa tus reglas de scoring separando fit e intent. Fit es firmográfico y de perfil: industria, tamaño, cargo, país, tecnología. Intent es comportamiento que sugiere compra: demo, pricing, comparativas, respuesta a ventas, alto engagement en páginas de solución. Si mezclas ambos en un único número sin límites, el score se vuelve una piñata: cualquiera le pega y caen puntos.

Busca estos infladores concretos. Primero, puntos por interacción pasiva como abrir emails. Segundo, puntos por acciones repetibles sin límite, como descargar cinco veces el mismo recurso. Tercero, puntos por páginas de blog que atraen estudiantes, competencia o curiosos. Cuarto, eventos duplicados de integraciones, por ejemplo cuando una herramienta manda el mismo evento con diferente nombre.

Un buen arreglo rápido es poner techos por ventana temporal. Por ejemplo, una conversión de formulario suma puntos una vez cada 30 días, o visitas a una página clave suman hasta un máximo semanal. Si tu versión de HubSpot lo permite, incorpora decaimiento para que el score refleje recencia, no solo acumulación histórica. Si no, simúlalo con reglas que resten puntos cuando no hay actividad relevante en 30 o 60 días.

Dato operativo: el lead scoring predictivo puede ayudar a priorizar, pero incluso ahí necesitas higiene de datos y definiciones alineadas, porque el modelo aprende de tus resultados históricos. Si tu histórico está inflado con MQL falsos, el modelo aprende a amar el ruido.

Workflows: reentrada, loops y condiciones mal planteadas Los falsos MQL y SQL por automatización casi siempre vienen de tres patrones.

El primero es reentrada sin control. Un workflow que promueve a MQL cada vez que el score cruza un umbral, pero el mismo workflow o uno paralelo también modifica el score, provoca inscripciones repetidas. El resultado es un contacto que entra, sale, vuelve a entrar, y cada vuelta genera más acciones y más puntos.

El segundo es el loop de condición. El disparador es “propiedad A tiene valor X” y el propio workflow fija A en X como parte de su lógica. Eso es como dejar el grifo abierto y preguntarte por qué sube la factura del agua.

El tercero es la falta de exclusiones: clientes existentes, contactos con deals abiertos, o leads descalificados que vuelven a recibir promoción por una actividad menor.

Audita con dos acciones simples. Primero, abre el historial de inscripciones de un contacto falso y mira si aparece “enrolled multiple times” o inscripciones repetidas. Segundo, usa la función de test del workflow con un contacto real para ver qué ramas dispara, sobre todo cuando hay múltiples criterios.

Mitigaciones típicas que funcionan sin complicarte. Usa un flag tipo “Already promoted to MQL” con fecha, y bloquea reentradas durante una ventana. Añade supresión por Lifecycle Stage y por “Customer” si aplica. Y si el workflow toca scoring y Lifecycle Stage, separa responsabilidades: un workflow calcula score, otro decide etapa, y se comunican por una propiedad puente.

Integraciones (Salesforce, ERP, otros): sobreescrituras y desalineación de definiciones Si tienes sincronización con Salesforce o un ERP, asume que parte de tus falsos MQL y SQL vienen de colisiones de definición. El clásico: HubSpot marca MQL por marketing, Salesforce baja el lead a un estado operativo, y HubSpot lo vuelve a subir porque el score sigue alto. O al revés: Salesforce marca SQL por un campo de lead status, pero en HubSpot no hay actividad real.

Haz tres preguntas y documenta respuestas. Primera, cuál es el sistema de verdad para Lifecycle Stage y para Lead Status. Segunda, qué campos son bidireccionales y cuáles solo deben ir en un sentido. Tercera, qué pasa con un contacto que ya es cliente y vuelve a llenar un formulario.

En la auditoría, revisa en el historial de propiedad si puedes inferir origen externo, y cruza con timestamps de sincronización. Si no tienes visibilidad de origen, usa una propiedad puente: por ejemplo “External lifecycle” y luego un workflow que traduzca solo en situaciones permitidas. Es menos elegante, pero evita la guerra de sobrescrituras.

Medir el impacto en reporting: dónde se nota el sesgo y cómo cuantificarlo El sesgo se nota donde duele: en el embudo y en la confianza del equipo comercial. Para cuantificarlo, trabaja por cohortes. MQL creados por semana, y su conversión a SQL, oportunidad y ganado. Segmenta por ruta de creación: manual, workflow, importación, API, integración. Segmenta también por fuente: orgánico, paid, referidos, campañas específicas.

Mide cuatro ratios útiles. Primero, porcentaje de MQL que llegan a SQL en 14 o 30 días. Segundo, porcentaje de SQL que tienen deal creado en 7 días. Tercero, tasa de descalificación o closed lost temprano, que suele subir cuando hay falsos. Cuarto, tiempo a primera actividad de ventas desde MQL.

Antes de corregir, fija un baseline de al menos 4 a 8 semanas. Si cambias scoring y etapas sin baseline, luego nadie sabrá si mejoraste o solo moviste la alfombra.

Priorizar correcciones: quick wins vs rediseño (matriz esfuerzo, impacto) Prioriza como operador, no como perfeccionista. El impacto más alto suele venir de frenar escrituras conflictivas y reentradas, no de afinar si una visita vale 3 o 5 puntos.

Quick wins típicos. Primero, detener que múltiples workflows escriban Lifecycle Stage y dejar solo uno por etapa o un solo orquestador. Segundo, añadir exclusiones para clientes, deals abiertos y leads descalificados. Tercero, poner límites a reglas de scoring repetibles y quitar puntos a señales pasivas.

Rediseños que valen la pena si el negocio ya está maduro. Separar score de fit y score de intent con dos propiedades distintas. Versionar el scoring para poder comparar antes y después. Rehacer la definición de SQL para que dependa de aceptación de ventas, no solo de umbral numérico.

Una matriz simple: alto impacto y bajo esfuerzo primero, alto impacto y alto esfuerzo después, bajo impacto y bajo esfuerzo solo si reduce ruido, y bajo impacto y alto esfuerzo normalmente se descarta.

Guardrails permanentes: diseño para que no vuelva a pasar Los guardrails son reglas de seguridad para que un error pequeño no se convierta en un incendio. El objetivo es que HubSpot sea difícil de romper incluso cuando alguien crea un workflow nuevo con buenas intenciones.

Empieza por una matriz de autoridad: quién puede promover a MQL, quién puede promover a SQL, y en qué condiciones. Asegura que los cambios de etapa solo avancen, salvo excepciones explícitas revisadas. Documenta la definición operativa de MQL y SQL en una nota interna y en los nombres de workflows, porque la memoria de equipo dura menos que un café en reunión de pipeline.

Añade monitoreo continuo con listas activas. MQL sin actividad, SQL sin deal, cambios de etapa múltiples, score con saltos grandes, y contactos creados por importación que se vuelven MQL enseguida. Revisa esas listas semanalmente 15 minutos. Es un hábito pequeño que evita meses de ruido.

Si usas playbooks, aprovecha propiedades condicionales para guiar a ventas a capturar datos mínimos y reducir promociones prematuras. Si no hay datos críticos, no se promueve. Es la versión CRM de “no hay postre si no comes verduras”.

Aquí tienes los controles clave en una tabla para amarrar el sistema.

Set: Propiedad 'Lifecycle Stage' define quién tiene la pluma cuando se cambian etapas. Set: Reglas de Lead Scoring evita que el score se convierta en una máquina de puntos gratis. Set: Workflows de cambio de etapa corta reentradas, loops y saltos de etapa. Set: Integraciones externas (ej. CRM, ERP) previene sobrescrituras y guerras de definiciones.

Para cerrar con una recomendación clara: primero aclara y estandariza quién cambia Lifecycle Stage y en qué condiciones. Luego simplifica el scoring quitando infladores y duplicados, y por último coloca guardrails con listas de monitoreo y exclusiones. Cuando eso está bien, el reporting deja de ser una novela de misterio y vuelve a ser un tablero de control.

Control	Dónde vive	Qué configurar	Qué se rompe si está mal
Set: Propiedad 'Lifecycle Stage'	Configuración de propiedades > Contactos/Empresas	Mapear todas las automatizaciones que la modifican. Definir una única fuente de verdad por etapa.	Falsos positivos / negativos de MQL / SQL. Equipos de ventas contactan leads no cualificados.
Set: Reglas de Lead Scoring	Configuración > Propiedades > Lead Scoring	Revisar puntos por acciones de bajo valor — ej. abrir email. Implementar decaimiento de puntos.	Inflación de scores. Leads con alta puntuación pero sin intención real de compra.
Set: Workflows de cambio de etapa	Automatización > Workflows	Asegurar que cada etapa solo se mueva hacia adelante. Excluir clientes existentes.	Contactos saltan etapas o vuelven atrás. Clientes reciben comunicaciones de prospección.
Set: Integraciones externas (ej. CRM, ERP)	Integraciones de HubSpot	Verificar qué propiedades modifican y con qué frecuencia. Establecer reglas de sincronización claras.	Datos duplicados o sobrescritos. Discrepancias entre sistemas.
Set: Propiedades auxiliares (ej. 'MQL reason')	Configuración de propiedades > Contactos	Crear propiedades para registrar el motivo y la fuente del cambio de etapa.	Imposibilidad de auditar por qué un contacto se convirtió en MQL/SQL.
Set: Listas activas para monitoreo	Contactos > Listas	Crear listas para detectar anomalías — ej. MQL sin actividad, SQL sin deal.	Problemas de calificación pasan desapercibidos. Pérdida de oportunidades de venta.

Fuentes

Última actualización: 2026-04-06 | Calypso

En HubSpot (2025), ¿cómo puedo auditar si mi lead scoring y mis Lifecycle Stages están creando MQL/SQL falsos por automatizaciones, reentrada y sincronizaciones

Respuesta

Fuentes

Etiquetas