Modelo de Acordo MQL/SQL: Um Contrato Para Copiar Entre Marketing e Vendas

O VP de Vendas diz que os leads não são qualificados. O CMO diz que vendas não está fazendo o follow-up. Os dois têm razão, os dois estão errados, e nenhum consegue provar seu ponto porque não existe um acordo escrito que defina o que significa "qualificado" ou o que "fazer follow-up" exige.

Isso acontece na maioria das organizações de receita. O alinhamento existe como memória de uma conversa — geralmente um kickoff de Q1 em que as duas equipes balançaram a cabeça para uma apresentação e depois voltaram a operar com suas próprias definições.

Alinhamento verbal não sobrevive ao primeiro trimestre perdido. No momento em que um deal esfria e alguém precisa atribuir culpa, a conversa que aconteceu sete meses atrás numa sala de reunião não vale nada. O que você precisa é de um documento assinado por ambos os lados, que defina MQL, defina SQL e especifique exatamente o que cada equipe deve à outra na fronteira do handoff.

É isso que este artigo oferece: o modelo completo, pronto para copiar.

Fatos Relevantes: O Custo das Definições Desalinhadas

• Empresas com processos formalmente alinhados entre marketing e vendas têm crescimento de receita 24% mais rápido ao longo de três anos em comparação com organizações desalinhadas (Aberdeen Group).
• 87% dos termos usados por equipes de marketing e vendas para descrever leads diferem entre os dois departamentos na mesma empresa (SiriusDecisions).
• Equipes alinhadas alcançam 36% mais retenção de clientes e 38% mais win rates (MarketingProfs).
• Organizações com um acordo de definição de lead documentado resolvem disputas de MQL 55% mais rápido e veem 20% menos MQLs rejeitados dentro de dois trimestres (Demand Gen Report).
• Equipes de receita com um acordo escrito de MQL/SQL calibram os modelos de scoring 2,4x mais frequentemente do que equipes que dependem de normas verbais, de acordo com pesquisas de alinhamento da Forrester.

O Que É (e o Que Não É) um Acordo MQL/SQL

Um acordo MQL/SQL é um compromisso mútuo entre marketing e vendas que define vocabulário compartilhado, critérios compartilhados e responsabilidades compartilhadas na fronteira do handoff de leads. Ele é revisado trimestralmente e assinado por ambos os líderes.

Não é um documento de fiscalização. Marketing não usa o acordo para envergonhar vendas por taxas baixas de aceitação. Vendas não usa para exigir perfeição de marketing antes de tocar em um lead. É um documento de referência. As duas equipes apontam para ele quando há uma divergência, e as duas equipes o atualizam quando a realidade muda.

Também não é uma política estática. O acordo MQL/SQL deve ser um documento vivo, com número de versão e cadência de revisão. Seu framework de ICP compartilhado muda. Seu modelo de lead scoring conjunto muda. Sua equipe cresce. O acordo deve refletir a realidade atual, não o mundo como era no kickoff do ano passado.

Por Que Equipes Com um Acordo Assinado Superam Equipes Sem Um

A pesquisa é consistente: artefatos de alinhamento escritos produzem resultados de receita mensuráveis. A definição de acordo de nível de serviço da Wikipedia destaca o mesmo princípio — SLAs eficazes exigem que as partes se reúnam regularmente, apliquem mecanismos de responsabilidade e deixem espaço para revisão periódica. É exatamente o que um acordo MQL/SQL bem estruturado faz. Mas o mecanismo não é mágico. É a especificidade.

Quando as duas equipes concordaram em um limite de score mínimo de 65 (não "em torno de alto"), uma janela de aceitação de 4 horas úteis (não "razoavelmente rápido") e uma lista de 6 códigos de motivo de rejeição (não "só nos diga o porquê"), cada conversa sobre um lead específico se torna uma comparação com um padrão. Disputas sobre leads individuais se resolvem rapidamente porque o padrão é claro. Disputas sobre o próprio padrão são produtivas — geram calibração, não culpa.

O acordo também cria uma base para as ferramentas e processos que o cercam: o checklist de documentação do handoff, as regras de roteamento de leads, a taxonomia de rejeição e o ciclo de feedback funcionam melhor quando as definições subjacentes são compartilhadas e estão por escrito.

Análise Rework: Equipes com um acordo MQL/SQL assinado resolvem disputas de leads 55% mais rápido do que equipes que dependem de normas verbais, de acordo com pesquisas do Demand Gen Report. O mecanismo é a especificidade: quando as duas equipes concordaram com um limite de score de 65 (não "em torno de alto") e uma janela de aceitação de 4 horas úteis (não "razoavelmente rápido"), cada conversa sobre um lead rejeitado se torna uma comparação com um padrão escrito, não um debate sobre memória. O acordo também cria a base definitória que torna cada outra ferramenta de alinhamento — documentação de handoff, regras de roteamento, códigos de rejeição, a chamada semanal de qualidade de leads — operacionalmente coerente. Sem ele, cada uma dessas ferramentas é construída sobre um conjunto diferente de suposições não declaradas. Na análise própria da Rework sobre configurações de equipes de receita, a presença ou ausência de um acordo MQL/SQL escrito é o preditor mais forte de se as revisões de qualidade de leads de uma equipe produzem melhorias no modelo de scoring ou produzem ciclos de culpa.

---

O MODELO — Acordo MQL/SQL

Copie a seção abaixo, preencha os valores da sua organização onde aparecem colchetes e apresente a ambos os líderes para aprovação. Este modelo foi criado para equipes B2B SaaS de SMB e mid-market com um ICP definido e um fluxo de trabalho de leads baseado em CRM.

---

ACORDO MQL/SQL

Organização: [Nome da Empresa] Data de Vigência: [Data] Versão: 1.0 Cadência de Revisão: Trimestral (próxima revisão: [Data + 90 dias]) Proprietário do Documento: [Líder de RevOps ou VP de Receita]

---

SEÇÃO A — PARTES E PROPÓSITO

Este acordo é firmado entre:

• Equipe de Marketing, representada por [Nome do CMO / VP de Marketing]
• Equipe de Vendas, representada por [Nome do CRO / VP de Vendas]
• Revenue Operations, como testemunha e proprietária do processo, representada por [Nome do Líder de RevOps]

Propósito: Estabelecer definições compartilhadas de Marketing Qualified Lead (MQL) e Sales Qualified Lead (SQL), definir as obrigações de ambas as equipes na fronteira do handoff e criar um processo estruturado de feedback e calibração.

Este acordo substitui todos os entendimentos verbais ou informais anteriores sobre critérios de qualificação de leads.

---

SEÇÃO B — DEFINIÇÃO E CRITÉRIOS DE MQL

Um lead atinge o status de MQL quando todas as seguintes condições são atendidas:

B.1 — Critérios Mínimos de Fit de ICP (todos obrigatórios)

B.2 — Limite Mínimo de Score

O score do lead deve atingir [ex.: 65] ou mais na pontuação combinada de fit + comportamento.

Peso do sub-score de fit: [ex.: 40%] Peso do sub-score de comportamento: [ex.: 60%]

B.3 — Gatilho Comportamental Obrigatório

Pelo menos um dos seguintes sinais comportamentais deve estar presente nos últimos [ex.: 30] dias:

• Solicitou uma demo ou avaliação gratuita
• Visitou a página de preços [ex.: 2+] vezes
• Visualizou a página de integrações ou documentação técnica
• Participou de um webinar ao vivo ou evento de produto
• Abriu e clicou em [ex.: 3+] e-mails de marketing em uma janela de 14 dias
• Enviou um formulário de contato com uma pergunta ou caso de uso específico

B.4 — Exclusões de MQL

Os seguintes leads não se qualificam como MQL independentemente do score:

• Clientes existentes (encaminhar ao CSM)
• Leads com oportunidades abertas ativas (encaminhar ao AE responsável)
• Concorrentes (encaminhar à fila de inteligência competitiva)
• Candidatos a emprego, estudantes ou instituições acadêmicas
• Domínios de e-mail pessoal (gmail.com, yahoo.com, etc.) a menos que nome da empresa e telefone sejam verificados
• Contatos marcados como descadastrados ou não contatáveis

---

SEÇÃO C — DEFINIÇÃO E CRITÉRIOS DE ACEITAÇÃO DE SQL

Um lead atinge o status de SQL quando um representante de vendas confirma todos os seguintes itens:

C.1 — Critérios de Aceitação

C.2 — Janela de Aceitação

Vendas deve aceitar ou rejeitar cada MQL dentro de [ex.: 4] horas úteis após a notificação de handoff.

Para MQLs Tier 1 (solicitações de demo, visitas à página de preços): aceitação ou rejeição dentro de [ex.: 1] hora útil.

C.3 — Como a Aceitação É Registrada

A aceitação é registrada alterando o status do lead de "MQL — Pendente" para "SQL — Aceito" em [Nome do CRM].

Se o representante não conseguir contato com o lead dentro de [ex.: 3] dias úteis usando os requisitos de persistência de contato da Seção E.2, o status do lead muda para "SQL — Sem Resposta" e retorna ao marketing para decisão.

---

SEÇÃO D — OBRIGAÇÕES DO HANDOFF: MARKETING

Marketing se compromete a entregar o seguinte em cada handoff de MQL:

D.1 — Completude de Dados

D.2 — Tempo do Handoff

Do gatilho de MQL ao handoff no CRM: dentro de [ex.: 15] minutos para rotas automatizadas. Roteamento em horário comercial: imediato. Roteamento fora do horário: até [ex.: 8h no horário local] do próximo dia útil.

D.3 — Gatilho de Roteamento

Leads que atendem aos critérios de MQL da Seção B são roteados automaticamente com base nas regras de roteamento documentadas em [link do documento de Regras de Roteamento].

Marketing notificará RevOps com 1 dia útil de antecedência de qualquer campanha que gere >50 MQLs em um único dia, para permitir o planejamento de capacidade dos representantes.

---

SEÇÃO E — OBRIGAÇÕES DO HANDOFF: VENDAS

Vendas se compromete com o seguinte para cada MQL recebido:

E.1 — SLA de Resposta por Tier

Horário comercial definido como: [ex.: 8h–18h, Seg–Sex, no fuso horário local do lead].

E.2 — Requisitos de Persistência de Contato

Antes de marcar um lead como "Sem Resposta", vendas deve fazer no mínimo:

• [ex.: 6] tentativas de contato ao longo de [ex.: 10] dias úteis
• Pelo menos [ex.: 2] tentativas por telefone
• Pelo menos [ex.: 3] tentativas por e-mail
• Pelo menos [ex.: 1] mensagem ou InMail no LinkedIn (para leads de mid-market e enterprise)
• As tentativas devem ocorrer em [ex.: 3+] dias distintos — não todas no mesmo dia

E.3 — Requisitos de Rejeição

Se um lead for rejeitado:

• O representante deve selecionar um código de motivo em [Nome do CRM] antes da rejeição ser processada
• Códigos de motivo válidos: Não é fit de ICP | Sem sinal de orçamento | Contato errado | Timing ruim | Problema de qualidade de dados | Cliente existente / oportunidade aberta
• Nota de texto livre opcional disponível para contexto
• Sem rejeições silenciosas — leads não podem ser abandonados sem uma disposição

E.4 — Feedback Para Marketing

• Participar da chamada semanal de qualidade de leads ([link da reunião ou convite de calendário])
• Enviar [ex.: 2] notas de win/loss por mês usando [formulário de Win/Loss ou canal Slack]
• Sinalizar anomalias de scoring (leads com score alto que consistentemente falham na qualificação) dentro de [ex.: 3] dias úteis para RevOps

---

SEÇÃO F — REGRAS DE RECICLAGEM

F.1 — Disposição de Rejeição por Código de Motivo

F.2 — Requisitos de Reentrada

Um lead reciclado pode se requalificar como MQL somente quando:

1. O período de espera passou (mínimo de [ex.: 30] dias; [ex.: 90] dias para "Não é fit de ICP")
2. Um novo gatilho comportamental ocorreu (não uma continuação da atividade pré-rejeição)
3. Qualquer lead reciclado mais de duas vezes requer revisão humana pelo marketing ops antes de reentrar na fila de MQL

F.3 — Prazo de Reatribuição de Nurture

Marketing se compromete a colocar leads reciclados na trilha de nurture apropriada dentro de [ex.: 5] dias úteis após a rejeição.

---

SEÇÃO G — REVISÃO E ALTERAÇÃO

G.1 — Revisão Trimestral

Este acordo é revisado trimestralmente. Responsável pela reunião de revisão: [Líder de RevOps]. Participantes: CMO/VP de Marketing + CRO/VP de Vendas + RevOps. Pauta: Tendências de taxas de rejeição, dados de conversão de reciclagem, propostas de calibração de score, eventuais alterações de definição.

G.2 — Processo de Alteração

Qualquer parte pode propor uma alteração enviando uma solicitação escrita ao proprietário de RevOps com dados de suporte. As alterações são ratificadas quando ambos os signatários abaixo aprovam por escrito (confirmação por e-mail é aceitável).

As mudanças entram em vigor [ex.: 30] dias após a ratificação, para permitir atualizações nos sistemas.

G.3 — Controle de Versão

Todas as versões arquivadas em [link do drive compartilhado ou wiki]. A versão atual sempre acessível em [link].

---

ASSINATURAS

---

Como Personalizar o Modelo

O modelo acima foi escrito para uma equipe B2B SaaS típica de SMB ou mid-market com 3 a 15 representantes, um ICP definido e um stack de CRM + MAP. Veja como adaptá-lo para a sua situação:

Se você é uma equipe de produto único e alta velocidade (menos de 50 funcionários): Simplifique as Seções B e C. Talvez você não precise de sub-scores ou gatilhos comportamentais além de "demo solicitada". Mantenha a janela de aceitação curta: menos de 2 horas para tudo.

Se você é uma equipe de múltiplos produtos: Adicione um campo de linha de produto à Seção B.1 e uma nota de roteamento à Seção D.3. Representantes especializados no Produto A não devem receber leads do Produto B por padrão.

Se você opera com um movimento enterprise de ciclos longos: Amplie a janela de aceitação na Seção C.2 (4–8 horas é adequado para enterprise). Reforce a persistência de contato na Seção E.2 (8–12 tentativas em 15–20 dias). Adicione um gatilho de reentrada de nurture para rejeições de timing de "ciclo orçamentário" na Seção F.

Se você tem uma equipe de parceiros ou canal: Adicione uma Seção H para leads provenientes de parceiros, com regras separadas de roteamento e aceitação. Leads de parceiros frequentemente envolvem obrigações de co-venda que as regras padrão não cobrem.

Como Fazer as Duas Equipes Assinarem

A abordagem de facilitação importa tanto quanto o documento. Duas opções:

Workshop conjunto (recomendado para primeiros acordos): Sessão de duas horas com ambos os líderes e RevOps. Trabalhe cada seção juntos. Onde houver divergência — geralmente em limite de score, janela de aceitação ou granularidade de código de rejeição — trabalhe com dados. Puxe seus últimos 90 dias de MQL e dados de rejeição e deixe os números guiar a negociação.

Redline assíncrono (para atualizações de acordos existentes): Circule o rascunho, deixe cada equipe fazer edições em suas seções, leve os termos conflitantes a uma chamada de decisão de 30 minutos. Funciona bem para alterações trimestrais quando o relacionamento já está estabelecido.

Pontos de Negociação Comuns

Batalhas sobre o limite de score. Marketing quer 60. Vendas quer 80. A resposta honesta é que nenhuma das partes sabe. Você precisa de dados. Puxe os últimos 90 dias de MQLs e calcule a taxa de conversão por faixa de score em incrementos de 5 pontos. O limite de score cai naturalmente no ponto onde a taxa de conversão muda de forma significativa. Sua análise de limites de score MQL fornece os benchmarks de referência para essa negociação.

Debates sobre a janela de aceitação. Vendas diz que não consegue responder em 2 horas porque estão em demos o dia todo. A solução é escalonada: 15 minutos para Tier 1 (solicitações de demo), 2 horas para Tier 2, 1 dia para Tier 3. Dê aos representantes janelas realistas para leads de menor intenção sem sacrificar a velocidade de resposta nos de alta intenção.

Granularidade dos motivos de rejeição. Vendas quer um campo: "lead ruim." Marketing quer 20 códigos. Cheguem a um consenso de 5 a 7 códigos que separem significativamente rejeições acionáveis (timing, contato errado) das não acionáveis (não é fit de ICP). Além de 7 códigos, a conformidade cai. Os representantes param de selecionar com cuidado quando a lista é longa.

Após a Assinatura: Tornando o Acordo Operacional

Guarde o acordo assinado em seu wiki compartilhado, base de conhecimento do CRM ou drive da equipe — em algum lugar onde ambas as equipes o incluam nos documentos de onboarding. Faça referência a ele na pauta da chamada semanal de qualidade de leads.

Quando surgir uma disputa, abra o documento e encontre a seção relevante antes que o argumento se intensifique. A maioria das disputas se resolve no texto. Alguém está operando com uma versão diferente do acordo na cabeça.

Sinais de Alerta de que o Acordo Está Desatualizado

• As taxas de rejeição para um código de motivo específico sobem acima de 30% por dois meses consecutivos
• O limite de score produz um volume de MQL consistentemente acima ou abaixo da meta
• Representantes rotineiramente aceitam MQLs e depois imediatamente os marcam como "Sem Resposta" sem tentar contato (sinal de que a janela de aceitação está muito curta em relação à capacidade real)
• Marketing muda uma campanha ou modelo de scoring sem notificar RevOps; qualquer mudança de scoring que altere o volume de MQL em mais de 15% deve acionar uma revisão de emergência

Perguntas Frequentes

Como você implementa o acordo MQL/SQL sem que vire uma briga política?

Enquadre-o como uma ferramenta de calibração, não como um documento de conformidade. A abordagem de implementação mais eficaz é um workshop conjunto de duas horas com ambos os líderes e RevOps, trabalhando cada seção usando seus últimos 90 dias de dados de MQL e rejeição. Onde as equipes discordarem — geralmente em limite de score e janela de aceitação — deixe os dados de conversão decidir, não a hierarquia. Equipes que negociam com base em dados, e não em opiniões, chegam a um acordo 3 a 4 vezes mais rápido e produzem acordos que duram mais, porque ambos os lados viram os mesmos números.

E se vendas não quiser assinar o acordo MQL/SQL?

A resistência de vendas geralmente sinaliza uma de duas coisas: o limite de score parece muito baixo (vendas não confia nos leads) ou a janela de aceitação parece irrealista dada a capacidade atual dos representantes. Ambos se resolvem com dados. Para resistência ao limite de score, puxe a taxa de conversão por faixa de score em incrementos de 5 pontos — a discussão sobre o limite se torna empírica. Para resistência à janela de aceitação, escalone o requisito: 15 minutos para solicitações de demo, 4 horas para todo o resto. Assinar um SLA escalonado é mais fácil do que assinar um uniforme. Se a resistência persistir, peça a vendas que proponha seu próprio limite com dados de suporte. O ato de construir o argumento frequentemente transforma a dinâmica de oposição em co-propriedade.

Com que frequência o acordo MQL/SQL deve ser revisado?

A revisão trimestral é o mínimo. Mas três eventos devem acionar uma revisão imediata fora do ciclo: uma campanha ou mudança no modelo de scoring que altere o volume de MQL em mais de 15%, um pico na taxa de rejeição acima de 30% para um código de motivo específico por dois meses consecutivos, e qualquer mudança significativa de ICP (novo segmento adicionado, segmento existente desprioritizado). A revisão trimestral é para ajuste fino. As revisões acionadas são para capturar desvios antes que se acumulem e resultem em um trimestre perdido.

Quem é o proprietário do documento de acordo MQL/SQL?

RevOps é o proprietário do documento, do controle de versão e do calendário de revisão. Marketing e vendas são cada um proprietários de suas respectivas seções. O líder de RevOps é o responsável pelo processo que conduz a revisão trimestral, gerencia solicitações de alteração e mantém ambas as partes na cadência acordada. Sem um proprietário neutro, o acordo é atualizado unilateralmente por quem estiver sob mais pressão — o que derrota seu propósito como referência compartilhada.

Para qual valor o limite de score deve ser definido?

Não há um limite universal. Puxe seus deals fechados como won dos últimos 90 dias e rastreie cada um até o score original do lead no momento do handoff de MQL. Encontre a faixa de score onde a taxa de conversão sobe significativamente acima da sua média geral — esse ponto de inflexão é sua âncora empírica de limite. Equipes com menos de 90 dias de dados devem começar com 60 e ajustar com base no feedback da taxa de rejeição após o primeiro mês completo. Uma taxa de rejeição acima de 35% sugere que o limite está muito baixo. Uma taxa de rejeição abaixo de 10% sugere que pode estar muito alto (leads demais se qualificando sem estarem prontos).

Saiba Mais

• Processo de Handoff de MQL para SQL
• Framework de Definição de MQL
• Definição e Aceitação de SQL
• Checklist de Documentação de Handoff
• Modelo de SLA Marketing-Vendas
• Glossário de Alinhamento Marketing-Vendas