MQL e SQL: o que são, a diferença e o que fazer com o lead que vendas devolve

Todo artigo sobre MQL e SQL termina no mesmo lugar: o marketing qualifica, passa o bastão, vendas qualifica de novo e o lead vira oportunidade. A história acaba bem porque ninguém conta o que acontece quando o vendedor liga, conversa e conclui que aquele contato não era para agora.

Este artigo define MQL e SQL, mostra a diferença entre eles e onde entra o SAL. Depois entra na parte que os guias pulam: o que o CRM faz com a etapa do lead, por que ela só anda para a frente no HubSpot e como desenhar a devolução para que o lead recusado volte para a nutrição sem estragar o relatório de conversão.

O que é MQL e SQL?

MQL, ou Marketing Qualified Lead, é o lead qualificado pelo marketing: um contato que, pelo perfil e pelo que fez, o marketing considera pronto para receber uma abordagem do time comercial. É a definição que a própria HubSpot usa na sua base de conhecimento, um contato que o marketing qualificou como pronto para vendas.

SQL, ou Sales Qualified Lead, é o lead qualificado por vendas: o contato que o time comercial, depois de avaliar e normalmente depois de falar com ele, reconhece como cliente em potencial. A diferença parece sutil, mas muda quem assina embaixo. O MQL é uma aposta do marketing; o SQL é uma confirmação de vendas.

As duas siglas existem porque marketing e vendas olham para o mesmo contato com informações diferentes. O marketing vê cliques, páginas visitadas, materiais baixados e dados de formulário. Vendas ouve a pessoa: descobre se há orçamento, quem decide, qual é o problema e quando ele precisa ser resolvido. Separar as etapas é uma forma de registrar em que ponto cada informação entrou na decisão.

Qual a diferença entre MQL e SQL?

A diferença central está em três coisas: quem qualifica, com que evidência e qual ação vem depois. A tabela resume o que muda de uma etapa para a outra.

Elaboração da Alliance a partir das definições de etapa do ciclo de vida da base de conhecimento da HubSpot

Na prática, o MQL costuma nascer de uma regra automática: o contato passou da nota mínima ou fez algo que sinaliza compra. Como a nota é construída, com perfil e engajamento separados e pontos que expiram, é assunto do nosso artigo sobre como pontuar leads com as regras que as plataformas documentam. O SQL, ao contrário, quase nunca deveria ser automático, porque depende de alguém ter ouvido o lead.

O que é MQL, SQL e SAL?

SAL, ou Sales Accepted Lead, é o lead aceito por vendas: a etapa em que o comercial recebe o MQL e diz, formalmente, que vai trabalhar aquele contato. Não é ainda a qualificação; é o aceite do repasse. O SAL não faz parte das etapas padrão do ciclo de vida do HubSpot, mas aparece em muitos processos de inbound justamente porque resolve um ponto cego.

Sem o SAL, o caminho tem dois estados: o marketing entregou e vendas qualificou. Tudo o que acontece no meio, o lead que ficou parado na fila, o que o vendedor olhou e descartou sem ligar, o que tinha telefone errado, desaparece. Com o SAL, cada MQL termina em uma de duas respostas registradas: aceito ou recusado. E a recusa precisa de um motivo.

A vantagem prática é que o SAL separa duas discussões que costumam se misturar. Se vendas recusa muito na hora do aceite, o problema está na definição de MQL, ou seja, no marketing. Se vendas aceita e depois desqualifica muito na conversa, o problema pode estar na abordagem, no prazo de contato ou no momento do lead. Sem a etapa do meio, as duas coisas viram uma só queixa: os leads do marketing são ruins.

Como um MQL vira SQL?

O MQL vira SQL quando vendas confirma, numa conversa, que existe uma venda possível. O caminho mais comum tem quatro passos, e cada um deixa um registro no CRM:

1. Repasse. O contato atinge o critério de MQL e é atribuído a um vendedor ou a uma fila de pré-vendas, com prazo para o primeiro contato.
2. Aceite. O vendedor confere o cadastro e aceita (SAL) ou recusa com motivo, antes mesmo de ligar.
3. Contato. Ligação, mensagem ou reunião em que o vendedor entende a necessidade, o orçamento, quem decide e o prazo.
4. Decisão. Se os critérios combinados estão presentes, o lead vira SQL e, logo depois, oportunidade com proposta. Se não estão, ele é desqualificado, também com motivo.

O critério de qualificação da quarta etapa precisa ser escrito e combinado entre as áreas, do mesmo jeito que o critério de MQL. Modelos conhecidos como BANT (orçamento, autoridade, necessidade e prazo) servem de ponto de partida, mas o que vale é a lista que o comercial da sua empresa usa de fato para decidir se abre proposta.

O que o CRM faz com a etapa do lead?

Aqui começa a parte que os guias de MQL e SQL não cobrem. No HubSpot, a etapa do lead fica numa propriedade chamada etapa do ciclo de vida (lifecycle stage), e as etapas padrão formam uma sequência fixa: Assinante, Lead, MQL, SQL, Oportunidade, Cliente e Evangelista, além de uma etapa Outro para quem não se encaixa em nenhuma.

A regra faz sentido para o uso que a HubSpot imagina. Se um cliente preenche de novo o formulário de newsletter, ninguém quer que ele volte a ser Assinante. A mão única protege o histórico de quem avançou. O efeito colateral aparece justamente no ponto mais sensível do funil, a passagem de marketing para vendas.

Um detalhe da mesma página ajuda a entender o tamanho do cuidado: as propriedades calculadas que registram a data em que o contato entrou em cada etapa não são apagadas quando a etapa é movida para trás. Ou seja, mesmo que alguém faça o lead voltar, o registro de que ele um dia foi SQL continua lá. Isso é bom para auditoria e ruim para quem monta relatório sem saber.

Onde fica registrado o lead que vendas recusa?

Se o ciclo de vida só avança, a recusa precisa morar em outro campo. No HubSpot, existem dois lugares possíveis, e qual deles a sua conta usa depende da configuração e do plano.

O primeiro é a propriedade Status do lead (Lead Status). A própria base de conhecimento descreve esse campo como as subetapas dentro da etapa SQL do ciclo de vida, com opções padrão como Novo, Aberto, Em andamento, Tentativa de contato, Conectado, Momento ruim e Não qualificado. Repare no que isso significa: o lead marcado como Não qualificado continua, por definição, dentro da etapa SQL.

O segundo lugar é esse pipeline de leads. Pela nossa leitura da documentação, é ali que o trabalho do vendedor fica registrado: tentou contato, conectou, qualificou ou desqualificou. A recusa vira uma etapa de um pipeline, não uma volta no ciclo de vida. São duas trilhas que andam em paralelo e que não se corrigem uma à outra sem uma regra que alguém precisa criar.

O que acontece quando vendas recusa um SQL?

Sem regra de devolução, acontece uma de três coisas, e nenhuma é boa. Na primeira, o lead fica parado como SQL no ciclo de vida, com status Não qualificado ou na etapa Disqualified do pipeline. Ele sai da fila do vendedor, mas também não volta para nenhum fluxo de nutrição, porque os fluxos costumam ser disparados por etapa do ciclo de vida, e a etapa dele não mudou.

Na segunda, o relatório mente. Se a taxa de conversão de MQL para SQL é calculada por quem chegou à etapa SQL, todo lead recusado entra na conta como sucesso. O marketing comemora uma conversão alta enquanto vendas reclama da qualidade. As duas áreas estão certas, cada uma olhando para um campo diferente.

Na terceira, alguém tenta corrigir na mão: volta a etapa para Lead em alguns contatos, esquece outros e não registra o motivo. Seis meses depois, ninguém sabe dizer quantos leads vendas devolveu, nem por quê. É o cenário mais comum em empresas que implantaram CRM sem desenhar a passagem, e é o que o artigo sobre o gargalo da geração de leads no repasse para vendas descreve do lado do acordo entre as áreas.

O lead recusado não é lixo. Boa parte das recusas tem motivo temporário: o contato não tinha orçamento neste trimestre, não era a pessoa que decide, a empresa acabou de fechar com outro fornecedor. Esse lead precisa voltar a receber conteúdo e ser reavaliado depois. Para isso, o CRM tem de saber que ele voltou.

Como desenhar a devolução do lead na prática?

A devolução é um pequeno processo com cinco peças. Nenhuma depende de ferramenta específica, mas cada uma precisa existir dentro das regras que o CRM documenta, e não contra elas.

1. Crie a etapa de aceite

Se o CRM não tem SAL no ciclo de vida, registre o aceite em outro campo: uma etapa do pipeline de leads, uma opção do status do lead ou uma propriedade própria com data. O importante é que todo MQL tenha uma resposta de vendas com data, e que um MQL sem resposta depois do prazo combinado apareça em algum relatório.

2. Torne o motivo de recusa obrigatório

Monte uma lista fechada de motivos, curta o bastante para o vendedor preencher sem pensar: perfil fora do cliente ideal, sem momento de compra, sem contato possível, já é cliente, concorrente ou fornecedor, dado inválido. No HubSpot, as configurações de pipeline permitem marcar uma propriedade como obrigatória em uma etapa, o que impede salvar o registro sem ela. Texto livre não serve: ninguém consegue somar texto livre no fim do mês.

3. Defina o que cada motivo faz

Cada motivo leva a um destino. Sem momento de compra volta para a nutrição com data para reavaliar. Perfil errado sai da régua comercial e fica só na newsletter. Concorrente e dado inválido saem de qualquer fluxo. Já é cliente vai para o time de relacionamento. Escrever esse mapa antes de configurar evita que a automação decida sozinha.

4. Faça a etapa voltar por regra, não à mão

Como a etapa do ciclo de vida só avança, a volta precisa seguir o caminho que a documentação descreve: limpar o valor e depois definir a etapa anterior. Isso pode ser feito por workflow disparado pela recusa. A HubSpot informa que ações de workflow sobre a etapa do ciclo de vida estão disponíveis nos planos Professional e Enterprise; em planos menores, a alternativa é a edição em massa periódica, com uma lista filtrada pelo motivo de recusa.

5. Coloque o lead em um fluxo próprio de reengajamento

O lead devolvido não deve entrar no mesmo fluxo de quem acabou de baixar o primeiro material. Ele já falou com vendas e já disse algo sobre o momento dele. Um fluxo curto, com conteúdo de decisão e uma nova checagem de interesse na data combinada, respeita essa história. Se ele voltar a atingir o critério, vira MQL de novo, e o relatório registra que é a segunda passagem.

Quais os erros mais comuns com MQL e SQL?

• Definir MQL só no marketing. Se vendas não participou da definição, vai recusar sem critério e o aceite vira disputa.
• Marcar SQL automaticamente. Formulário de orçamento é sinal forte, mas ainda é MQL. SQL é a conclusão de uma conversa.
• Medir conversão pela etapa mais alta já atingida. Como o ciclo de vida só avança e as datas de entrada não são apagadas, o lead recusado continua contando como SQL.
• Deixar o motivo de recusa em texto livre. Sem lista fechada, não há como saber se o problema é perfil, momento ou abordagem.
• Devolver o lead para o início da régua. Quem já falou com vendas não precisa do material de topo de funil de novo.
• Corrigir etapas à mão, caso a caso. A correção manual cria uma base em que metade dos recusados voltou e metade não.
• Criar SAL sem prazo. Aceite sem prazo vira fila invisível: o MQL fica esperando e ninguém percebe.

Como medir a passagem de MQL para SQL?

Com a devolução desenhada, o relatório deixa de ter uma taxa só e passa a ter uma sequência de perguntas, cada uma com dono:

1. MQL entregues no período, pela data de entrada na etapa, e não pela etapa atual.
2. Taxa de aceite (MQL para SAL): quantos vendas aceitou. Se é baixa, a definição de MQL precisa ser revista com o comercial.
3. Tempo até o aceite e até o primeiro contato: quanto tempo o MQL esperou. Lead que espera esfria.
4. Taxa de qualificação (SAL para SQL): quantos dos aceitos viraram SQL depois da conversa.
5. Recusas por motivo: a distribuição dos motivos no mês, separando aceite e conversa.
6. Retorno dos devolvidos: quantos leads devolvidos voltaram a ser MQL e quantos desses fecharam negócio.

O último número costuma surpreender. Empresas que nunca registraram a devolução não sabem quanto da receita vem de leads que um vendedor um dia recusou. É exatamente o dado que justifica manter a nutrição rodando depois da recusa.

O que muda em MQL e SQL por tipo de negócio?

A lógica é a mesma em qualquer empresa que tenha um time comercial atendendo leads, mas o peso de cada etapa muda com o tamanho do ticket e o tempo de decisão.

Elaboração da Alliance

Em empresas pequenas, a distinção entre MQL e SQL pode parecer burocracia. Não precisa ter cinco etapas, mas o motivo de recusa e a data de retorno continuam valendo: são eles que transformam o contato que não comprou hoje em uma venda possível depois.

Por onde começar hoje?

1. Escreva, numa página, as definições de MQL e SQL que a sua empresa usa hoje, e mostre ao comercial. Se houver discordância, ela é o ponto de partida.
2. Rode o teste do destaque acima e descubra quantos SQL estão, na verdade, recusados.
3. Decida onde o aceite e a recusa vão morar no seu CRM: etapa de pipeline, status do lead ou propriedade própria.
4. Monte a lista fechada de motivos e o destino de cada um.
5. Configure a volta da etapa por regra e o fluxo de reengajamento dos devolvidos.
6. Troque a taxa única de MQL para SQL pelas seis medidas da seção de métricas.

Se o desenho do repasse, da nutrição e da devolução ainda não existe na sua operação, é o tipo de trabalho que fazemos no serviço de inbound e nutrição de leads da Alliance. E se você quer saber antes onde está o maior gargalo do seu funil, o diagnóstico de marketing gratuito é um briefing guiado que avalia, entre outras frentes, geração de leads, nutrição e retenção.