Definição e Aceitação de SQL: O Que Vendas Realmente Compromete ao Aceitar um Lead

Os Leads estão no Salesforce. Status: SQL. Idade: 17 dias. Primeiro contato: nunca.

Marketing vê a contagem de aceites e pensa que o handoff funcionou. Vendas diz que os Leads não eram bons. Tecnicamente, nenhum dos dois está errado — e esse é o problema. A aceitação aconteceu. A responsabilidade, não.

Um SQL sem um SLA de aceitação é apenas um rótulo. Quando vendas clica em "aceitar" em um Lead, essa ação precisa significar algo específico: um compromisso de agir dentro de uma janela definida, com próximos passos definidos, ou devolver o Lead com um motivo documentado. Sem esse contrato, o handoff MQL→SQL é teatro. Duas equipes performando alinhamento sem realmente alcançá-lo.

Este artigo descreve o que uma definição de SQL deve conter, o que a aceitação genuinamente obriga vendas a fazer e como documentar o acordo para que ambos os lados possam ser responsabilizados.

Fatos Relevantes: Desempenho de SQL e Qualidade do Handoff

• Apenas 27% dos Leads encaminhados para vendas são alguma vez contatados, segundo pesquisa da MarketingSherpa sobre taxas de follow-up de Leads B2B.
• Empresas com acordos de SLA formais entre marketing e vendas têm 2,4x mais probabilidade de relatar crescimento de receita ano a ano, segundo o relatório State of Marketing da HubSpot.
• A empresa B2B média perde 71% dos Leads da internet porque não são contatados com rapidez suficiente, segundo pesquisa da Drift e Heinz Marketing.
• Leads contatados em até 5 minutos após a consulta inicial têm 21 vezes mais probabilidade de qualificar do que Leads contatados após 30 minutos, segundo estudo conjunto do MIT e InsideSales.com.
• 61% dos profissionais de marketing B2B enviam todos os Leads diretamente para vendas, mas apenas 27% desses Leads são realmente qualificados, segundo MarketingSherpa.

O Problema do Teatro de Aceitação

A definição de SQL do Gartner trata o status SQL como uma transição confirmada de propriedade — mas propriedade sem responsabilidade é a lacuna que a maioria das equipes nunca fecha.

Veja como o teatro de aceitação se desenvolve na maioria das empresas B2B:

Marketing passa um lote de MQLs para vendas no final da semana. Vendas os aceita, porque o SLA diz que eles têm que responder em 48 horas. Mas "aceitar" significa clicar em um botão no CRM. Não significa que o rep olhou para o Lead, pesquisou a empresa ou planeja ligar dentro de uma janela razoável.

Duas semanas depois, marketing puxa o relatório. Todos os MQLs foram "aceitos". Ótimo. Exceto que apenas 3 dos 20 foram alguma vez contatados. Os outros 17 estão agora frios.

Quando marketing levanta isso na próxima reunião de alinhamento, vendas diz: "Esses Leads não eram bons." Marketing diz: "Vocês os aceitaram." Ambos os lados estão tecnicamente corretos. Nenhum dos lados é responsável.

A causa raiz é definitória. A maioria das empresas define um SQL apenas em termos de critérios para passar: quais sinais um Lead precisa atingir antes de vendas assumir a propriedade. Não definem o que vendas deve em troca. Essa assimetria é o que faz o handoff falhar.

SQL vs. MQL: A Mudança de Propriedade

A transição MQL→SQL não é apenas uma mudança de status. Deveria ser uma transferência de propriedade.

Quando um Lead é um MQL, marketing o possui. Marketing decide se vai nutri-lo, acelerá-lo ou desqualificá-lo. Quando um Lead se torna um SQL, vendas o possui. Vendas decide se vai avançá-lo, devolvê-lo ou encerrá-lo.

Mas propriedade sem responsabilidade é vazia. Vendas "possuir" um SQL precisa significar algo operacionalmente. Significa:

• Vendas é responsável pelo primeiro contato significativo
• Vendas deve avançar o Lead ou rejeitá-lo dentro de uma janela definida
• A rejeição requer um motivo documentado que é enviado de volta para marketing

Até definir o que a propriedade realmente requer, o handoff apenas move um registro da visualização de uma equipe para a de outra. Nada muda sobre o destino do Lead.

O processo de handoff MQL→SQL cobre a mecânica dessa transferência. Este artigo foca no que o compromisso de aceitação deve conter. Para o contexto mais amplo do Funnel que ambas as equipes compartilham, o modelo de Funnel acordado define a propriedade em cada estágio.

A Definição SQL em Duas Partes

O Framework de Definição SQL em Duas Partes

Uma definição completa de SQL cobre dois compromissos igualmente vinculantes — critérios de qualificação (o que torna um Lead pronto para SQL) e compromissos de aceitação (o que vendas deve ao aceitar). A maioria das equipes escreve a Parte 1 e pula a Parte 2. Essa assimetria é onde os handoffs falham.

Parte 1: Critérios de qualificação — os sinais que tornam um Lead pronto para SQL. Cobre fit (correspondência com ICP, autoridade de compra), intenção (solicitação de Demo, visita de preços) e timing (projeto ativo, alinhamento de ciclo orçamentário).

Parte 2: O SLA de aceitação — o que vendas se compromete ao clicar em aceitar: primeiro contato significativo em até 24 horas, tentativa de discovery em até 5 dias úteis, disposição (avançar ou devolver com motivo) em até 10 dias úteis.

Ambas as partes vivem no mesmo documento assinado. Uma definição que cobre apenas a Parte 1 é um handoff sem responsabilidade.

Uma definição de SQL funcional tem duas partes que a maioria das equipes constrói apenas pela metade:

Parte 1: Critérios de qualificação: os sinais que tornam um Lead pronto para SQL. Isso é o que a maioria das equipes escreve.

Parte 2: Compromissos de aceitação: o que vendas concorda em fazer ao aceitar. Isso é o que a maioria das equipes pula.

Ambas as partes precisam estar no mesmo acordo documentado. Uma definição que cobre apenas a Parte 1 diz a quem fazer o handoff. Não diz o que fazer a seguir. E sem a Parte 2, a aceitação permanece uma formalidade.

Parte 1: Critérios de Qualificação

Os critérios de SQL devem cobrir três categorias de sinais: fit, intenção e timing.

Sinais de fit confirmam que o Lead está genuinamente no seu mercado-alvo:

• Correspondência com ICP em tamanho de empresa, setor, geografia — o framework compartilhado de ICP documenta como concordar com essas dimensões entre equipes
• Autoridade de compra confirmada ou provável (título indica papel de compra, ou confirmação direta de orçamento pelo formulário/ligação)
• Compatibilidade de stack tecnológico (eles usam sistemas com os quais seu produto se integra, ou estão substituindo um sistema que você desloca)

Sinais de intenção confirmam interesse ativo de compra:

• Visitas a páginas de alto valor: preços, Demo, comparação, calculadora de ROI
• Solicitação explícita: Demo agendado, Trial iniciado, consulta direta
• Comportamento de pesquisa competitiva: visitando conteúdo de comparação com concorrentes

Sinais de timing confirmam que há uma janela de decisão ativa:

• Campo de formulário indicando cronograma do projeto ("avaliando agora", "orçamento do Q2 alocado")
• Gatilho de evento: renovação de contrato se aproximando, mudança de liderança, rodada de captação
• Contato inbound (eles entraram em contato com você, o que implica algum nível de urgência)

Nenhum sinal único deve automaticamente tornar um Lead um SQL. Um Lead que visitou sua página de preços uma vez e corresponde ao seu ICP não está necessariamente pronto para uma conversa de vendas. Você quer uma combinação — tipicamente fit mais pelo menos um sinal forte de intenção ou timing.

Checklist de Critérios SQL

Sinais mínimos antes de vendas assumir a propriedade:

• Empresa corresponde ao ICP em pelo menos 2 de 3 critérios firmográficos (tamanho, setor, stack tecnológico)
• Contato tem autoridade de compra provável (VP ou acima, ou economic buyer confirmado)
• Pelo menos um sinal explícito de intenção (solicitação de Demo, visita de preços, consulta direta)
• Sem desqualificadores ativos (concorrente, estudante, geografia irrelevante)
• Fonte do Lead capturada e verificada

Este checklist é um ponto de partida. Calibre-o com seus dados de negócios fechados. Se os Leads que correspondem a todos os cinco critérios fecham a uma taxa materialmente mais alta do que os que correspondem a três, seus limites estão aproximadamente corretos. Se Leads com cinco critérios fecham na mesma taxa que Leads com três, você está sendo muito restritivo.

O framework de definição de MQL cobre as decisões de qualificação de estágio anterior que alimentam esse conjunto de critérios.

Parte 2: O SLA de Aceitação

Quando vendas aceita um SQL, está se comprometendo com ações específicas dentro de prazos específicos. O SLA de aceitação define esses compromissos.

O SLA de primeiro contato em 24 horas é o que a maioria das equipes não cumpre. Pesquisa do HBR sobre Leads de vendas online descobriu que empresas que tentaram contatar clientes potenciais dentro de uma hora de receber uma consulta tinham quase sete vezes mais probabilidade de qualificar o Lead do que as que esperaram mesmo uma hora a mais.

Citável: Equipes de vendas B2B que respondem a Leads inbound dentro de uma hora de receber uma consulta têm 7x mais probabilidade de qualificar o Lead do que equipes que esperam mesmo 60 minutos a mais, segundo pesquisa do HBR sobre taxas de resposta a Leads de vendas online. A diferença entre 1 hora e 24 horas já é significativa. Se o seu SLA de aceitação permite 48 horas para o primeiro contato, você está abrindo mão de Pipeline antes mesmo de vendas pegar o telefone.

Para equipes que lidam com solicitações de Demo inbound, considere apertar isso ainda mais. Um SLA de resposta de cinco minutos é alcançável para inbound de alta intenção e muda as taxas de conversão de forma significativa.

Escrevendo Critérios de SQL que Sua Equipe Realmente Vai Usar

A definição de MQL do Gartner é uma referência upstream útil aqui — os critérios de SQL que você escreve downstream devem refletir exatamente onde a definição de MQL termina e a propriedade transfere para vendas.

As definições de SQL falham por dois motivos: são muito frouxas (qualquer MQL conta como SQL) ou muito rígidas (tantos critérios que poucos Leads se qualificam, e vendas reclama que a definição é irrealista).

Uma definição funcional é específica o suficiente para ser significativa e flexível o suficiente para levar em conta a variedade de Leads reais.

Evite definições binárias. Em vez de "orçamento deve ser confirmado", escreva "faixa de orçamento indicada no formulário OU título sugere autoridade de orçamento (VP ou acima)". Isso considera a realidade de que muitos compradores não divulgam orçamento no estágio de awareness.

Inclua desqualificadores explícitos. Critérios negativos importam tanto quanto os positivos. Um Lead que corresponde perfeitamente ao seu ICP, mas é de um concorrente direto, estudante ou país que você não atende, deve falhar nos critérios de SQL independentemente de seus sinais de intenção.

Use linguagem de "provável" com cuidado. Autoridade de compra "provável" é um critério válido para SQLs em muitos movimentos, especialmente inbound, onde raramente se confirma orçamento no primeiro contato. Mas "provável" requer definição. "Título de Diretor ou acima na função relevante" é autoridade provável. "Qualquer pessoa com um e-mail corporativo" não é.

Defina uma pontuação mínima ou contagem de sinais. Para equipes que usam lead scoring conjunto, defina a pontuação composta mínima necessária para o status SQL. Para equipes sem scoring formal, defina uma contagem mínima de sinais (por exemplo, "pelo menos 2 sinais de fit e pelo menos 1 sinal de intenção").

A Camada SAL: Quando Ajuda, Quando Não Ajuda

Algumas equipes de receita adicionam um estágio de Sales Accepted Lead (SAL) entre MQL e SQL. O estágio SAL cria uma breve janela (tipicamente 48-72 horas) para vendas revisar o Lead antes de se comprometer totalmente com o SLA de SQL.

Quando SAL adiciona clareza:

• Inbound de alto volume onde vendas genuinamente precisa de tempo de revisão antes de se comprometer
• Equipes onde os critérios de qualificação são complexos e requerem pesquisa no CRM antes da aceitação
• Organizações com auditorias formais de SLA onde compromisso parcial é significativo

Quando SAL apenas adiciona atrito:

• Equipes com critérios de ICP limpos onde a revisão leva 2 minutos
• Ambientes de baixo volume onde cada Lead vale uma revisão completa de qualquer forma
• Organizações onde o estágio SAL é usado para atrasar a responsabilidade em vez de habilitá-la

Se você adicionar um estágio SAL, defina uma janela estrita (máximo 48 horas) e um requisito de disposição no final dessa janela: aceitar para o status SQL, ou devolver com motivo. Um SAL que pode ficar parado por uma semana não oferece nenhum benefício sobre um MQL. As regras de lead routing que sua equipe aplica determinam qual rep recebe o Lead assim que ele passa pela janela SAL.

O Que Acontece Quando Vendas Rejeita um SQL

A rejeição é um sinal valioso, mas apenas se for documentada corretamente.

Taxonomia de motivo de rejeição (códigos estruturados, não texto livre):

Motivos de rejeição desestruturados ("não interessado", "Lead ruim") são inúteis para marketing. Não informam se a definição precisa de atualização, se o programa de nurture falhou ou se vendas está usando a rejeição para evitar trabalho difícil.

Códigos de motivo estruturados permitem que marketing identifique padrões. Se 40% das rejeições de SQL voltam como R2 (empresa certa, timing errado), marketing pode construir um gatilho de re-engajamento mais rápido. Se 30% voltam como R3 (fora do ICP), a definição de MQL tem um problema.

O processo de rejeição e reciclagem de Lead cobre o que acontece com os Leads devolvidos. Essa taxonomia alimenta diretamente esse Workflow.

Documentando o Contrato SQL

A definição de SQL e o SLA de aceitação devem ser um único documento escrito, não um entendimento verbal. Tanto o VP de Marketing quanto o VP de Vendas assinam. Ambas as equipes têm acesso a ele. Tem um número de versão e uma data da última revisão.

Estrutura do template:

Contrato SQL — [Nome da Empresa]
Versão: [X.X]
Data de vigência: [Data]
Última revisão: [Data]
Responsáveis: VP de Marketing, VP de Vendas

Seção 1: Critérios de Qualificação SQL
- Sinais de fit mínimos necessários: [lista]
- Sinais de intenção mínimos necessários: [lista]
- Desqualificadores: [lista]
- Pontuação composta mínima (se aplicável): [pontuação]

Seção 2: Compromissos de Aceitação
- SLA de primeiro contato significativo: [prazo]
- SLA de tentativa de discovery: [prazo]
- Requisito de disposição: [prazo e opções]

Seção 3: Padrões de Rejeição
- Códigos de motivo: [taxonomia]
- Ações de roteamento por código: [tabela]
- SLA de rejeição (feedback para marketing): [prazo]

Seção 4: Cronograma de Revisão
- Reunião de calibração trimestral: [responsáveis, formato]
- Gatilho para revisão fora do ciclo: [condições]

O controle de versão importa. Quando a definição muda (porque seu ICP mudou, um novo canal começou a gerar Leads de qualidade diferente, ou dados de calibração mostraram que os limites estavam errados), você precisa de um registro do que mudou e por quê. Sem controle de versão, definições antigas são seguidas após serem substituídas, e você não consegue diagnosticar lacunas de desempenho em relação à baseline certa.

Análise Rework: Equipes que formalizam uma definição de SQL em duas partes — com critérios e SLAs de aceitação documentados — geralmente fecham a lacuna do teatro de aceitação dentro de um trimestre. O indicador principal é a taxa de rejeição com códigos de motivo estruturados. Quando os códigos R1–R6 são usados de forma consistente, a conversão MQL→SQL se estabiliza dentro de 60 dias porque marketing consegue rotear os Leads devolvidos com precisão, em vez de repassar os mesmos contatos desqualificados. Comece com o SLA de aceitação antes de otimizar os critérios. Comportamento antes de scoring.

Medindo a Qualidade do SQL ao Longo do Tempo

Três métricas dizem se sua definição de SQL está funcionando:

Taxa de conversão SQL→oportunidade. Se menos de 60–70% dos SQLs se tornarem oportunidades, sua definição está frouxa demais. Você está passando Leads que vendas não consegue avançar. Se a conversão é muito alta (>90%) e o volume é baixo, sua definição pode ser restritiva demais e você está perdendo Pipeline. Os benchmarks de conversão Lead→oportunidade do lado do Pipeline oferecem a visão downstream dessa taxa.

Taxa de conversão SQL→negócio fechado. Rastreie o win rate desde o estágio SQL, não apenas desde a oportunidade. Se você está criando muitas oportunidades a partir de SQLs, mas fechando poucos, o problema de qualidade aparece um estágio depois: os critérios de SQL estão passando Leads que vendas consegue trabalhar, mas não fechar. É aqui que os critérios de qualificação de oportunidade tornam-se críticos — o que vendas aceita como SQL deve se alinhar com o que consegue realmente avançar.

Taxa de rejeição por código de motivo. Uma taxa R3 crescente (fora do ICP) significa que sua qualificação upstream está derivando. Uma taxa R2 crescente (empresa certa, timing errado) pode significar que marketing está acelerando Leads muito rápido, ou que sinaliza uma oportunidade para programas de nurture baseados em timing.

Revise essas métricas trimestralmente na reunião de alinhamento que cobre o glossário de alinhamento de marketing e vendas e as definições compartilhadas. Quando os números mudam, rastreie de volta para a definição, não para a equipe.

A Conclusão

Uma definição de SQL sem compromissos de aceitação é um handoff sem responsabilidade. Marketing pode apontar para as contagens de aceites. Vendas pode apontar para a qualidade dos Leads. Ninguém é responsável pela lacuna no meio.

Escrever a definição em duas partes (critérios mais compromissos) fecha essa lacuna. Vendas sabe o que aceitar significa antes de clicar no botão. Marketing sabe o que esperar após o handoff. Quando algo falha, o acordo diz onde.

Ambas as equipes precisam ser donas do documento. Ambas precisam ter revisado os dados que informaram os limites. E ambas precisam sentir que a definição é justa, não uma armadilha para nenhum dos lados.

É assim que a aceitação se torna um compromisso em vez de uma formalidade.

Perguntas Frequentes

Qual é a diferença entre um MQL e um SQL?

Um MQL (Marketing Qualified Lead) é um Lead que marketing determinou que atende aos critérios mínimos de ICP e engajamento, tornando-o digno de nurture em direção a uma conversa de vendas. Um SQL (Sales Qualified Lead) é um Lead que cruzou um limite mais alto — fit confirmado, intenção ativa e sinais de timing — e que vendas aceitou a responsabilidade de trabalhar. A diferença de propriedade é a distinção-chave: marketing possui o MQL, vendas possui o SQL.

O que a aceitação de SQL realmente compromete vendas a fazer?

Quando vendas aceita um SQL, compromete-se com ações específicas dentro de prazos definidos: um primeiro contato significativo em até 24 horas, uma tentativa de discovery em até 5 dias úteis e uma disposição completa — avançar para oportunidade ou devolver com um motivo de rejeição estruturado — em até 10 dias úteis. Aceitação sem esses compromissos é teatro, não responsabilidade.

O que deve acontecer quando vendas rejeita um SQL?

Vendas deve devolver o Lead com um código de motivo estruturado, não texto livre como "não é um bom fit". Uma taxonomia de rejeição (por exemplo, R1 = persona errada, R2 = sem projeto ativo, R3 = fora do ICP) diz exatamente a marketing onde a falha aconteceu para que possa corrigir a definição de MQL ou construir programas de nurture melhores. Motivos de rejeição desestruturados são inúteis para melhoria upstream.

E se vendas nunca contatar um SQL aceito?

Esse é o problema do teatro de aceitação — aceitação aconteceu, responsabilidade não. A solução é operacional: construa relatórios de SLA no seu CRM que sinalizem SQLs sem atividade de primeiro contato após 24 horas. Tanto o VP de Marketing quanto o VP de Vendas devem ver esse relatório semanalmente. Quando SLAs perdidos aparecem em um Dashboard compartilhado, ambas as equipes são responsáveis pela lacuna.

Com que frequência a definição de SQL deve ser revisada?

No mínimo, trimestralmente. A definição de SQL deve ser revisada sempre que a conversão SQL→oportunidade cair mais de 10 pontos percentuais trimestre a trimestre, quando um novo canal começar a gerar Leads de qualidade significativamente diferente, ou quando seu ICP mudar. Faça controle de versão do documento para que você possa diagnosticar lacunas de desempenho em relação à baseline certa.

O que é um SAL (Sales Accepted Lead) e quando devemos adicionar esse estágio?

Um SAL é um estágio intermediário entre MQL e SQL que oferece a vendas uma breve janela de revisão — tipicamente 48–72 horas — para confirmar que um Lead atende aos critérios de SQL antes de se comprometer totalmente com o SLA de aceitação. O SAL agrega valor quando os critérios de qualificação são complexos e vendas genuinamente precisa de tempo de pesquisa antes de se comprometer. Adiciona atrito quando se torna um buffer para follow-up lento. Se o seu estágio SAL consistentemente envelhece além de 72 horas, remova-o.

Como calculamos o target certo de conversão SQL→oportunidade?

Puxe 3–6 meses de dados limpos do CRM. Conte SQLs por data de entrada e conte oportunidades criadas a partir desses SQLs. Divida oportunidades por SQLs para obter sua taxa base. Benchmarks de SMB B2B ficam em 60–80%; médio porte fica em 55–75%. Se você está abaixo de 55%, sua definição de SQL está frouxa demais. Se você está acima de 90%, mas o volume é baixo, você está sendo muito restritivo e está perdendo Pipeline.

Saiba Mais

• Framework de Definição de MQL
• Processo de Handoff MQL→SQL
• Modelo de Funnel Acordado
• Rejeição e Reciclagem de Lead
• SLA de Resposta de Cinco Minutos
• Qualificação de Oportunidade
• Glossário de Alinhamento de Marketing e Vendas