Seu relatório diz 300 leads no mês. O cliente diz que recebeu 12 oportunidades. Os dois números podem estar certos, e a discussão só anda quando vocês combinam o que separa um do outro. É para isso que servem MQL e SQL.
Na documentação de estágios do ciclo de vida da HubSpot, lida em 05/11/2026, MQL (marketing qualified lead) é o contato que o marketing qualificou como pronto para vendas, e SQL (sales qualified lead) é o contato que vendas qualificou como potencial cliente. A diferença está em quem qualifica e com que critério. Na prática de tráfego, isso se traduz em duas decisões: quem passa ao vendedor e que evento você manda de volta para a mídia.
O caminho de um lead de anúncio
Para o gestor, são quatro pontos diferentes, e cada um pede um dono. Se a palavra “lead” ainda gera confusão na conta, vale nivelar com o cliente o que é lead antes de discutir as siglas.
| Ponto | O que aconteceu | Quem decide | Exemplo em uma escola de idiomas (hipotético) |
|---|---|---|---|
| Lead | A pessoa deixou um contato | Ninguém: é o registro do formulário | Preencheu “quero saber o preço do curso” |
| MQL | Cumpriu os critérios combinados com o marketing | Regra escrita, aplicada pelo gestor ou pelo sistema | Adulto, mora na região, escolheu turma presencial |
| SQL | Uma pessoa de vendas conversou e confirmou a oportunidade | Vendedor | Tem objetivo e horário compatíveis, topou fazer o teste de nível |
| Venda | Fechou | Sistema ou vendedor | Fez a matrícula |
Em muitas contas pequenas o MQL nem existe como etapa separada, porque todo lead vai direto para o vendedor. Não há problema nisso enquanto o volume couber na equipe. Nesse caso, o critério ainda serve para decidir a ordem de atendimento e para ler a campanha.
Como escrever o critério de passagem
Na nossa recomendação, o critério cabe em meia página, sai de uma conversa com quem vende e usa só o que dá para verificar:
- Para virar MQL: de dois a quatro dados que o formulário ou o rastreamento já entregam. Região, tipo de empresa, serviço escolhido.
- Para virar SQL: o que o vendedor precisa confirmar em conversa. Tem o problema que o cliente resolve? Pode comprar? Aceitou o próximo passo, como visita, teste ou reunião?
- Para voltar: o que acontece com quem foi recusado. Um motivo registrado e, se fizer sentido, um retorno ao marketing para ser nutrido depois.
O terceiro item é o que costuma faltar. Sem ele, a recusa do vendedor desaparece do funil, e você continua achando que aquela campanha entrega MQL de qualidade.
Evite também usar “quente” como critério sem definir o termo. Um lead quente diz respeito ao interesse do momento, enquanto MQL e SQL dizem respeito a uma passagem combinada. Um lead pode estar animado e fora da região atendida.
Quatro pontos em que a passagem trava
Formulário preenchido virou MQL automático
Se todo lead já nasce MQL, a sigla só trocou de nome e o custo por MQL é o custo por lead com outro rótulo. O sinal é uma taxa de lead para MQL de 100%. Volte ao critério e deixe alguma regra de fato excluir alguém.
O vendedor recebe, mas não dá devolutiva
O lead fica parado na etapa e não vira SQL nem perda. Você não sabe se ele foi recusado, se não atendeu ou se ninguém tentou. Por isso, combine um prazo para todo MQL sair daquela etapa.
SQL sem definição comum
Um vendedor marca SQL quem respondeu “oi”. Outro só depois da proposta. Comparar campanhas com esse dado leva a erro, porque a variação pode vir de quem atendeu. Uma frase escrita, com o próximo passo aceito pelo lead, costuma resolver.
A passagem acontece fora de hora
Formulário de anúncio pode chegar à noite. Se a passagem ao vendedor só roda no dia seguinte, ou depende de alguém abrir uma planilha, parte do que parece queda entre MQL e SQL pode ser fila. Antes de mexer no público, confira a hora de entrada e a hora da primeira tentativa.
Que evento enviar à mídia
O que você manda de volta influencia o que a plataforma aprende a procurar. Se o único sinal é o formulário preenchido, a otimização busca quem preenche formulário. Essa é a nossa leitura do mecanismo, e ela ajuda a entender por que o custo por lead pode melhorar no gerenciador sem que nada melhore no funil.
Veja um exemplo com números inventados. Duas campanhas gastam R$ 6.000 cada uma:
| Campanha | Leads | Custo por lead | SQL | Custo por SQL |
|---|---|---|---|---|
| A | 200 | R$ 30 | 10 | R$ 600 |
| B | 100 | R$ 60 | 20 | R$ 300 |
Olhando só o custo por lead, A ganha e recebe mais verba. Com SQL na conta, a leitura se inverte, ainda que a resposta final dependa de quantos SQL de cada campanha viram venda.
Nossa recomendação é enviar o evento mais próximo da venda que a conta gera com regularidade. Em uma conta com muito volume, pode ser SQL ou a própria venda. Em uma conta com poucos SQL por mês, comece medindo: use o dado para decidir verba manualmente, por campanha, sem depender de otimização automática.
Na Meta, a página “Conversions API for CRM Integration”, lida em 05/11/2026, permite enviar eventos do CRM e pede ao menos 200 leads por mês, envio diário, etapa alcançada em até 28 dias e taxa de conversão da etapa entre 1% e 40%. O objetivo correspondente só funciona com formulários instantâneos. Muita conta pequena fica de fora desse objetivo, e a leitura manual continua disponível.
O que pedir ao cliente nesta semana
Três coisas bastam para começar: uma conversa de 30 minutos com quem vende para escrever o critério, uma etapa de SQL no funil com a definição ao lado e o compromisso de registrar o motivo quando um lead for recusado. No mês seguinte, você já pode trocar “leads gerados” por custo por SQL, separado por campanha.
Essa conta só fecha se cada lead carregar a origem até o fim do funil. O CRM do Cubo Suite guarda a campanha de origem dos leads vindos do Meta Ads, do Google Ads, de landing pages e de formulários, e o motivo de perda é obrigatório. Para quem quer ver esse caminho antes de propor o critério ao cliente, vale agendar uma demonstração do funil com a origem de cada lead.
Deixe um comentário