Un lead calificado para ventas (SQL) en B2B es un lead que ventas ha verificado contra criterios escritos: encaje con el ICP, un problema de negocio real, presupuesto y autoridad, una solución relevante y un plazo de decisión. Es un estado confirmado por una persona, no un score ni un conteo de clics. Si un lead no supera cualquiera de los cinco gates, no es un SQL.
La definición de SQL en la calificación B2B es donde el reporting del pipeline se rompe sin hacer ruido. La mayoría de los equipos cree que tiene un problema de leads. En realidad, tiene un problema de operaciones.
Probablemente conoces los síntomas. El pipeline se ve lleno, pero no cierra y no permite hacer forecasting. Ventas rechaza leads que marketing considera calificados. La attribution reporta actividad, no compradores verificados.
Calificar es, en realidad, decidir a quién le dices que no. Este artículo cubre la definición de SQL que necesita la calificación B2B, los gates y dónde debe vivir para funcionar.
¿Qué es una buena definición de SQL?
Una buena definición de SQL es escrita, breve y binaria. Enumera los gates que un lead debe superar e indica quién verifica cada uno. Fallar en cualquier gate significa "todavía no" o "no". Nunca depende solo de un score.
El scoring ordena, los gates deciden. Un lead puede tener un score alto y aun así no encajar. Ese es todo el trabajo de la definición de SQL en la calificación B2B: decidir quién cuenta. Parte de una definición de ICP B2B cerrada, porque la forma en que defines tu perfil de cliente ideal es el primer gate del que dependen todos los demás. Un SQL es algo que ventas comprueba, no algo que un modelo adivina.
Aquí se confunden tres términos, así que mantenlos separados:
- MQL. una señal de comportamiento. El contacto hizo algo.
- Lead score. un ranking. Te dice a quién mirar primero.
- SQL. un estado. Ventas lo confirmó contra los gates escritos.
¿Por qué se rompe la transición de MQL a SQL?
La transición de MQL a SQL se rompe porque marketing y ventas usan definiciones distintas. Marketing cuenta engagement. Ventas cuenta intención de compra. Sin criterios escritos compartidos, los leads se pasan por actividad y luego se rechazan por encaje.
Nadie es dueño de esa brecha. Marketing cumple su número en el papel. Ventas descarta en silencio una parte de lo que recibe. El CRM guarda ambos registros, así que el conteo de SQL reportado y el número en el que cree ventas nunca coinciden.
Esa discrepancia tiene un costo. El pipeline se ve lleno, así que los forecasts se construyen sobre él. Luego los negocios se estancan porque los compradores nunca tuvieron un problema, un presupuesto ni una autoridad reales. La attribution entonces le da crédito a los canales por leads que nunca fueron compradores. La mayoría de los equipos de marketing mide actividad en lugar de resultados de negocio, y una definición blanda de SQL es la forma en que ese hábito entra al pipeline.
Quizás te preocupe que criterios más estrictos hagan caer tus números. Van a caer. Ese es el punto. Un conteo de SQL menor y verificado es el único que predice ingresos. Un conteo mayor de leads que no encajan solo traslada el desacuerdo del traspaso a la revisión del forecast.
Más canales no lo arreglarán, y tampoco más puntos en un modelo de scoring. Corregir la definición de SQL es más barato que sumar otro canal, y la solución es una definición compartida que firmen ambos equipos. Un traspaso construido sobre actividad siempre será rechazado por encaje.
¿Cuáles son los cinco criterios de calificación de leads?
Los cinco gates son encaje con el ICP, un problema de negocio reconocido, presupuesto y autoridad, relevancia de la solución y un plazo de decisión. Un lead debe superar los cinco. El engagement puede subir la prioridad, pero nunca reemplaza un gate. Estos son los criterios de calificación de leads que vale la pena dejar por escrito, y son el núcleo de cualquier proceso de definición de SQL en la calificación B2B.
Gate 1, encaje con el ICP: cada lead se revisa contra un único perfil cerrado. Ningún canal recibe una versión más laxa. Los leads de marketplaces y listados pagados pasan los mismos gates que todos los demás, sin excepciones especiales. Si la empresa está fuera del perfil, la conversación termina aquí, por muy cálida que se sienta.
Gate 2, un problema de negocio reconocido: el comprador debe nombrar un problema real con sus propias palabras. Los típicos son un pipeline impredecible, un ROI poco claro, outbound o demand gen con bajo desempeño, un sitio web que frena la conversión o un exceso de herramientas. Un lead sin dolor reconocido sale temprano. El interés en tu contenido no es dolor.
Gate 3, presupuesto y autoridad: alguien en la llamada controla el presupuesto o puede llegar a quien lo controla. Aquí importa entender a los compradores y comités detrás de tu ICP. Sabe quién firma, quién influye y quién bloquea, para que ventas distinga a un champion de alguien que solo investiga.
Gate 4, relevancia de la solución: tu oferta debe encajar con el problema nombrado en el gate 2. Un dolor real que no puedes resolver sigue siendo un no. Decirlo temprano protege el tiempo de ventas y mantiene honesto el conteo de SQL.
Gate 5, un plazo de decisión: define una ventana que respalde tu propio ciclo de ventas. No copies un número de otra empresa. Un lead sin horizonte de decisión es un contacto para nurturing, no un SQL.
Cinco gates, todos obligatorios, sin excepciones por canal. Así se verifica cada uno y así se ve cuando falla:
- Encaje con el ICP. confirma que la empresa coincide con el perfil cerrado. Lo verifica ventas. Fallar se ve como un tamaño, sector o stack equivocado.
- Problema reconocido. confirma que el comprador nombra un dolor real. Ventas lo verifica en la llamada. Fallar se ve como una curiosidad cortés.
- Presupuesto y autoridad. confirma que hay dinero y un camino hacia la decisión. Lo verifica ventas. Fallar se ve como alguien que investiga y no tiene sponsor.
- Relevancia de la solución. confirma que tu oferta encaja con el problema. Lo verifica ventas. Fallar se ve como un buen lead para un servicio que no vendes.
- Plazo de decisión. confirma una ventana que coincide con tu ciclo de ventas. Lo verifica ventas. Fallar se ve como "quizás el próximo año".
¿Cómo aplicas los estándares de SQL en el CRM?
Convierte cada gate en un campo obligatorio con valores controlados. Así, un lead no puede llegar a la etapa de SQL hasta que ventas los complete. Usa el lead scoring para enrutar y priorizar leads. Usa los gates para decidir el estado. Una definición de SQL en la que los equipos puedan confiar vive en campos obligatorios, no en una wiki.
En la práctica, eso significa cuatro cosas:
- Campos obligatorios. uno por gate, completado por ventas, no por marketing.
- Valores controlados. listas desplegables, no texto libre, para que los reportes se mantengan limpios.
- Reglas de entrada a la etapa. el CRM bloquea la etapa de SQL hasta que todos los campos pasen.
- Scoring solo para enrutamiento. decide a quién se llama primero, nunca quién cuenta.
¿Por qué fallan las definiciones de SQL aunque los criterios sean correctos?
Por nuestro trabajo con clientes, la definición de SQL rara vez falla porque los criterios estén equivocados. Falla porque no se aplican en ningún lugar del CRM. Una definición en una página wiki es una sugerencia. En más de 15 años trabajando con más de 250 empresas B2B, he construido sistemas de HubSpot, attribution y automatización que reemplazaron flujos de trabajo manuales de marketing. El patrón es consistente. Los equipos que codifican las reglas en el sistema dejan de discutirlas.
El enrutamiento es un trabajo distinto de calificar. El scoring basado en encaje, como el lead scoring de HubSpot construido alrededor del encaje con el ICP, le dice a los reps dónde mirar primero, mientras que los gates deciden quién cuenta.
¿Qué deberías reportar? SQL que pasan los gates, no conteos brutos. Revisa las métricas de control cada semana y deja que gobiernen qué canales y ofertas reciben presupuesto. Los leads que no pasan los gates quedan registrados, pero no cuentan para las metas. Una regla que el CRM no puede aplicar no es un estándar.
¿Quién debería ser responsable de la definición de SQL?
La dirección de ventas y marketing deberían escribirla juntas. Un solo responsable debería custodiarla, normalmente RevOps o la dirección de ventas. Marketing no debería definirla por su cuenta, y ventas no debería cambiarla en silencio.
La autoría conjunta le da credibilidad a la definición en ambos lados. Un único responsable le da un historial de versiones. Un ritmo regular de revisión te permite endurecer un gate cuando los datos muestran que tiene fugas, a la vista de todos y con ambos equipos presentes.
SEO, PPC, RevOps, automatización y CRO son un solo sistema de crecimiento. Una definición compartida pertenece a ese sistema, no a un departamento. En nuestro trabajo con empresas SaaS, una mejor alineación operativa entre marketing y ventas redujo el CAC y mejoró la calidad de los leads. Las mejoras vinieron del traspaso, no de gastar más. Si tu traspaso es donde se rompe la confianza, empieza con definiciones compartidas y un traspaso de leads limpio. Un responsable, dos autores, una revisión permanente.
Corrige la volatilidad del pipeline sin contratar más SDRs
Arregla el filtro antes de añadir capacidad. La volatilidad suele venir de definiciones inconsistentes de "calificado", un tracking roto y un traspaso con fugas. Más SDRs trabajando el mismo filtro débil solo producen más leads rechazados, y más rápido.
La volatilidad del pipeline también es uno de los dolores de crecimiento más claros que puede nombrar un equipo B2B SaaS. Si te describe, estos son cuatro movimientos, en orden:
Este es trabajo estructural, no trabajo de campañas. Está más cerca de B2B RevOps que de la compra de medios: infraestructura que tu propio equipo puede poseer y operar.
- 1. Acuerda una sola definición de SQL. Usa los cinco criterios anteriores. Consigue que Ventas y Marketing lo aprueben.
- 2. Registra un código de motivo en cada lead rechazado. Los patrones en los rechazos te muestran qué criterio está fallando.
- 3. Corrige el tracking y la higiene del CRM. Fusiona duplicados, mapea las etapas y asegúrate de que se pueda confiar en los reportes.
- 4. Revisa los leads aceptados y rechazados con una cadencia regular. Hazlo como una reunión de decisión. Valida el encaje con el ICP, la alineación de la oferta y la probabilidad de cierre. Luego actúa sobre los negocios estancados.
¿Qué debería hacer la definición a continuación?
Repaso de los cinco gates en una línea cada uno:
- Encaje con el ICP. la empresa coincide con el perfil cerrado.
- Problema. el comprador nombra un dolor real.
- Presupuesto y autoridad. alguien puede decir que sí.
- Relevancia. tu oferta encaja con el problema.
- Plazo. una ventana de decisión que tu ciclo respalda.
Por dónde empezar
La calificación es el primer diagnóstico. Trabajamos en el diagnóstico antes de la ejecución, porque el error más costoso en crecimiento es ejecutar rápido sobre el sistema equivocado. Una definición clara de SQL es la misma idea aplicada a tu pipeline.
Si quieres un segundo par de ojos, revisaremos tu definición actual de SQL y cómo se aplica en tu CRM.
- ✓ Un SQL es un estado confirmado por una persona y verificado contra cinco gates escritos, no un score ni un conteo de clics.
- ✓ La mayoría de las disputas sobre SQL son problemas de operaciones: marketing cuenta engagement mientras ventas cuenta intención de compra.
- ✓ Los cinco gates son encaje con el ICP, un problema reconocido, presupuesto y autoridad, relevancia de la solución y un plazo de decisión.
- ✓ Aplica los gates como campos obligatorios del CRM con valores controlados, y usa el scoring solo para enrutamiento.
- ✓ Haz que ventas y marketing escriban la definición juntos, con un responsable único y una revisión permanente.
FAQ
¿Qué es un SQL en B2B?+
Un lead calificado para ventas (SQL) en B2B es un lead que ventas ha verificado contra criterios escritos: encaje con el ICP, un problema de negocio real, presupuesto y autoridad, una solución relevante y un plazo de decisión. Es un estado confirmado por una persona, no un score ni un conteo de clics.
¿Cuál es la diferencia entre un MQL, un lead score y un SQL?+
Un MQL es una señal de comportamiento, es decir, el contacto hizo algo. Un lead score es un ranking que muestra a quién mirar primero. Un SQL es un estado que ventas confirma contra los gates de calificación escritos. El scoring ordena, los gates deciden.
¿Por qué se rompe el traspaso de MQL a SQL?+
Se rompe porque marketing y ventas usan definiciones distintas. Marketing cuenta engagement y ventas cuenta intención de compra. Sin criterios escritos compartidos, los leads se pasan por actividad y luego se rechazan por encaje.
¿Una definición de SQL más estricta reducirá mis números de SQL?+
Sí, y ese es el punto. Un conteo de SQL menor y verificado es el único que predice ingresos. Un conteo mayor de leads que no encajan solo traslada el desacuerdo del traspaso a la revisión del forecast.
¿Cómo se aplica una definición de SQL en el CRM?+
Convierte cada gate en un campo obligatorio con valores controlados, completado por ventas. Agrega reglas de entrada a la etapa para que el CRM bloquee la etapa de SQL hasta que todos los campos pasen, y usa el lead scoring solo para decidir a quién se llama primero.
¿Quién debería ser responsable de la definición de SQL?+
La dirección de ventas y marketing deberían escribirla juntas, y un responsable único debería custodiarla, normalmente RevOps o la dirección de ventas. Marketing no debería definirla por su cuenta, y ventas no debería cambiarla en silencio.
¿Cómo se corrige la volatilidad del pipeline sin contratar más SDRs?+
Arregla el filtro antes de añadir capacidad. Acuerda una sola definición de SQL basada en los tres filtros, registra un código de motivo en cada lead rechazado, limpia el tracking y la higiene del CRM, y revisa los leads aceptados y rechazados con una cadencia regular.
