MQL vs SQL: definiciones, diferencias y playbook práctico

• Acerca de
• Últimas entradas

Eduardo Gámez

MKT AUTOMATION SPECIALIST en Why Ads Media SL

Encargado de todo lo que tiene que ver con automatización de CRM y CDP, donde los flujos, campañas y audiencias ayudan a sus estrategias de crecimiento

Últimas entradas de Eduardo Gámez (ver todo)

• MQL vs SQL: definiciones, diferencias y playbook práctico - marzo 9, 2026
• Cómo crear reports en Connectif con Looker Studio - abril 21, 2025
• Estrategias de Research para eCommerce con Connectif - abril 10, 2025

¿Qué es un MQL?

MQL significa Marketing Qualified Lead: un contacto que ha mostrado señales suficientes de interés para que Marketing lo considere potencialmente relevante, pero todavía no está validado como oportunidad de venta. En la comparación mql vs sql, SQL se refiere a Sales Qualified Lead (no a Structured Query Language) y supone un nivel de intención y encaje superior, normalmente listo para que Ventas lo gestione como conversación comercial.

En B2B y B2C, el MQL se define con una combinación de engagement (acciones y frecuencia) y encaje (atributos del perfil). La definición útil no es la que “suena bien”, sino la que evita dos problemas: pasar a Ventas contactos inmaduros o dejar en nurturing a contactos que ya están listos para una conversación.

Señales de comportamiento que indican MQL

Las señales de comportamiento (behavioral) son especialmente valiosas porque capturan intención en tiempo real. Para que sean operativas, conviene que estén instrumentadas en analítica y unificadas en el CRM o en la plataforma de automatización.

Indicadores típicos de MQL (la combinación exacta depende de ciclo de compra y ticket): consumo recurrente de contenido (varias sesiones en pocos días), interacción con contenidos de media intención (comparativas, guías técnicas, webinars), clics repetidos en CTAs hacia páginas de producto, y respuesta a secuencias de nurturing (aperturas/clics sostenidos, no un único impacto).

También funciona como señal de MQL la profundidad de navegación cuando hay una arquitectura clara: visitar varias URLs dentro de una misma categoría (por ejemplo, dos artículos técnicos y una página de casos), o volver a una misma sección en ventanas cortas.

Advertencia operativa: una sola visita a “Pricing” o “Contacto” no siempre es intención. Puede ser investigación temprana, comparación o incluso tráfico interno. Por eso, la condición MQL suele funcionar mejor como regla compuesta (acción + contexto + frecuencia) y con ventanas temporales explícitas.

Datos mínimos para considerar un MQL (B2B / B2C)

Además del comportamiento, un MQL necesita datos mínimos para segmentar, cumplir con privacidad y permitir el siguiente paso de nurturing. En términos prácticos, el mínimo no debe ser “todo el formulario”, sino lo necesario para continuidad de conversación y ruteo.

B2B: suele bastar con email corporativo (o identificador equivalente), empresa o dominio, rol/área (categórico), y un indicador de tamaño (rango de empleados o facturación). Si el producto depende de región o normativa, país o comunidad autónoma puede ser relevante. Cuando hay varios ICP, se recomienda capturar un campo de caso de uso (categórico) para enrutar mensajes y scoring.

B2C: el mínimo suele ser canal de contacto (email o teléfono si aplica), preferencia de categoría o intención (categórica), y señales de capacidad de compra indirectas (por ejemplo, rango de presupuesto, tipo de plan). En B2C, el comportamiento pesa más que el perfil, pero el perfil sigue siendo clave para evitar sobrecalificar tráfico oportunista.

En ambos casos, la definición MQL debe documentar qué campos son obligatorios, cuáles son enriquecibles (enriquecimiento posterior por herramientas o equipo) y cuáles no se usarán para calificar por riesgo de sesgo o baja fiabilidad.

¿Qué es un SQL?

SQL significa Sales Qualified Lead: un contacto que, según criterios acordados, está listo para una gestión comercial. A diferencia del MQL, el SQL exige señales más cercanas a compra (o a evaluación formal) y un nivel de validación suficiente para que Ventas invierta tiempo con alta probabilidad de avance.

Un SQL no es sinónimo de “quiere comprar ya”. En ciclos largos, puede significar “entra en pipeline” o “merece discovery”. La clave es que el SQL define un punto de traspaso (handoff) con expectativas claras: Ventas recibe el lead con contexto y Marketing deja de tratarlo como una audiencia genérica.

Señales y criterios que indican SQL

Los criterios de SQL deben mezclar intención, encaje y viabilidad. En B2B, muchos equipos formalizan esto con BANT/MEDDIC u otras variantes, pero no es obligatorio convertirlo en un interrogatorio: se puede aproximar con evidencias digitales y un primer contacto bien diseñado.

Señales comunes que apuntan a SQL:

Intención alta: visita repetida a pricing, comparador, integraciones, seguridad/compliance; interacción con calculadoras; solicitud explícita de hablar con un comercial; respuesta afirmativa a un correo de cualificación; selección de “necesidad inmediata” en un formulario.

Encaje: industria objetivo, tamaño compatible, rol con influencia (o acceso al decisor), stack tecnológico compatible, localización atendida, caso de uso que el producto cubre sin custom excesivo.

Viabilidad: evidencia de presupuesto o de problema priorizado; urgencia razonable; disponibilidad para reunión; aceptación de condiciones básicas (por ejemplo, rango mínimo de contrato o número de usuarios).

En B2C, el SQL suele equivaler a “lead listo para cierre” y se activa cuando hay interacción directa (chat, llamada, WhatsApp, visita a tienda) y señales de capacidad de compra (por ejemplo, preaprobación, selección de financiación, disponibilidad de stock, preferencia cerrada por un modelo).

Qué información debería tener Ventas al recibir un SQL

El handoff funciona cuando Ventas recibe un paquete mínimo consistente. No se trata de acumular campos, sino de entregar contexto accionable.

Contenido recomendado del SQL en el CRM:

Fuente y campaña: canal (orgánico, paid, referral), campaña y creatividad si aplica; esto permite ajustar expectativas y entender sesgos (por ejemplo, leads de “comparativa” vs “branding”).

Línea temporal de actividad: últimas páginas o eventos relevantes (pricing, integraciones, casos, demo), última fecha de interacción y frecuencia en ventana (por ejemplo, 7 días).

Motivo de calificación: regla que disparó el SQL (por ejemplo, “score ≥ X + encaje ICP + visita pricing 2 veces”). Este campo reduce discusiones posteriores.

Encaje resumido: industria, tamaño, rol, país; en B2B, también stack o requisito clave (por ejemplo, “necesita SSO”).

Próximo paso sugerido: tipo de contacto (llamada, email, mensaje), franja horaria si se capturó, y un guion corto con la hipótesis del problema.

Cuando existe un SD R/BDR, conviene separar “SQL” (apto para discovery) de “opportunity” (descubierto y confirmado). Si no existe, el SQL debe estar lo bastante limpio como para que el primer contacto no sea una recogida de datos desde cero.

MQL vs SQL — tabla comparativa rápida

Una tabla de comparación reduce ambigüedad y ayuda a alinear a Marketing, Ventas y RevOps sobre qué significa cada etapa en la práctica.

Cómo pasar de MQL a SQL: playbook paso a paso

El paso de MQL a SQL debe tratarse como un sistema: definición de criterios, instrumentación, automatización, control de calidad y un acuerdo de tiempos. La ejecución cambia por sector, pero el patrón es estable: detectar señales, acumular evidencia, validar encaje y disparar un handoff verificable.

1. Definición operativa: documentar qué eventos y atributos califican MQL y SQL, con ventanas temporales y excepciones (por ejemplo, excluir clientes existentes o dominios internos).

2. Instrumentación y unificación: asegurar que formularios, analítica y CRM registran los eventos relevantes con el mismo identificador (cookie/ID, user_id, o clave CRM), evitando duplicados.

3. Scoring + reglas de promoción: combinar scoring (puntos) con reglas de gating (encaje/viabilidad). La promoción a SQL debe guardar el “motivo” en un campo.

4. Workflow de handoff: creación/actualización de registro, asignación (round-robin o por territorio), notificación y tareas con caducidad, más un estado de “contactado/no contactado”.

5. Control de calidad: muestreo semanal de SQL por Ventas/RevOps para verificar si los criterios se correlacionan con oportunidades.

6. Iteración: ajustar pesos del scoring y triggers a partir de métricas (MQL→SQL, SQL→Opportunity, time-to-contact, win rate por origen).

Reglas de lead scoring recomendadas

El lead scoring funciona cuando representa probabilidad de avance, no “popularidad” de un usuario. Por eso conviene separar scoring de comportamiento (intención) y scoring de perfil (encaje). También es recomendable incorporar decaimiento temporal: acciones antiguas pesan menos.

Ejemplo hipotético de matriz de puntos (orientativo, no universal):

Comportamiento: visitar pricing (alto), visitar integraciones o seguridad (alto), repetir sesión en 7 días (medio), hacer clic en una secuencia (medio), leer artículos genéricos (bajo). Penalizaciones típicas: rebotes de email, desuscripción, visitas aisladas sin repetición en 30 días.

Perfil (B2B): rango de tamaño objetivo (alto), industria objetivo (medio/alto), rol alineado (medio), email gratuito (penalización), país fuera de cobertura (penalización fuerte). En B2C, el perfil suele ser menos determinante; funciona mejor como filtro de elegibilidad.

La promoción a SQL suele depender de dos condiciones: umbral de score y gates de encaje. Ejemplo hipotético: “score ≥ 60” y “tamaño en rango” y “país en cobertura”. Esto evita que un estudiante o un competidor suba a SQL por consumir contenido intensamente.

Referencia útil para conceptos y enfoques de scoring: documentación de HubSpot sobre scoring.

Triggers automáticos y workflows

Los triggers más fiables combinan evento (acción) + condición (atributo o score) + ventana temporal. También se recomienda diferenciar triggers “duros” (promocionan a SQL) de triggers “blandos” (ajustan score o cambian segmento).

Patrones de automatización habituales:

Trigger duro: “envío de formulario de alta intención” (por ejemplo, solicitud de contacto comercial) + “encaje ICP = verdadero” → estado = SQL, asignar owner, crear tarea con vencimiento.

Trigger duro: “visita pricing dos veces en 7 días” + “score total ≥ umbral” → SQL.

Trigger blando: “apertura/clic en email de caso de uso” → sumar puntos y mover a secuencia más específica.

Trigger blando: “inactividad 30 días” → restar puntos o reiniciar a etapa MQL frío, evitando que el pipeline se llene de SQL caducados.

Para orquestación, es común usar automatización nativa del CRM (HubSpot, Salesforce con herramientas complementarias) o conectores. El objetivo no es “automatizar todo”, sino asegurar trazabilidad y consistencia del handoff.

<script>
// Ejemplo hipotético para GTM: registrar cambio de etapa sin datos personales.
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'lead_stage_change',
  lead_stage: 'SQL',
  previous_stage: 'MQL',
  lead_id: 'crm_12345',
  email_hash: 'sha256:__HASH__',
  lead_source: 'paid_search',
  product_line: 'b2b_saas',
  score_total: 72
});
</script>

En medición, conviene alinear nombres de evento y parámetros con el modelo de eventos de GA4 y con la lógica de CRM. Documentación de referencia: guía de eventos en Google Analytics 4 y especificación de dataLayer en Google Tag Manager.

{
  "workflow_name": "Promoción MQL a SQL (ejemplo hipotético)",
  "trigger": {
    "type": "event",
    "name": "page_view",
    "conditions": [
      {"param": "page_category", "operator": "equals", "value": "pricing"},
      {"param": "views_last_7d", "operator": ">=", "value": 2},
      {"param": "score_total", "operator": ">=", "value": 60},
      {"param": "icp_fit", "operator": "equals", "value": true}
    ]
  },
  "actions": [
    {"type": "crm.update", "field": "lifecycle_stage", "value": "SQL"},
    {"type": "crm.update", "field": "sql_reason", "value": "pricing_2x_7d_and_score"},
    {"type": "crm.assign_owner", "strategy": "round_robin", "team": "sales"},
    {"type": "crm.create_task", "due_hours": 2, "title": "Contactar SQL"},
    {"type": "notify", "channel": "slack", "message": "Nuevo SQL asignado: crm_12345"}
  ]
}

Si la automatización incluye retargeting o audiencias, es importante que los estados (MQL/SQL) se sincronicen con cuidado, evitando reimpactar a SQL con creatividades de descubrimiento que generen fricción comercial.

SLA y handoff Marketing → Ventas

El SLA (acuerdo de nivel de servicio) entre Marketing y Ventas define qué se entrega y en qué tiempo se gestiona. No es un documento “para archivo”: es un conjunto de reglas comprobables en CRM.

Elementos técnicos que suelen formar parte del SLA:

Definición de SQL aceptado: campos mínimos presentes, gates de encaje, y motivo de calificación registrado.

Tiempo objetivo de primer contacto: una ventana medible (por ejemplo, “en horas laborables”), registrada en un KPI como time to contact. El objetivo debe adaptarse a capacidad real de Ventas y a la urgencia del producto.

Estados de gestión: “Pendiente de contacto”, “Contactado”, “No se pudo contactar”, “No cualifica”, “En nurturing”. Cada estado necesita una razón normalizada para análisis.

Devolución a Marketing: criterios para “recycled lead” (por ejemplo, no encaja ahora, pero sí más adelante) y cómo se reintroduce en nurturing sin duplicar.

Control de calidad: revisión periódica de una muestra de SQL y registro de feedback estructurado. Sin este feedback, el scoring se convierte en una discusión de opiniones.

En organizaciones con múltiples líneas de producto, el SLA debe cubrir también el ruteo: territorio, vertical, idioma y prioridad, para evitar que el lead “rebote” entre equipos.

Ejemplos prácticos y formatos

Los ejemplos ayudan a convertir definiciones en decisiones. A continuación se describen formatos de trabajo habituales con ejemplos hipotéticos, aplicables tanto a inbound como a captación con paid media.

Ejemplo hipotético B2B (SaaS): un lead visita dos veces la página de integraciones y una vez pricing en 5 días, asiste a un webinar técnico y pertenece a una empresa del ICP (tamaño y sector). Marketing lo marca como MQL al superar el umbral de score. Se promueve a SQL cuando añade la señal de alta intención (pricing repetido) y el encaje está verificado. Ventas recibe el lead con historial (“integraciones + pricing”), caso de uso declarado (“automatización”), y una nota de “posible bloqueo: requiere SSO”.

Ejemplo hipotético B2C (servicio con asesoramiento): un usuario vuelve varias veces a una categoría de producto, usa un simulador y deja sus datos con preferencia concreta. Se considera MQL por comportamiento repetido. Se convierte en SQL cuando confirma disponibilidad horaria y el presupuesto está dentro de rango. El handoff contiene “preferencia de plan”, “canal preferido” y “última interacción”.

Formato de nota de handoff (texto corto y estructurado) para que sea escaneable:

Contexto: origen/campaña + páginas clave vistas.

Hipótesis de necesidad: problema probable por contenido consumido.

Objeción prevista: requisito o fricción detectada (seguridad, integraciones, precio).

Propuesta de primer mensaje: una frase con enfoque de discovery, no de demo inmediata.

Asunto interno CRM: SQL por intención alta

Contexto: paid_search | campaña "integraciones" | visitó /integraciones (2), /pricing (2) en 5 días
Encaje: industria = "software" | tamaño = "51-200" | país = "ES" | rol = "Operaciones"
Motivo SQL: pricing_2x_7d_and_score
Hipótesis: busca reducir trabajo manual conectando herramientas
Posible bloqueo: pregunta recurrente sobre SSO/seguridad
Siguiente paso sugerido: discovery de 15-20 min

Dashboards y métricas clave (KPI)

Un dashboard útil conecta el funnel completo y permite detectar dónde se degrada la calidad: en captación, en nurturing, en promoción a SQL o en la velocidad de respuesta de Ventas. Para evitar dashboards “decorativos”, cada métrica debe tener un uso operativo asociado (optimizar presupuesto, ajustar scoring, redistribuir capacidad comercial).

KPI habituales para MQL/SQL:

Tasa de MQL: MQL / leads totales (o / contactos nuevos). Sirve para detectar si el tráfico aporta intención o solo volumen.

Conversión MQL→SQL: proporción y por cohorte temporal (semana/mes). Cuando cae, suele indicar scoring inflado, nurturing ineficiente o gates de encaje mal definidos.

Time to contact en SQL: tiempo desde promoción a SQL hasta primer intento de contacto registrado. Es crítico si el canal trae leads de intención alta.

SQL aceptado vs rechazado: porcentaje de SQL que Ventas marca como “no cualifica”, con razones normalizadas. Es el termómetro de alineación.

SQL→Oportunidad y Oportunidad→Venta: aunque exceda la definición estricta de MQL/SQL, es el cierre del loop para ajustar scoring con resultados, no con percepciones.

Rendimiento por fuente/campaña: no solo CPA por lead, sino CPA por SQL y por oportunidad. Si no hay atribución perfecta, un modelo coherente y estable es preferible a cambiarlo cada semana.

Para medición y modelado, suele ser útil consolidar eventos en un data warehouse o en BigQuery cuando existe volumen. Ejemplo hipotético de consulta SQL para ver conversión MQL→SQL por canal (estructura orientativa):

SELECT
  lead_source,
  COUNTIF(stage = 'MQL') AS mql_count,
  COUNTIF(stage = 'SQL') AS sql_count,
  SAFE_DIVIDE(COUNTIF(stage = 'SQL'), COUNTIF(stage = 'MQL')) AS mql_to_sql_rate
FROM lead_stage_events
WHERE event_date BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY) AND CURRENT_DATE()
GROUP BY lead_source
ORDER BY mql_to_sql_rate DESC;

En entornos con GA4, conviene definir eventos y dimensiones personalizadas con cuidado, evitando datos personales y manteniendo una taxonomía estable. GA4 no debe convertirse en el “CRM paralelo”; su rol es medir comportamiento y atribución, mientras que el CRM es el sistema de registro del estado del lead.

Errores comunes y cómo evitarlos

Definiciones vagas: describir MQL y SQL con frases genéricas (“interesado”, “listo para comprar”) impide automatización y genera fricción. Evitarlo requiere reglas con eventos y atributos concretos, ventanas temporales y condiciones de exclusión.

Score sin decaimiento: acumular puntos indefinidamente convierte leads antiguos en “SQL por historial”. Evitarlo con decaimiento por tiempo o reinicio de score tras inactividad, y con criterios de “actividad reciente” como gate.

Promoción por un único evento: un solo clic o una sola visita a pricing puede ser ruido. Evitarlo con reglas compuestas y con confirmación por repetición o por interacción directa.

Formularios como única fuente de verdad: confiar solo en lo declarado en formularios introduce sesgo (campos inventados, selección al azar) y frena conversión por fricción. Evitarlo mezclando declaración mínima + enriquecimiento y comportamiento.

Handoff sin contexto: enviar un SQL a Ventas sin motivo y sin actividad reciente provoca contacto genérico y baja tasa de respuesta. Evitarlo registrando “sql_reason”, adjuntando timeline de eventos clave y estandarizando la nota de handoff.

Sin control de calidad: si Ventas rechaza SQL pero no hay razón normalizada, no se aprende nada. Evitarlo con motivos de rechazo cerrados (picklist), revisión periódica y ajustes de reglas basados en datos.

Canibalización de mensajes: mantener nurturing agresivo cuando el lead ya es SQL puede interferir con la conversación comercial. Evitarlo con supresión automática de ciertas secuencias y audiencias al cambiar a SQL.

Herramientas recomendadas y ejemplos de automatización

El stack típico para gestionar MQL y SQL combina un CRM, una herramienta de marketing automation, analítica (GA4) y un sistema de integración (nativo o vía iPaaS). La elección exacta depende de complejidad, volumen y necesidad de gobernanza.

CRM: debe ser el sistema de registro para estados MQL/SQL, owners, tareas, motivos y resultados. Los estados deben estar en campos estándar o equivalentes para reporting consistente.

Marketing automation: útil para lead nurturing, scoring, segmentación y triggers. El punto crítico es que el scoring y la promoción a SQL queden auditables (qué regla, qué fecha, qué evento).

Analítica (GA4) y etiquetado (GTM): necesarios para capturar intención y para atribución por canal. Conviene definir una taxonomía mínima de eventos relacionados con intención (pricing_view, integration_view, form_submit, lead_stage_change) y mapearla a CRM cuando sea posible.

Integración / orquestación: en stacks heterogéneos, herramientas como Zapier o n8n suelen cubrir ruteo y notificaciones, pero la lógica crítica de lifecycle conviene que resida en un sistema gobernable (CRM/automation) para reducir puntos de fallo.

Para automatización de emails y journeys, guías como el recurso de Mailchimp sobre MQL vs SQL ayudan a alinear nomenclatura y prácticas, aunque la implementación final depende de campos, consentimiento y modelo de datos.

Casos de estudio (mini-casos)

Mini-caso hipotético B2B (ciclo medio): un equipo define SQL solo por “formulario enviado” y observa que Ventas rechaza muchos leads por falta de encaje. Se ajusta el modelo: se separa “formulario de contenido” (MQL) de “solicitud comercial” (SQL), se añade gate de tamaño/industria y se exige actividad reciente. Resultado esperado (hipotético): menos SQL totales, mayor tasa SQL→Oportunidad y menos tiempo perdido en contacto con leads fuera de ICP. La mejora real debe validarse en cohorts, no por impresión en la primera semana.

Mini-caso hipotético B2C (alto volumen): la promoción a SQL se hacía por score acumulado, sin decaimiento. Se introduce decaimiento temporal y una señal de intención directa (interacción con simulador + selección de preferencia). Resultado esperado (hipotético): caída de SQL “caducados”, mejora en time to contact y aumento de respuesta a primer contacto al estar más cerca del momento de decisión.

En ambos mini-casos, el factor determinante no es la herramienta sino el control de calidad: motivos de rechazo normalizados, trazabilidad del motivo SQL y un loop de mejora con datos de pipeline.

Lista de verificación para implementar en 30 días

1. Definir en un documento operativo los criterios de MQL y SQL: eventos, atributos, ventanas temporales, exclusiones, y campo sql_reason obligatorio.

2. Revisar instrumentación: eventos clave en GA4/GTM, formularios, deduplicación de contactos, y mapeo de identificadores entre analítica y CRM sin datos personales en capas de datos.

3. Implementar scoring separado (perfil y comportamiento) con decaimiento temporal; fijar umbral y gates de encaje para promoción a SQL.

4. Configurar workflow de handoff: asignación, tarea con vencimiento, notificación, supresión de secuencias de nurturing no compatibles con fase SQL y estados de gestión.

5. Definir SLA de tiempos y campos mínimos: tiempo objetivo de primer contacto, razones de rechazo cerradas, y mecanismo de devolución a nurturing (recycled).

6. Montar dashboard mínimo: MQL rate, MQL→SQL, SQL aceptado/rechazado, time to contact, y SQL→Oportunidad por canal/campaña; revisar semanalmente con muestras de SQL y feedback estructurado.