Plantilla de Acuerdo MQL/SQL: Un Contrato Listo para Copiar entre Marketing y Ventas

El VP de Ventas dice que los leads no están calificados. El CMO dice que ventas no hace seguimiento. Ambos tienen razón y ambos están equivocados, y ninguno puede demostrarlo porque no existe un acuerdo escrito que defina qué significa "calificado" o qué implica "hacer seguimiento".

Esto ocurre en la mayoría de las organizaciones de ingresos. La alineación existe como el recuerdo de una conversación, generalmente una reunión de inicio de Q1 donde ambos equipos asintieron ante una presentación y luego volvieron a operar con sus propias definiciones.

La alineación verbal no sobrevive al primer trimestre fallido. En el momento en que un deal se cierra en frío y alguien necesita asignar responsabilidades, la conversación que ocurrió siete meses atrás en una sala de conferencias no vale nada. Lo que se necesita es un documento firmado por ambas partes que defina el MQL, el SQL y exactamente qué debe cada equipo al otro en el límite del handoff.

Eso es lo que este artículo le entrega: la plantilla completa, lista para copiar.

Datos Clave: El Costo de las Definiciones Desalineadas

• Las empresas con procesos de marketing y ventas formalmente alineados experimentan un crecimiento de ingresos 24% más rápido durante tres años en comparación con las organizaciones desalineadas (Aberdeen Group).
• El 87% de los términos utilizados por los equipos de marketing y ventas para describir los leads difieren entre los dos departamentos dentro de la misma empresa (SiriusDecisions).
• Los equipos alineados logran una retención de clientes 36% mayor y tasas de cierre 38% más altas (MarketingProfs).
• Las organizaciones con un acuerdo documentado de definición de leads resuelven las disputas sobre MQL 55% más rápido y ven 20% menos MQLs rechazados dentro de dos trimestres (Demand Gen Report).
• Los equipos de ingresos con un acuerdo MQL/SQL escrito calibran sus modelos de scoring 2,4 veces más frecuentemente que los equipos que dependen de normas verbales, según la investigación de alineación de Forrester.

Qué Es (y No Es) un Acuerdo MQL/SQL

Un acuerdo MQL/SQL es un compromiso mutuo entre marketing y ventas que define vocabulario compartido, criterios compartidos y responsabilidad compartida en el límite del handoff de leads. Se revisa trimestralmente y es firmado por ambos líderes.

No es un documento de fiscalización. Marketing no lo usa para avergonzar a ventas por sus bajas tasas de aceptación. Ventas no lo usa para exigir perfección de marketing antes de contactar un lead. Es un documento de referencia. Ambos equipos lo consultan cuando hay un desacuerdo, y ambos lo actualizan cuando la realidad cambia.

Tampoco es una política estática. El acuerdo MQL/SQL debe ser un documento vivo con número de versión y una cadencia de revisión. Su marco de ICP compartido cambia. Su modelo conjunto de lead scoring cambia. Su equipo crece. El acuerdo debe reflejar la realidad actual, no el mundo tal como existía en el kickoff del año pasado.

Por Qué los Equipos con un Acuerdo Firmado Superan a los que No lo Tienen

La investigación es consistente: los artefactos de alineación escritos producen resultados de ingresos medibles. La definición de acuerdo de nivel de servicio de Wikipedia destaca el mismo principio: los SLA efectivos requieren que las partes se reúnan regularmente, apliquen mecanismos de responsabilidad y dejen espacio para revisiones periódicas. Eso es exactamente lo que hace un acuerdo MQL/SQL bien estructurado. Pero el mecanismo no es magia. Es especificidad.

Cuando ambos equipos han acordado un umbral mínimo de score de 65 (no "en algún lugar por encima de alto"), una ventana de aceptación de 4 horas hábiles (no "razonablemente rápido") y una lista de 6 códigos de razón de rechazo (no "solo díganos por qué"), cada conversación sobre un lead específico se convierte en una comparación con un estándar. Las discusiones sobre leads individuales se resuelven rápidamente porque el estándar es claro. Las discusiones sobre el estándar mismo son productivas. Producen calibración, no culpa.

El acuerdo también crea una base para las herramientas y procesos que lo rodean: el checklist de documentación del handoff, las reglas de enrutamiento de leads, la taxonomía de rechazo y el ciclo de retroalimentación funcionan mejor cuando las definiciones subyacentes son compartidas y están escritas.

Análisis de Rework: Los equipos con un acuerdo MQL/SQL firmado resuelven las disputas sobre leads 55% más rápido que los equipos que dependen de normas verbales, según la investigación de Demand Gen Report. El mecanismo es la especificidad: cuando ambos equipos han acordado un umbral de score de 65 (no "en algún lugar por encima de alto") y una ventana de aceptación de 4 horas hábiles (no "razonablemente rápido"), cada conversación sobre un lead rechazado se convierte en una comparación con un estándar escrito en lugar de un debate sobre recuerdos. El acuerdo también crea la base definitoria que hace que cada otra herramienta de alineación —documentación del handoff, reglas de enrutamiento, códigos de rechazo, la llamada semanal de calidad de leads— sea operativamente coherente. Sin él, cada una de esas herramientas se construye sobre un conjunto diferente de supuestos tácitos. En el propio análisis de Rework sobre configuraciones de equipos de ingresos, la presencia o ausencia de un acuerdo MQL/SQL escrito es el predictor más sólido de si las revisiones de calidad de leads de un equipo producen mejoras en el modelo de scoring o producen ciclos de culpa.

---

LA PLANTILLA — Acuerdo MQL/SQL

Copie la sección a continuación, complete los valores de su organización donde aparecen corchetes y preséntela a ambos líderes para su aprobación. Esta plantilla está diseñada para equipos B2B SaaS de pequeñas y medianas empresas con un ICP definido y un flujo de trabajo de leads basado en CRM.

---

ACUERDO MQL/SQL

Organización: [Nombre de la Empresa] Fecha de Vigencia: [Fecha] Versión: 1.0 Cadencia de Revisión: Trimestral (próxima revisión: [Fecha + 90 días]) Propietario del Documento: [Responsable de RevOps o VP de Ingresos]

---

SECCIÓN A — PARTES Y PROPÓSITO

Este acuerdo es celebrado por:

• Equipo de Marketing, representado por [Nombre del CMO / VP de Marketing]
• Equipo de Ventas, representado por [Nombre del CRO / VP de Ventas]
• Revenue Operations, como testigo y propietario del proceso, representado por [Nombre del Responsable de RevOps]

Propósito: Establecer definiciones compartidas de Marketing Qualified Lead (MQL) y Sales Qualified Lead (SQL), definir las obligaciones de ambos equipos en el límite del handoff y crear un proceso estructurado de retroalimentación y calibración.

Este acuerdo reemplaza todos los entendimientos verbales o informales anteriores sobre los criterios de calificación de leads.

---

SECCIÓN B — DEFINICIÓN Y CRITERIOS DEL MQL

Un lead alcanza el estado de MQL cuando se cumplen todas las siguientes condiciones:

B.1 — Criterios Mínimos de Adecuación al ICP (todos requeridos)

B.2 — Umbral Mínimo de Score

El lead score debe alcanzar [Ej., 65] o más en el score combinado de adecuación + comportamiento.

Peso del sub-score de adecuación: [Ej., 40%] Peso del sub-score de comportamiento: [Ej., 60%]

B.3 — Disparador de Comportamiento Requerido

Al menos una de las siguientes señales de comportamiento debe estar presente en los últimos [Ej., 30] días:

• Solicitó una demo o prueba gratuita
• Visitó la página de precios [Ej., 2+] veces
• Visitó la página de integraciones o documentación técnica
• Asistió a un webinar en vivo o evento de producto
• Abrió y hizo clic en [Ej., 3+] correos de marketing en una ventana de 14 días
• Envió un formulario de contacto con una pregunta o caso de uso específico

B.4 — Exclusiones de MQL

Los siguientes leads no califican como MQL independientemente del score:

• Clientes existentes (enrutar al CSM)
• Leads con oportunidades activas abiertas (enrutar al AE responsable)
• Competidores (enrutar a la cola de inteligencia competitiva)
• Buscadores de empleo, estudiantes o instituciones académicas
• Dominios de correo personal (gmail.com, yahoo.com, etc.) a menos que el nombre de la empresa y el teléfono estén verificados
• Contactos marcados como no suscritos o no contactar

---

SECCIÓN C — DEFINICIÓN DEL SQL Y CRITERIOS DE ACEPTACIÓN

Un lead alcanza el estado de SQL cuando un representante de ventas confirma todo lo siguiente:

C.1 — Criterios de Aceptación

C.2 — Ventana de Aceptación

Ventas debe aceptar o rechazar cada MQL dentro de [Ej., 4] horas hábiles de la notificación del handoff.

Para MQLs de Nivel 1 (solicitudes de demo, visitas a la página de precios): aceptación o rechazo dentro de [Ej., 1] hora hábil.

C.3 — Cómo Se Registra la Aceptación

La aceptación se registra cambiando el estado del lead de "MQL — Pendiente" a "SQL — Aceptado" en [Nombre del CRM].

Si el representante no puede contactar al lead dentro de [Ej., 3] días hábiles utilizando los requisitos de persistencia de contacto de la Sección E.2, el estado del lead cambia a "SQL — Sin Respuesta" y regresa a marketing para su decisión.

---

SECCIÓN D — OBLIGACIONES DEL HANDOFF: MARKETING

Marketing se compromete a entregar lo siguiente en cada handoff de MQL:

D.1 — Completitud de Datos

D.2 — Momento del Handoff

Disparador de MQL a handoff en CRM: dentro de [Ej., 15] minutos para rutas automatizadas. Enrutamiento en horario hábil: inmediato. Enrutamiento fuera de horario: antes de las [Ej., 8am hora local] del siguiente día hábil.

D.3 — Disparador de Enrutamiento

Los leads que cumplen los criterios de MQL de la Sección B se enrutan automáticamente según las reglas documentadas en [enlace al documento de Reglas de Enrutamiento].

Marketing notificará a RevOps dentro de 1 día hábil de cualquier campaña que se espere genere más de 50 MQLs en un solo día, para permitir la planificación de capacidad de los representantes.

---

SECCIÓN E — OBLIGACIONES DEL HANDOFF: VENTAS

Ventas se compromete a lo siguiente para cada MQL recibido:

E.1 — SLA de Respuesta por Nivel

Horas hábiles definidas como: [Ej., 8am–6pm, lunes a viernes, en la zona horaria local del lead].

E.2 — Requisitos de Persistencia de Contacto

Antes de marcar un lead como "Sin Respuesta", ventas debe realizar un mínimo de:

• [Ej., 6] intentos de contacto durante [Ej., 10] días hábiles
• Al menos [Ej., 2] intentos telefónicos
• Al menos [Ej., 3] intentos por correo electrónico
• Al menos [Ej., 1] mensaje de LinkedIn o InMail (para leads de medianas y grandes empresas)
• Los intentos deben realizarse en [Ej., 3+] días distintos — no todos en un mismo día

E.3 — Requisitos de Rechazo

Si se rechaza un lead:

• El representante debe seleccionar un código de razón en [Nombre del CRM] antes de que se procese el rechazo
• Códigos de razón válidos: No es ICP | Sin señal de presupuesto | Contacto equivocado | Mal momento | Problema de calidad de datos | Cliente existente / oportunidad abierta
• Hay disponible una nota de texto libre opcional para contexto adicional
• No se permiten rechazos silenciosos — los leads no pueden abandonarse sin una disposición

E.4 — Retroalimentación a Marketing

• Asistir a la llamada semanal de calidad de leads ([enlace a la reunión o invitación del calendario])
• Enviar [Ej., 2] notas de win/loss por mes usando [formulario de Win/Loss o canal de Slack]
• Señalar anomalías en el scoring (leads con score alto que consistentemente fallan en la calificación) dentro de [Ej., 3] días hábiles a RevOps

---

SECCIÓN F — REGLAS DE RECICLAJE

F.1 — Disposición del Rechazo por Código de Razón

F.2 — Requisitos de Re-ingreso

Un lead reciclado puede re-calificarse como MQL solo cuando:

1. El período de enfriamiento ha transcurrido (mínimo [Ej., 30] días; [Ej., 90] días para "No es ICP")
2. Ha ocurrido un nuevo disparador de comportamiento (no es una continuación de la actividad previa al rechazo)
3. Cualquier lead reciclado más de dos veces requiere revisión humana por parte de marketing ops antes de volver a entrar en la cola de MQL

F.3 — Cronograma de Reasignación a Nurture

Marketing se compromete a colocar los leads reciclados en la pista de nurture apropiada dentro de [Ej., 5] días hábiles del rechazo.

---

SECCIÓN G — REVISIÓN Y ENMIENDA

G.1 — Revisión Trimestral

Este acuerdo se revisa trimestralmente. Propietario de la reunión de revisión: [Responsable de RevOps]. Participantes: CMO/VP de Marketing + CRO/VP de Ventas + RevOps. Agenda: Tendencias en tasas de rechazo, datos de conversión de reciclaje, propuestas de calibración del scoring, enmiendas a definiciones.

G.2 — Proceso de Enmienda

Cualquiera de las partes puede proponer una enmienda enviando una solicitud escrita al propietario de RevOps con datos de respaldo. Las enmiendas se ratifican cuando ambos signatarios aprueban por escrito (se acepta confirmación por correo electrónico).

Los cambios entran en vigor [Ej., 30] días después de la ratificación para permitir actualizaciones en los sistemas.

G.3 — Control de Versiones

Todas las versiones archivadas en [enlace a unidad compartida o wiki]. La versión actual siempre accesible en [enlace].

---

FIRMAS

---

Cómo Personalizar la Plantilla

La plantilla anterior está redactada para un equipo B2B SaaS típico de pequeñas o medianas empresas con 3-15 representantes, un ICP definido y un stack de CRM + MAP. A continuación se explica cómo adaptarla a su situación:

Si usted es un equipo de producto único y alta velocidad (menos de 50 empleados): Simplifique las Secciones B y C. Es posible que no necesite sub-scores ni disparadores de comportamiento más allá de "demo solicitada". Mantenga la ventana de aceptación ajustada: menos de 2 horas para todo.

Si usted es un equipo con múltiples productos: Agregue un campo de línea de producto a la Sección B.1 y una nota de enrutamiento a la Sección D.3. Los representantes que se especializan en el Producto A no deben recibir leads del Producto B por defecto.

Si usted ejecuta un proceso enterprise con ciclos largos: Amplíe la ventana de aceptación en la Sección C.2 (4-8 horas es adecuado para enterprise). Refuerce la persistencia de contacto en la Sección E.2 (8-12 intentos durante 15-20 días). Agregue un disparador de re-ingreso al nurture para rechazos por "momento del ciclo presupuestario" en la Sección F.

Si usted tiene un equipo de partners o canal: Agregue una Sección H para leads provenientes de partners con reglas de enrutamiento y aceptación separadas. Los leads de partners a menudo implican obligaciones de venta conjunta que las reglas estándar no contemplan.

Cómo Lograr que Ambos Equipos lo Firmen

El enfoque de facilitación importa tanto como el documento. Dos opciones:

Taller conjunto (recomendado para primeros acuerdos): Sesión de dos horas con ambos líderes y RevOps. Trabajen cada sección juntos. Donde haya desacuerdo (generalmente en el umbral del score, la ventana de aceptación o la granularidad de los códigos de rechazo), trabajen a partir de datos. Extraigan los últimos 90 días de datos de MQL y rechazo y dejen que los números guíen la negociación.

Revisión asíncrona (para actualizaciones de acuerdos existentes): Circulen el borrador, permitan que cada equipo haga sus modificaciones, y traigan los términos en conflicto a una llamada de decisión de 30 minutos. Funciona bien para enmiendas trimestrales cuando la relación ya está establecida.

Puntos de Negociación Comunes

Disputas sobre el umbral del score. Marketing quiere 60. Ventas quiere 80. La respuesta honesta es que ninguna de las partes lo sabe. Necesita datos. Extraiga los últimos 90 días de MQLs y calcule la tasa de conversión por banda de score en incrementos de 5 puntos. El umbral del score cae naturalmente en el punto donde la tasa de conversión cambia de forma significativa. El análisis de umbrales de score de MQL proporciona los benchmarks de referencia para esta negociación.

Debates sobre la ventana de aceptación. Ventas dice que no puede responder en 2 horas porque está en demos todo el día. La solución es escalonada: 15 minutos para el Nivel 1 (solicitudes de demo), 2 horas para el Nivel 2, 1 día para el Nivel 3. Dé a los representantes ventanas realistas para leads de menor intención sin sacrificar la velocidad de respuesta en los de alta intención.

Granularidad de las razones de rechazo. Ventas quiere un solo campo: "lead malo". Marketing quiere 20 códigos. Acuerden entre 5-7 códigos que separen de forma significativa los rechazos accionables (mal momento, contacto equivocado) de los no accionables (no es ICP). Más de 7 códigos reduce el cumplimiento. Los representantes dejan de seleccionar con cuidado cuando la lista es larga.

Después de la Firma: Hacer el Acuerdo Operativo

Guarde el acuerdo firmado en su wiki compartido, base de conocimientos del CRM o unidad del equipo: en algún lugar al que ambos equipos enlacen desde sus documentos de onboarding. Refiérase a él en la agenda de la llamada semanal de calidad de leads.

Cuando surja una disputa, abra el documento y encuentre la sección relevante antes de que el argumento escale. La mayoría de las disputas se resuelven en el texto. Alguien está operando con una versión diferente del acuerdo en su cabeza.

Señales de Alerta de que el Acuerdo Está Desactualizado

• Las tasas de rechazo para un código de razón específico superan el 30% durante dos meses consecutivos
• El umbral del score produce un volumen de MQL que consistentemente está por encima o por debajo del objetivo
• Los representantes aceptan MQLs rutinariamente y luego los marcan inmediatamente como "Sin Respuesta" sin intentar contacto (una señal de que la ventana de aceptación es demasiado ajustada en relación con la capacidad real)
• Marketing cambia una campaña o modelo de scoring sin notificar a RevOps; cualquier cambio de scoring que desplace el volumen de MQL en más del 15% debería desencadenar una revisión de emergencia

Preguntas Frecuentes

¿Cómo se implementa el acuerdo MQL/SQL sin que se convierta en una pelea política?

Enmarquelo como una herramienta de calibración, no como un documento de cumplimiento. El enfoque de implementación más efectivo es un taller conjunto de dos horas con ambos líderes y RevOps, trabajando en cada sección con los datos de MQL y rechazo de los últimos 90 días. Donde los equipos no estén de acuerdo —generalmente en el umbral del score y la ventana de aceptación— deje que los datos de conversión decidan, no la jerarquía. Los equipos que negocian a partir de datos en lugar de opiniones llegan a un acuerdo 3-4 veces más rápido y producen acuerdos que se sostienen más tiempo porque ambas partes vieron los mismos números.

¿Qué hacer si ventas no quiere firmar el acuerdo MQL/SQL?

La resistencia de ventas generalmente señala una de dos cosas: el umbral del score parece demasiado bajo (ventas no confía en los leads) o la ventana de aceptación parece poco realista dada la capacidad actual de los representantes. Ambas son solucionables con datos. Para la resistencia al umbral del score, extraiga la tasa de conversión por banda de score en incrementos de 5 puntos: la discusión sobre el umbral se vuelve empírica. Para la resistencia a la ventana de aceptación, escalone el requisito: 15 minutos para solicitudes de demo, 4 horas para todo lo demás. Firmar un SLA escalonado es más fácil que firmar uno global. Si la resistencia persiste, pida a ventas que proponga su propio umbral con datos de respaldo. El acto de construir el argumento a menudo cambia la dinámica de oposición a co-propiedad.

¿Con qué frecuencia debe revisarse el acuerdo MQL/SQL?

La revisión trimestral es el mínimo. Pero tres eventos deben desencadenar una revisión inmediata fuera de ciclo: un cambio de campaña o modelo de scoring que desplace el volumen de MQL en más del 15%, un aumento de la tasa de rechazo por encima del 30% para un código de razón específico durante dos meses consecutivos, y cualquier cambio significativo en el ICP (nuevo segmento agregado, segmento existente des-priorizado). La revisión trimestral es para el ajuste. Las revisiones desencadenadas son para detectar la deriva antes de que se acumule en un trimestre fallido.

¿Quién es el propietario del documento del acuerdo MQL/SQL?

RevOps es el propietario del documento, el control de versiones y el calendario de revisiones. Marketing y ventas son propietarios de sus respectivas secciones. El responsable de RevOps es el dueño del proceso que dirige la revisión trimestral, gestiona las solicitudes de enmienda y mantiene a ambas partes comprometidas con la cadencia acordada. Sin un propietario neutral, el acuerdo se actualiza unilateralmente por quien esté bajo más presión, lo que anula su propósito como referencia compartida.

¿En qué valor debe fijarse el umbral del score?

No existe un umbral universal. Extraiga los deals cerrados como ganados de los últimos 90 días y rastree cada uno hasta su lead score original en el momento del handoff como MQL. Encuentre la banda de score donde la tasa de conversión sube de forma significativa por encima de su promedio general: ese punto de inflexión es su ancla de umbral empírico. Los equipos con menos de 90 días de datos deben comenzar en 60 y ajustar según la retroalimentación de la tasa de rechazo después del primer mes completo. Una tasa de rechazo superior al 35% sugiere que el umbral es demasiado bajo. Una tasa de rechazo inferior al 10% sugiere que puede ser demasiado permisivo (demasiados leads no calificados que califican).

Aprenda Más

• Proceso de Handoff MQL a SQL
• Marco de Definición de MQL
• Definición y Aceptación de SQL
• Checklist de Documentación del Handoff
• Plantilla de SLA de Marketing y Ventas
• Glosario de Alineación de Marketing y Ventas