MQL vs SQL vs PQL: cuándo cada uno aplica a tu negocio (y cómo medirlos)

MQL, SQL y PQL son los 3 tipos de leads calificados más usados en B2B. La diferencia entre ellos no es semántica: define cómo opera tu sistema de marketing y ventas.

Definiciones rápidas:

• MQL (Marketing Qualified Lead): lead que marketing considera con potencial real basado en perfil + engagement. No fue contactado por ventas todavía.
• SQL (Sales Qualified Lead): MQL que ventas contactó y confirmó BANT (Budget, Authority, Need, Timeline) o equivalente.
• PQL (Product Qualified Lead): lead que ya usó el producto (free trial, freemium) y mostró señales de adopción que predicen disposición a pagar.

Cuándo aplica cada uno:

• Solo MQL + SQL: si tu producto no tiene free trial ni freemium (consultoría, servicios profesionales, B2B enterprise con sales-led growth).
• Los tres (MQL + SQL + PQL): si tu producto tiene free trial o freemium (SaaS, marketplaces, productos product-led).
• Solo PQL: si tu producto es self-serve puro sin sales team (raro, generalmente solo en B2C masivo).

Esta guía cubre cómo definir y medir cada uno, cuándo conviene cuál y los errores típicos.

MQL es lead que marketing decide entregar a ventas (o a un proceso de nurturing más intenso). La definición operacional debe responder dos preguntas: ¿quién es? ¿qué hizo?

¿Quién es? - Fit con ICP:

Dimensiones a verificar: - Tamaño de empresa (rango target). - Industria. - País/región. - Cargo del lead (decisor, influencer, usuario).

Para que sea MQL, el lead debe cumplir criterios mínimos de ICP. Sin fit, no es MQL aunque tenga engagement alto. Un curioso de la industria equivocada no es MQL.

¿Qué hizo? - Engagement:

Señales que indican interés real: - Descargó lead magnet (especialmente de fondo de funnel: pricing guide, comparativa, case study). - Visitó página de pricing. - Abrió 3+ emails en últimos 30 días. - Asistió a webinar. - Llenó formulario de contacto.

Más de un par de señales combinadas es la marca operacional de MQL. Una sola señal (por ejemplo, descargó un eBook genérico) generalmente no es suficiente.

Definición operacional típica de MQL para SaaS B2B PYME:

"Lead que cumple criterios de ICP (empresa 10-200 personas, industria SaaS/tech/servicios, país en LATAM) Y al menos 2 señales de engagement de la lista anterior en últimos 30 días."

Documentar esta definición en una página. Compartirla con todo el equipo. Sin definición escrita, cada persona usa su propia versión y el handoff falla.

Cómo medirlo en CRM:

Lead Score con peso 50% ICP + 50% engagement. Threshold para MQL: 50/100 puntos. Por encima de eso, automáticamente se marca como MQL y entra al proceso de evaluación de ventas.

En GoHighLevel: Custom Fields para ICP + Workflow que suma puntos por engagement + automation que actualiza tag 'MQL'. En HubSpot: Lead Scoring de Marketing Hub Pro o Operations Hub.

SQL es MQL que ventas contactó y validó. La validación se hace típicamente con framework BANT o similar.

BANT (clásico): - Budget: ¿tiene presupuesto en rango aceptable? - Authority: ¿es decisor o influencer en la decisión? - Need: ¿tiene problema real que tu producto resuelve? - Timing: ¿tiene urgencia o plazo definido?

Para que un MQL pase a SQL, debe cumplir al menos 3 de los 4 BANT. Si cumple 2 o menos, queda como MQL y entra a nurturing.

Frameworks alternativos:

• MEDDIC: Metrics, Economic buyer, Decision criteria, Decision process, Identify pain, Champion. Más usado en enterprise.
• GPCTBA/C&I: Goals, Plans, Challenges, Timeline, Budget, Authority, Consequences & Implications. Más completo, más tiempo de discovery.
• CHAMP: Challenges, Authority, Money, Prioritization. Más enfocado en pain.

Para PYME B2B, BANT es suficiente. Para enterprise, MEDDIC.

Definición operacional de SQL:

"MQL contactado por ventas con discovery call completada, que cumple al menos 3 de 4 BANT, con próximo paso agendado (demo o propuesta)."

Criterios verificables: - Discovery call completada (fecha en CRM). - BANT documentado en notas del CRM con respuestas específicas. - Próximo paso agendado con fecha.

Conversión típica MQL→SQL:

B2B PYME: 25-45% es saludable. <20% indica problema (MQL mal definido, ventas no contacta a tiempo, calidad de leads baja). >60% indica que el MQL está muy laxo (cualquier lead pasa, perdiendo valor de la calificación).

Errores comunes:

• Pasar a SQL sin discovery call hecha. La discovery call es el filtro principal.
• BANT sin documentar. Si no está en CRM, no pasó.
• Pasar a SQL sin próximo paso agendado. Sin compromiso futuro, no es lead activo.

PQL (Product Qualified Lead) es un concepto más nuevo (popularizado por Tomasz Tunguz y la escuela product-led growth ~2018-2020). Es lead que ya usó el producto y mostró señales de adopción que predicen disposición a pagar.

Por qué importa: en SaaS con free trial o freemium, el comportamiento dentro del producto es señal mucho más fuerte que cualquier engagement de marketing. Un usuario que activó 3 features clave en su primera semana tiene 5-10x más chance de pagar que un usuario que solo abrió emails de marketing.

Señales típicas de PQL:

1. Activación del 'aha moment': la acción que correlaciona con retención a largo plazo. Varía por producto: - Slack: 2.000 mensajes enviados en team. - Dropbox: 1 archivo guardado en 1 device. - Notion: 1 página compartida con team. - GoHighLevel: 1 contacto importado + 1 workflow activado.

Medir cuál es tu 'aha moment' requiere análisis de cohort: comparar comportamiento de usuarios que se convirtieron a paid vs los que churned.

2. Uso de features de plan paid: si el usuario intenta usar features que están detrás de paywall, es señal fuerte de PQL. Hizo clic en feature locked, vio modal de upgrade, exploró pricing.

3. Adopción team-based: si el usuario invitó miembros del team al workspace, es señal de adopción organizacional, no solo individual.

4. Volumen de uso alto: logins frecuentes, tiempo de sesión largo, integraciones conectadas. Indica que el producto está siendo usado en producción, no solo evaluado.

5. Tiempo desde signup: PQL típicamente requiere días o semanas de uso, no solo signup. Un signup sin actividad NO es PQL.

Definición operacional de PQL para SaaS B2B PYME:

"Usuario de free trial o freemium que: 1) activó el aha moment, 2) usó el producto 5+ veces en 7 días, 3) invitó al menos 1 miembro del team O conectó al menos 1 integración."

Umbrales específicos varían por producto. La regla: definir PQL basándose en señales que históricamente correlacionan con cierre.

Conversión típica PQL → paid:

SaaS B2B PYME bien implementado: 25-50% de PQLs convierten a paid en 30-60 días. Esto es 3-5x superior a tasa de conversión de free trial sin filtro PQL.

Cómo implementar: integrar product analytics (Mixpanel, Amplitude, PostHog) con CRM. Cuando usuario cumple criterios PQL, se marca automáticamente y se notifica a ventas (en SaaS de high-touch) o se dispara secuencia de upgrade automática (en SaaS de low-touch).

Modelo 1: Solo MQL + SQL (Sales-led growth tradicional)

Aplica a: - Consultoría y servicios profesionales. - B2B enterprise con ciclos largos. - Productos sin free trial ni freemium. - High-touch sales con discovery call obligatoria.

Ejemplo: agencias de marketing, software enterprise con implementación compleja, servicios de consultoría tipo Minimal Consulting.

Proceso: marketing genera MQL → ventas valida BANT → SQL → cierre.

Modelo 2: MQL + SQL + PQL (Hybrid)

Aplica a: - SaaS B2B con free trial. - SaaS B2B con freemium pero también sales team. - Productos con sales-assist sobre product-led growth.

Ejemplo: HubSpot (free CRM + sales team), Asana (free tier + sales para enterprise), GoHighLevel (free trial + sales asistido).

Proceso: marketing genera MQL → algunos pasan por sales (SQL) → otros activan trial y se convierten en PQL si adoptan → cierre por ambos paths.

Modelo 3: Solo PQL (Pure Product-Led Growth)

Aplica a: - SaaS de adopción individual sin sales team. - Self-serve puro. - Productos virales (B2C2B).

Ejemplo: Notion, Figma en sus inicios, Linear, Loom.

Proceso: usuario llega al producto → free trial o freemium → adopta y se convierte en PQL → upgrade automático sin sales humano.

Cómo elegir tu modelo:

Dos preguntas:

1. ¿Tu producto se puede usar inmediatamente sin setup humano? Si sí, PQL es viable. 2. ¿Tu ACV (Annual Contract Value) justifica costo de sales? Si ACV >USD 5.000/año, sales-led tiene sentido. Si ACV <USD 1.000/año, product-led es más eficiente.

Decisión típica: - ACV <USD 1.000 + producto self-serve: Modelo 3 (solo PQL). - ACV USD 1.000-5.000 + producto self-serve: Modelo 2 (hybrid). - ACV >USD 5.000 OR producto requiere implementación: Modelo 1 (solo MQL + SQL).

Muchas empresas evolucionan: empiezan Modelo 1 (sales-led con manual touch), agregan free trial para reducir CAC y evolucionan a Modelo 2, eventualmente Modelo 3 para segmentos low-ACV.

1. Definición de MQL demasiado laxa. 'Cualquiera que descargue un eBook es MQL'. Resulta en miles de MQLs que ventas no puede procesar y baja calidad del pool. Mejor: combinar ICP fit + engagement (descarga de bottom-funnel content + 2 visitas a pricing) para mantener el bar alto.

2. SQL sin discovery call. Marketing y ventas usan el término SQL para cosas distintas. Para evitarlo: definir SQL operacionalmente como 'MQL con discovery call completada y BANT documentado'.

3. PQL definido en cabeza del fundador. El producto manager 'siente' qué es PQL pero no está documentado ni medido. Resulta en PQL inconsistente y revenue oportunidades perdidas. Mejor: análisis de cohort para identificar señales reales.

4. Múltiples definiciones en el equipo. Marketing dice MQL es A, ventas dice MQL es B, customer success dice MQL es C. Causa la mayor parte de la fricción entre equipos. Una sola definición, documentada, compartida.

5. No revisar definiciones con el tiempo. El ICP cambia, el mercado cambia, las features del producto cambian. Las definiciones de MQL/SQL/PQL deben revisarse trimestralmente.

6. Forzar PQL en negocios donde no aplica. Si tu producto requiere implementación compleja y no se puede usar inmediatamente, PQL no aplica. Forzar el concepto donde no funciona genera procesos overhead sin valor.

Cómo evitar los 6 errores:

• Documento de una página con las 3 definiciones aplicables a tu modelo de negocio.
• Review trimestral con marketing, ventas y product (si aplica PQL).
• Métricas compartidas en dashboard único.
• Workshop semestral de re-calibración con data real.

El objetivo no es tener las definiciones 'perfectas'. Es tener definiciones consistentes que el equipo respete y que se ajusten con la realidad operativa.