Segundo artículo de la serie sobre lead nurturing. En el anterior vimos por qué perder un lead cuesta más de lo que casi nadie calcula. Aquí abordamos la raíz de por qué se pierden: tratar igual a leads que son radicalmente distintos. Empezamos por definir bien los dos perfiles que todo el mundo nombra y casi nadie distingue con criterio.
La diferencia entre un MQL y un SQL se explica casi siempre con la imagen de un semáforo: el lead empieza en ámbar, va madurando y en algún momento la luz cambia a verde y pasa a ventas. Es una imagen cómoda y es engañosa. Un MQL y un SQL no son el mismo vehículo esperando a que cambie la luz el semáforo: son dos vehículos distintos, que llegan en momentos distintos de maduración y que necesitan dos carreteras distintas. Confundirlos —tratar a uno como si fuera el otro— es una de las formas más caras y silenciosas de perder leads que ya están pagados.
Antes de explicar por qué esa distinción lo cambia todo, conviene definir bien cada figura, porque buena parte del problema nace de que hay mucha confusión con la definición de ambos conceptos y se deja a la libre interpretación de cada uno.
Qué es un MQL (Marketing Qualified Lead)
Un MQL es un contacto que, por su comportamiento, ha mostrado interés suficiente como para merecer seguimiento de marketing, pero que todavía no ha dado señales de querer comprar. La palabra clave es interés, y conviene separarla de su vecina peligrosa: intención de compra. No son lo mismo. Si hacemos el símil con este blog o línea temática, alguien puede leer tres artículos de tu blog, descargarse una guía y volver a tu web varias veces sin tener la menor intención de comprar a corto plazo. Está aprendiendo, comparando, formándose una opinión. Es un buen lead, pero no está listo para que alguien le ofrezca algo de forma intrusiva.
Lo que define a un MQL es el tipo de comportamiento que exhibe: descargas de contenido educativo, lecturas de blog, aperturas de correos, visitas repetidas a páginas informativas. Todo ello dibuja a alguien que está en la fase de exploración del problema, no en la de elegir una solución concreta. Verlo es fácil con un ejemplo.
Un responsable de compras de una tienda mediana descarga el catálogo mayorista de Aura desde un anuncio. Dos días después vuelve a la web y lee un artículo sobre cómo calcular márgenes en la reventa. A la semana abre un correo con casos de otras tiendas y hace clic en uno.
Hay interés real: ha vuelto, ha leído, ha interactuado. Pero nada en su comportamiento dice que quiera comprar todavía. Está entendiendo si este tipo de proveedor encaja en su negocio. Es un MQL de manual, y llamarle ahora para cerrar una venta sería el camino más rápido para perderlo.
Qué es un SQL (Sales Qualified Lead)
Un SQL es un contacto cuyo comportamiento indica intención de compra suficiente como para que un comercial invierta tiempo en él. La diferencia con el MQL no está en cuánto interés tiene, sino en qué tipo de interés muestra. El MQL explora; el SQL decide. Y decidir deja un rastro de comportamiento distinto: ya no consume contenido para aprender, sino para comparar opciones concretas y justificar una elección.
Las señales que marcan a un SQL son señales de intención, no de curiosidad. Visitas repetidas a la página de precios, una solicitud de demostración, consultas sobre condiciones o plazos, comparativas con competidores, y una especialmente reveladora: el reenvío de información a un compañero, que casi siempre significa que la decisión ha dejado de ser individual y ha entrado un comité (sea quien sea este comité). Cuando estos comportamientos aparecen, el lead ha cruzado una frontera. Volvamos al mismo responsable de compras.
El mismo contacto ha vuelto cuatro veces esta semana. Ha estado dos veces en la página de tarifas mayoristas, ha consultado las condiciones de pedido mínimo y ha reenviado el catálogo a otra dirección de la misma empresa —probablemente al dueño, que es quien firma.
Esto ya no es exploración: es una decisión en marcha. Si en este punto Aura le sigue mandando artículos educativos sobre márgenes, lo está aburriendo y regalando tiempo al competidor que sí le esté dando una propuesta concreta. Ahora es un SQL, y lo que necesita es exactamente lo contrario de lo que necesitaba hace tres semanas.
El problema: la frontera es subjetiva (y la subjetividad no escala)
Hasta aquí parece sencillo. El problema empieza cuando hay que aplicar esta distinción a cientos de leads sin un sistema que lo haga. Sin criterios objetivos, la clasificación depende del negocio y sus lógicas, de quién la haga y de cómo se haya levantado esa mañana. Un comercial optimista ve SQLs por todas partes y satura a leads que solo estaban mirando. Uno escéptico descarta como "frío" a un MQL que iba a convertir en dos semanas. El mismo lead, evaluado por dos personas del mismo equipo, recibe dos etiquetas distintas.
Y no está mal, no hay una definición exacta de MQL y SQL porque depende del comportamiento de nuestro propio negocio y algo que hacen en la mayoría de sitios de forma incorrecta es asociar unas reglas de clasificación comunes para cualquier negocio.
Con veinte leads al mes, la intuición de un buen comercial basta para gestionar esto. Con doscientos, se rompe. Nadie puede revisar manualmente doscientos perfiles cada semana, cruzar su historial de comportamiento y aplicar un criterio consistente lead a lead. La subjetividad es un lujo que solo funciona a pequeña escala, y el momento en que una empresa empieza a crecer es justo el momento en que ese método deja de servir. Lo que se necesita no es mejor criterio humano, sino un criterio que no dependa de qué humano lo aplique.
Debemos de conocer a nivel abstracto lo que es un MQL y un SQL, la clasificación de estos depende de la arquitectura de datos que tengamos y un sistema que clasifique de forma autónoma en función de unos patrones que se van entrenando.
Por qué cada uno necesita un funnel distinto
Aquí está el corazón del asunto, y es la parte que la mayoría de los artículos sobre MQL y SQL pasan por alto. Distinguir los dos perfiles no sirve para etiquetar bien: sirve porque cada uno necesita una máquina de nurturing completamente distinta. No un mensaje distinto dentro de la misma secuencia, sino un funnel con un objetivo, un ritmo y un tipo de contacto diferentes.
El MQL necesita un funnel de maduración. Su objetivo es construir confianza y mantenerse presente mientras el lead se forma una opinión, sin ninguna presión comercial. Ritmo pausado, contenido educativo, paciencia. El SQL necesita justo lo contrario: un funnel de conversión, cuyo objetivo es cerrar antes de que el lead se enfríe o el competidor lo capture. Ritmo rápido, contacto directo, propuesta concreta, resolución de objeciones. Son dos sistemas con lógicas opuestas.
Los dos errores que aparecen al mezclar los funnels son simétricos y los dos cuestan dinero. Tratar a un MQL como si fuera un SQL significa llamarle para vender cuando solo estaba investigando: lo presionas antes de tiempo, lo incomodas y lo quemas. Ese lead se va, y se va antes incluso de haber considerado comprar. Es, en la práctica, churn anticipado —un abandono que ocurre en la fase de captación en lugar de en la de cliente, pero con la misma causa de fondo: recibir un trato que no corresponde a su momento.
Presionar a un MQL es como pedirle matrimonio en la primera cita. No es que la intención sea mala; es que el momento convierte algo potencialmente bueno en un motivo para salir corriendo. Y un lead que sale corriendo no vuelve.
El error inverso es igual de caro. Tratar a un SQL como si fuera un MQL significa responder a su intención de compra con un goteo de contenido educativo y un ritmo pausado. El lead está listo para hablar de condiciones y tú le mandas un ebook. Pierdes el momento exacto en que estaba decidido, y ese momento tiene fecha de caducidad: mientras tú educas, el competidor que le dio una propuesta concreta cierra la venta. El lead no se enfría por falta de interés, sino por exceso de lentitud.
La prueba: especializar mueve la aguja
Esto no es teoría. En un equipo comercial que atendía todos los leads trabajaba sin una estrategia clara y trataba a todos con el mismo guion, daba igual que el contacto acabara de descargar un PDF o que llevara semanas pidiendo una llamada: todos recibían el mismo tratamiento, a medio camino entre educar y vender, que no servía bien para ninguno de los dos perfiles. Al reorganizar el equipo para que unas personas cuidaran la maduración de los MQL y otras se centraran en cerrar SQL, la conversión subió de forma notable. No cambió el producto. No cambió el volumen de leads ni el presupuesto de captación. Lo único que cambió es que cada perfil empezó a recibir el funnel que le correspondía.
de incremento en la tasa de conversión al especializar el equipo por tipo de lead, sin tocar el producto ni aumentar la inversión en captación. La diferencia estuvo solo en dar a cada perfil su funnel.
Lo interesante de este resultado es que apunta a una palanca de crecimiento que no depende del mercado publicitario. Mientras el coste por lead sigue subiendo año tras año, separar bien los funnels es una mejora de conversión que sale gratis en términos de captación: el mismo flujo de leads produce más ventas porque cada uno recibe el tratamiento adecuado. Es exactamente el tipo de mejora que sostiene un negocio cuando atraer leads nuevos se vuelve cada vez más caro.
El mismo lead recorre un camino u otro según su comportamiento. El funnel del MQL es lento y educativo; el del SQL es rápido y comercial. Cuando un MQL cruza el umbral de intención, pasa al funnel de conversión. Y donde termina este sistema —en el cliente— empieza el de retención.
Por qué BANT, MEDDIC y los frameworks clásicos se quedan cortos
Llegados a este punto, lo razonable es preguntarse cómo se decide, en la práctica, si un lead es MQL o SQL. La respuesta tradicional son los frameworks de cualificación: BANT (presupuesto, autoridad, necesidad y plazo), MEDDIC o CHAMP, entre otros. Todos comparten la misma lógica: hacer una serie de preguntas al lead —¿tienes presupuesto asignado?, ¿eres tú quien decide?, ¿para cuándo lo necesitas?— y clasificarlo según las respuestas.
Estos frameworks funcionan bien en un contexto muy concreto: ventas de ciclo largo, ticket alto y contacto humano constante, donde un comercial tiene tiempo de mantener una conversación con cada lead. Su límite aparece en cuanto sales de ahí. Dependen de dos cosas que en un funnel digital rara vez se dan: que el lead responda a las preguntas, y que haya una persona disponible para hacerlas. En una operación con cientos de leads que no hablarán con un humano hasta etapas muy tardías —si es que lo hacen—, preguntar no es una opción viable como sistema de clasificación primaria.
BANT y compañía clasifican según lo que el lead dice. Pero la mayoría de los leads de un funnel digital nunca dicen nada: solo hacen. Lo que escala no es preguntar, sino observar el comportamiento. Un lead que visita la página de precios tres veces en cinco días te está diciendo más sobre su intención que cualquier respuesta a un formulario.
Esto no significa que BANT o MEDDIC no sirvan. Siguen siendo excelentes guiones para estructurar una conversación comercial cuando esta por fin ocurre. Pero como motor para clasificar a escala quién es MQL y quién es SQL, llegan tarde y dependen de un recurso —el tiempo de un comercial— que es justo el que no quieres gastar en leads que aún no están listos. El criterio que sí escala no se basa en lo que el lead responde, sino en lo que el lead hace.
El comportamiento como criterio: el scoring que sí escala
La alternativa que resuelve el problema de escala es un sistema de scoring: asignar a cada lead una puntuación calculada a partir de su comportamiento observable y definir el umbral a partir del cual un MQL se convierte en SQL. En lugar de depender del criterio del comercial de turno o de que el lead conteste un formulario, el sistema aplica exactamente la misma lógica a los doscientos leads, cada día, sin cansarse y sin sesgos de humor. Es objetivo, consistente y auditable: siempre puedes revisar por qué el sistema clasificó a un lead de una manera.
Sobre ese scoring se construye lo que de verdad importa: el enrutamiento automático. Cuando la puntuación de un lead y sus señales indican que sigue en fase de exploración, el sistema lo mantiene en el funnel de maduración. Cuando cruza el umbral de intención, lo mueve al funnel de conversión y avisa al equipo comercial. Esto es, en esencia, lo que significa un buen sistema de lead nurturing automatizado: no enviar correos en masa, sino enrutar a cada lead al funnel correcto según lo que hace, en el momento en que lo hace, sin que nadie tenga que clasificarlo a mano.
El sistema de scoring que cualifica leads en captación no vive aislado: es la misma arquitectura de datos que, una vez el lead se convierte en cliente, detecta las señales de churn en retención. Cualificar un lead y predecir el abandono de un cliente son el mismo motor aplicado a dos puntos del ciclo de vida. Por eso un lead bien cualificado y bien nutrido no solo convierte mejor: se transforma en un cliente del que ya sabes mucho, lo que mejora su retención desde el primer día.
Esa continuidad es la clave de todo el sistema. La distinción entre MQL y SQL deja de ser una etiqueta que alguien asigna a mano y se convierte en la primera decisión de una arquitectura que acompaña al cliente desde que es un desconocido que descarga un catálogo hasta mucho después de su primera compra. Captación y retención no son dos problemas separados: son dos tramos del mismo recorrido, sostenidos por la misma inteligencia de datos.
La pregunta que queda abierta
Hemos dicho que un MQL se convierte en SQL cuando su comportamiento cruza un umbral de intención. Pero queda la pregunta más difícil y más importante: ¿cuál es ese umbral, exactamente? ¿Qué comportamientos, en qué orden y dentro de qué ventana de tiempo marcan el momento preciso en que un lead deja de explorar y empieza a decidir? Esa frontera no se adivina con intuición: se mide. Y medirla bien requiere entender de cerca el recorrido completo que hace un comprador entre el primer clic y la firma, porque es en ese recorrido donde se esconden las señales que de verdad importan. ¿Qué ocurre, exactamente, en esas semanas de decisión?
¿Te ha resultado útil?
¿Tienes un problema que
los datos podrían resolver?
Sin formularios largos. Una conversación de 30 minutos para ver si tiene sentido.
Hablamos