Definición y Aceptación del SQL: A Qué se Compromete Realmente Ventas al Aceptar un Lead

Los leads están en Salesforce. Estado: SQL. Antigüedad: 17 días. Primer contacto: nunca.

Marketing ve el conteo de aceptados y piensa que el handoff funcionó. Ventas dice que los leads no eran buenos. Técnicamente nadie está equivocado, y ese es el problema. La aceptación ocurrió. La responsabilidad, no.

Un SQL sin un SLA de aceptación es solo una etiqueta. Cuando Ventas hace clic en "aceptar" en un lead, esa acción debe significar algo específico: un compromiso de actuar dentro de un período definido, con los próximos pasos definidos, o devolver el lead con un motivo documentado. Sin ese contrato, su handoff de MQL a SQL es teatro. Dos equipos actuando la alineación sin lograrla realmente.

Este artículo expone qué debe contener una definición de SQL, a qué obliga genuinamente la aceptación a Ventas y cómo documentar el acuerdo para que ambos lados puedan ser responsabilizados.

Datos Clave: Rendimiento del SQL y Calidad del Handoff

• Solo el 27% de los leads enviados a Ventas son contactados alguna vez, según investigación de MarketingSherpa sobre tasas de seguimiento de leads B2B.
• Las empresas con acuerdos formales de SLA entre Marketing y Ventas tienen 2,4 veces más probabilidades de reportar crecimiento de ingresos año tras año, según el informe State of Marketing de HubSpot.
• La empresa B2B promedio pierde el 71% de los leads de internet porque no se contactan con suficiente rapidez, según investigación de Drift y Heinz Marketing.
• Los leads contactados dentro de los 5 minutos de la consulta inicial tienen 21 veces más probabilidades de calificar que los leads contactados después de 30 minutos, según un estudio conjunto del MIT e InsideSales.com.
• El 61% de los especialistas en marketing B2B envían todos los leads directamente a Ventas, pero solo el 27% de esos leads están realmente calificados, según MarketingSherpa.

El Problema del Teatro de Aceptación

La definición de SQL de Gartner trata el estado de SQL como una transición de propiedad confirmada — pero la propiedad sin responsabilidad es la brecha que la mayoría de los equipos nunca cierra.

Así es como el teatro de aceptación se desarrolla en la mayoría de las empresas B2B:

Marketing pasa un lote de MQLs a Ventas al final de la semana. Ventas los acepta, porque el SLA dice que deben responder dentro de 48 horas. Pero "aceptar" significa hacer clic en un botón del CRM. No significa que el representante revisó el lead, investigó la empresa o planea llamar dentro de un período razonable.

Dos semanas después, Marketing saca el informe. Todos los MQLs fueron "aceptados". Bien. Excepto que solo 3 de 20 fueron contactados alguna vez. Los otros 17 ya están fríos.

Cuando Marketing plantea esto en la siguiente reunión de alineación, Ventas dice: "Esos leads no eran buenos." Marketing dice: "Los aceptaron." Ambos lados tienen técnicamente razón. Ninguno es responsable.

La causa raíz es definitoria. La mayoría de las empresas definen un SQL solo en términos de criterios para pasarlo: qué señales debe alcanzar un lead antes de que Ventas tome la propiedad. No definen lo que Ventas debe hacer a cambio. Esa asimetría es lo que hace que el handoff falle.

SQL vs. MQL: El Cambio de Propiedad

La transición de MQL a SQL no es solo un cambio de estado. Se supone que es una transferencia de propiedad.

Cuando un lead es un MQL, Marketing lo gestiona. Marketing decide si nurturarlo, acelerarlo o descalificarlo. Cuando un lead se convierte en SQL, Ventas lo gestiona. Ventas decide si avanzarlo, devolverlo o cerrarlo.

Pero la propiedad sin responsabilidad está vacía. Que Ventas "posea" un SQL debe significar algo operacionalmente. Significa:

• Ventas es responsable del primer contacto significativo
• Ventas debe avanzar el lead o rechazarlo dentro de un período definido
• El rechazo requiere un motivo documentado que retorna a Marketing

Hasta que defina lo que la propiedad requiere realmente, el handoff simplemente mueve un registro de la vista de un equipo a la de otro. Nada cambia en el destino del lead.

El proceso de handoff MQL a SQL cubre los mecanismos de esa transferencia. Este artículo se enfoca en lo que el compromiso de aceptación debe contener. Para el contexto más amplio del Funnel que ambos equipos comparten, el modelo de Funnel acordado define la propiedad en cada etapa.

La Definición de SQL en Dos Partes

El Marco de Definición SQL en Dos Partes

Una definición completa de SQL cubre dos compromisos igualmente vinculantes — criterios de calificación (qué hace que un lead esté listo para SQL) y compromisos de aceptación (qué debe hacer Ventas una vez que acepta). La mayoría de los equipos escriben la Parte 1 y omiten la Parte 2. Esa asimetría es donde los handoffs se rompen.

Parte 1: Criterios de calificación — las señales que hacen que un lead esté listo para SQL. Cubre ajuste (match con ICP, autoridad de compra), intención (solicitud de Demo, visita de precios) y timing (proyecto activo, alineación con ciclo presupuestario).

Parte 2: El SLA de aceptación — a qué se compromete Ventas al hacer clic en aceptar: primer contacto significativo dentro de 24 horas, intento de discovery dentro de 5 días hábiles, disposición (avanzar o devolver con motivo) dentro de 10 días hábiles.

Ambas partes viven en el mismo documento firmado. Una definición que solo cubre la Parte 1 es un handoff sin responsabilidad.

Una definición de SQL funcional tiene dos partes que la mayoría de los equipos solo construyen a medias:

Parte 1: Criterios de calificación: las señales que hacen que un lead esté listo para SQL. Esto es lo que la mayoría de los equipos escriben.

Parte 2: Compromisos de aceptación: a qué acuerda hacer Ventas una vez que acepta. Esto es lo que la mayoría de los equipos omiten.

Ambas partes deben vivir en el mismo acuerdo documentado. Una definición que solo cubre la Parte 1 le dice a quién hacer el handoff. No le dice qué hacer a continuación. Y sin la Parte 2, la aceptación sigue siendo una formalidad.

Parte 1: Criterios de Calificación

Los criterios de SQL deben cubrir tres categorías de señales: ajuste, intención y timing.

Señales de ajuste confirman que el lead está genuinamente en su mercado objetivo:

• Match con ICP en tamaño de empresa, industria, geografía — el marco de ICP compartido documenta cómo acordar estas dimensiones entre equipos
• Autoridad de compra confirmada o probable (el título indica rol de compra, o confirmación directa de presupuesto desde formulario/llamada)
• Compatibilidad de stack tecnológica (usan sistemas con los que su producto se integra, o están reemplazando un sistema que usted desplaza)

Señales de intención confirman interés activo de compra:

• Visitas a páginas de alto valor: precios, Demo, comparación, calculadora de ROI
• Solicitud explícita: Demo reservada, Trial iniciado, consulta directa
• Comportamiento de investigación competitiva: visitar contenido de comparación de competidores

Señales de timing confirman que existe una ventana de decisión activa:

• Campo de formulario que indica cronograma del proyecto ("evaluando ahora", "presupuesto Q2 asignado")
• Disparador de evento: renovación de contrato próxima, cambio de liderazgo, ronda de financiamiento
• Outreach inbound (se contactaron con usted, lo que implica cierto nivel de urgencia)

Ninguna señal única debe convertir automáticamente a un lead en SQL. Un lead que visitó su página de precios una vez y coincide con su ICP no necesariamente está listo para una conversación de ventas. Se quiere una combinación, típicamente ajuste más al menos una señal fuerte de intención o timing.

Lista de Verificación de Criterios SQL

Señales mínimas antes de que Ventas tome la propiedad:

• La empresa coincide con el ICP en al menos 2 de 3 criterios firmográficos (tamaño, industria, stack tecnológica)
• El contacto tiene probable autoridad de compra (VP o superior, o economic buyer confirmado)
• Al menos una señal de intención explícita (solicitud de Demo, visita de precios, consulta directa)
• Sin descalificadores activos (competidor, estudiante, geografía irrelevante)
• Fuente de lead capturada y verificada

Esta lista de verificación es un punto de partida. Calibrela con sus datos de closed-won. Si los leads que cumplen los cinco criterios cierran a una tasa materialmente más alta que los que cumplen tres, sus umbrales son aproximadamente correctos. Si los leads de cinco criterios cierran a la misma tasa que los de tres criterios, está sobre-filtrando.

El marco de definición de MQL cubre las decisiones de calificación en etapas más tempranas que alimentan este conjunto de criterios.

Parte 2: El SLA de Aceptación

Cuando Ventas acepta un SQL, se compromete a acciones específicas dentro de períodos de tiempo específicos. El SLA de aceptación define esos compromisos.

El SLA de primer contacto en 24 horas es el que la mayoría de los equipos no cumple. La investigación de HBR sobre leads de ventas online encontró que las empresas que intentaron contactar a clientes potenciales dentro de la primera hora de recibir una consulta tenían casi siete veces más probabilidades de calificar el lead que las que esperaron incluso una hora más.

Citable: Los equipos de ventas B2B que responden a leads inbound dentro de la primera hora de recibir una consulta tienen 7 veces más probabilidades de calificar el lead que los equipos que esperan incluso 60 minutos más, según investigación de HBR sobre tasas de respuesta a leads de ventas online. La diferencia entre 1 hora y 24 horas ya es significativa. Si su SLA de aceptación permite 48 horas para el primer contacto, está perdiendo Pipeline antes de que Ventas siquiera descuelgue el teléfono.

Para equipos que manejan solicitudes de Demo inbound, considere ajustar esto aún más. Un SLA de respuesta de cinco minutos es alcanzable para inbound de alta intención y cambia significativamente las tasas de conversión.

Escribir Criterios de SQL Que Su Equipo Realmente Usará

La definición de MQL de Gartner es una referencia útil aquí en la parte superior — los criterios de SQL que escriba en la parte inferior deben reflejar exactamente dónde termina la definición de MQL y la propiedad se transfiere a Ventas.

Las definiciones de SQL fallan por dos razones: son demasiado laxas (cualquier MQL cuenta como SQL) o demasiado rígidas (tantos criterios que pocos leads califican alguna vez, y Ventas se queja de que la definición es poco realista).

Una definición funcional es lo suficientemente específica para ser significativa y lo suficientemente flexible para dar cuenta de la variedad de leads reales.

Evite las definiciones binarias. En lugar de "el presupuesto debe estar confirmado", escriba "rango de presupuesto indicado en el formulario O el título sugiere autoridad presupuestaria (VP o superior)". Esto da cuenta de la realidad de que muchos compradores no revelan el presupuesto en la etapa de awareness.

Incorpore descalificadores explícitos. Los criterios negativos importan tanto como los positivos. Un lead que coincide perfectamente con su ICP pero es de un competidor directo, un estudiante o un país al que no da servicio debe fallar los criterios de SQL independientemente de sus señales de intención.

Use el lenguaje "probable" con cuidado. La autoridad de compra "probable" es un criterio válido para SQLs en muchos movimientos, especialmente inbound donde rara vez se confirma el presupuesto en el primer contacto. Pero "probable" requiere definición. "Título de Director o superior en la función relevante" es autoridad probable. "Cualquiera con un email empresarial" no lo es.

Establezca una puntuación mínima o un conteo de señales. Para equipos que usan lead scoring conjunto, defina la puntuación compuesta mínima requerida para el estado de SQL. Para equipos sin scoring formal, defina un conteo mínimo de señales (ej. "al menos 2 señales de ajuste y al menos 1 señal de intención").

La Capa SAL: Cuándo Ayuda, Cuándo No

Algunos equipos de revenue agregan una etapa de Sales Accepted Lead (SAL) entre MQL y SQL. La etapa SAL crea una breve ventana (típicamente 48-72 horas) para que Ventas revise el lead antes de comprometerse completamente con el SLA de SQL.

Cuándo el SAL aporta claridad:

• Inbound de alto volumen donde Ventas genuinamente necesita tiempo de revisión antes de comprometerse
• Equipos donde los criterios de calificación son complejos y requieren investigación en el CRM antes de la aceptación
• Organizaciones con auditorías formales de SLA donde el compromiso parcial es significativo

Cuándo el SAL solo agrega fricción:

• Equipos con criterios de ICP claros donde la revisión toma 2 minutos
• Entornos de bajo volumen donde cada lead vale una revisión completa de todos modos
• Organizaciones donde la etapa SAL se usa para retrasar la responsabilidad en lugar de habilitarla

Si agrega una etapa SAL, defina una ventana estricta (máximo 48 horas) y un requisito de disposición al final de esa ventana: aceptar al estado SQL o devolver con motivo. Un SAL que puede permanecer una semana no aporta ningún beneficio sobre un MQL. Las reglas de lead routing que su equipo aplica determinan qué representante recibe el lead una vez que supera la ventana SAL.

Qué Ocurre Cuando Ventas Rechaza un SQL

El rechazo es una señal valiosa, pero solo si está documentado correctamente.

Taxonomía de motivos de rechazo (códigos estructurados, no texto libre):

Los motivos de rechazo no estructurados ("no interesado", "lead malo") son inútiles para Marketing. No le dicen si la definición necesita actualización, si el programa de nurture falló o si Ventas está usando el rechazo para evitar el trabajo difícil.

Los códigos de motivo estructurados permiten a Marketing identificar patrones. Si el 40% de los rechazos de SQL regresan como R2 (empresa correcta, timing incorrecto), Marketing puede construir un disparador de re-engagement más rápido. Si el 30% regresan como R3 (fuera del ICP), la definición de MQL tiene un problema.

El proceso de rechazo y reciclaje de leads cubre qué pasa con los leads devueltos. Esta taxonomía alimenta directamente ese Workflow.

Documentar el Contrato SQL

La definición de SQL y el SLA de aceptación deben ser un documento escrito único, no un entendimiento verbal. Tanto el VP de Marketing como el VP de Ventas lo firman. Ambos equipos tienen acceso a él. Tiene un número de versión y una fecha de última revisión.

Estructura de la plantilla:

Contrato SQL — [Nombre de la Empresa]
Versión: [X.X]
Fecha de Vigencia: [Fecha]
Última Revisión: [Fecha]
Responsables: VP Marketing, VP Ventas

Sección 1: Criterios de Calificación SQL
- Señales de ajuste mínimas requeridas: [lista]
- Señales de intención mínimas requeridas: [lista]
- Descalificadores: [lista]
- Puntuación compuesta mínima (si aplica): [puntuación]

Sección 2: Compromisos de Aceptación
- SLA de primer contacto significativo: [período de tiempo]
- SLA de intento de discovery: [período de tiempo]
- Requisito de disposición: [período de tiempo y opciones]

Sección 3: Estándares de Rechazo
- Códigos de motivo: [taxonomía]
- Acciones de routing por código: [tabla]
- SLA de rechazo (feedback a Marketing): [período de tiempo]

Sección 4: Calendario de Revisión
- Reunión de calibración trimestral: [responsables, formato]
- Disparador para revisión fuera del ciclo: [condiciones]

El control de versiones importa. Cuando la definición cambia (porque su ICP se desplazó, un nuevo canal empezó a generar leads de diferente calidad, o los datos de calibración mostraron que los umbrales eran incorrectos) necesita un registro de qué cambió y por qué. Sin control de versiones, se siguen definiciones antiguas después de haber sido reemplazadas, y no puede diagnosticar brechas de rendimiento con respecto a la línea base correcta.

Análisis de Rework: Los equipos que formalizan una definición de SQL en dos partes — con tanto los criterios como los SLAs de aceptación documentados — típicamente cierran la brecha del teatro de aceptación en un trimestre. El indicador adelantado es la tasa de rechazo con códigos de motivo estructurados. Cuando los códigos R1–R6 se usan consistentemente, la conversión de MQL a SQL se estabiliza en 60 días porque Marketing puede enrutar los leads devueltos con precisión en lugar de re-pasar los mismos contactos descalificados. Comience con el SLA de aceptación antes de optimizar los criterios. El comportamiento antes que el scoring.

Medir la Calidad del SQL a lo Largo del Tiempo

Tres métricas le indican si su definición de SQL está funcionando:

Tasa de conversión SQL a oportunidad. Si menos del 60-70% de los SQLs se convierten en oportunidades, su definición es demasiado laxa. Está pasando leads que Ventas no puede avanzar. Si la conversión es muy alta (>90%) y el volumen es bajo, su definición puede ser demasiado estricta y está perdiendo Pipeline. Los benchmarks de conversión de lead a oportunidad del lado del Pipeline le dan la visión downstream de esta tasa.

Tasa de conversión SQL a closed-won. Rastree la tasa de cierre desde la etapa SQL, no solo desde la oportunidad. Si está creando muchas oportunidades a partir de SQLs pero cerrando pocas, el problema de calidad aparece una etapa después: los criterios de SQL están pasando leads con los que Ventas puede trabajar pero no cerrar. Aquí es donde los criterios de calificación de oportunidades se vuelven críticos — lo que Ventas acepta como SQL debe alinearse con lo que realmente puede avanzar.

Tasa de rechazo por código de motivo. Una tasa R3 creciente (fuera del ICP) significa que su calificación upstream se está desviando. Una tasa R2 creciente (empresa correcta, timing incorrecto) puede significar que Marketing está acelerando leads demasiado rápido, o que señala una oportunidad para programas de nurture basados en timing.

Revise estas métricas trimestralmente en la reunión de alineación que cubre el glosario de alineación marketing-ventas y las definiciones compartidas. Cuando los números se mueven, rastree de vuelta a la definición, no al equipo.

El Punto Final

Una definición de SQL sin compromisos de aceptación es un handoff sin responsabilidad. Marketing puede señalar los conteos de aceptados. Ventas puede señalar la calidad de los leads. Nadie es responsable de la brecha en el medio.

Escribir la definición en dos partes (criterios más compromisos) cierra esa brecha. Ventas sabe lo que significa aceptar antes de hacer clic en el botón. Marketing sabe qué esperar después del handoff. Cuando algo falla, el acuerdo le dice dónde.

Ambos equipos deben ser propietarios del documento. Ambos deben haber revisado los datos que informaron los umbrales. Y ambos deben sentir que la definición es justa, no una trampa para ningún lado.

Así es como la aceptación se convierte en un compromiso en lugar de una formalidad.

Preguntas Frecuentes

¿Cuál es la diferencia entre un MQL y un SQL?

Un MQL (Marketing Qualified Lead) es un lead que Marketing ha determinado que cumple con los criterios mínimos de ICP y engagement, haciéndolo digno de nurture hacia una conversación de ventas. Un SQL (Sales Qualified Lead) es un lead que ha superado un umbral más alto — ajuste confirmado, intención activa y señales de timing — y que Ventas ha aceptado la responsabilidad de trabajar. La diferencia de propiedad es la distinción clave: Marketing posee el MQL, Ventas posee el SQL.

¿A qué compromete realmente la aceptación del SQL a Ventas?

Cuando Ventas acepta un SQL, se compromete a acciones específicas dentro de períodos de tiempo definidos: un primer outreach significativo dentro de 24 horas, un intento de discovery dentro de 5 días hábiles y una disposición completa — avanzar a oportunidad o devolver con un motivo de rechazo estructurado — dentro de 10 días hábiles. La aceptación sin estos compromisos es teatro, no responsabilidad.

¿Qué debe pasar cuando Ventas rechaza un SQL?

Ventas debe devolver el lead con un código de motivo estructurado, no texto libre como "no es un buen fit". Una taxonomía de rechazo (ej. R1 = buyer persona incorrecto, R2 = sin proyecto activo, R3 = fuera del ICP) le dice a Marketing exactamente dónde ocurrió la falla para que pueda corregir la definición de MQL o construir mejores programas de nurture. Los motivos de rechazo no estructurados son inútiles para la mejora upstream.

¿Qué pasa si Ventas nunca contacta un SQL aceptado?

Este es el problema del teatro de aceptación — la aceptación ocurrió, la responsabilidad no. La solución es operacional: incorpore reporting de SLA en su CRM que marque los SQLs sin actividad de primer contacto después de 24 horas. Tanto el VP de Marketing como el VP de Ventas deben ver este informe semanalmente. Cuando los SLAs incumplidos aparecen en un Dashboard compartido, ambos equipos son responsables de la brecha.

¿Con qué frecuencia debe revisarse la definición de SQL?

Como mínimo, trimestralmente. La definición de SQL debe revisarse siempre que la conversión de SQL a oportunidad caiga más de 10 puntos porcentuales trimestre a trimestre, cuando un nuevo canal empiece a generar leads de calidad significativamente diferente, o cuando su ICP cambie. Controle las versiones del documento para poder diagnosticar brechas de rendimiento con respecto a la línea base correcta.

¿Qué es un SAL (Sales Accepted Lead) y cuándo debemos agregar esa etapa?

Un SAL es una etapa intermedia entre MQL y SQL que da a Ventas una breve ventana de revisión — típicamente 48–72 horas — para confirmar que un lead cumple con los criterios de SQL antes de comprometerse completamente con el SLA de aceptación. SAL agrega valor cuando los criterios de calificación son complejos y Ventas genuinamente necesita tiempo de investigación antes de comprometerse. Agrega fricción cuando se convierte en un buffer para el seguimiento lento. Si su etapa SAL consistentemente supera las 72 horas, elimínela.

¿Cómo calculamos el objetivo correcto de conversión SQL a oportunidad?

Extraiga de 3 a 6 meses de datos limpios del CRM. Cuente los SQLs por fecha de entrada y cuente las oportunidades creadas a partir de esos SQLs. Divida las oportunidades entre los SQLs para obtener su tasa base. Los benchmarks de SMB B2B oscilan entre 60–80%; mid-market entre 55–75%. Si está por debajo del 55%, su definición de SQL es demasiado laxa. Si está por encima del 90% pero el volumen es bajo, está sobre-filtrando y está perdiendo Pipeline.

Aprenda Más

• Marco de Definición de MQL
• Proceso de Handoff MQL a SQL
• Modelo de Funnel Acordado
• Rechazo y Reciclaje de Leads
• SLA de Respuesta de Cinco Minutos
• Calificación de Oportunidades
• Glosario de Alineación Marketing-Ventas