Funil B2B com histórico de etapas

Fonte

Histórico de etapa e de dono no CRM

Regra

Indicador declarado, data oficial e papel no momento

Resultado

Funil por coorte e por produção, com crédito por pessoa

Ativação

Dashboard, ranking, agente de IA e alertas

O que resolve

Todos os painéis passam a mostrar o mesmo número de MQL, SQL e venda.
Cada etapa tem uma data oficial, mesmo quando o deal pulou etapa ou voltou atrás.
SDR e closer recebem crédito pelo que fizeram, mesmo que o deal tenha mudado de dono depois.

Perguntas de negócio que responde

Faça estas perguntas ao seu agente quando o caso estiver pronto.

Quantos MQL, SQL, demos e vendas aconteceram em setembro, por SDR?

Dos leads que entraram em julho, quantos já viraram venda?

Quanto tempo um deal fica em cada etapa antes de avançar ou ser perdido?

Qual a taxa de qualificação por origem e por canal?

Quanto tempo o time leva para atender um lead inbound?

Como estamos contra a meta do mês por time e por vendedor?

O que você precisa

CRM conectado na Nekt com histórico de etapa e de dono
Definição combinada de MQL, SQL, demo e venda, com as exclusões
Metas por mês e por pessoa ou canal, numa planilha ou tabela

O que você recebe

Tabela de eventos de etapa, com data, autor e ordem
Funil por coorte e por produção mensal, sem misturar os dois
Ranking de SDR e closer com crédito no momento do evento
Agente de IA que responde sobre funil com as definições oficiais

Onde ativar

Dashboard comercial

Funil por coorte e por produção lado a lado, com a definição de cada etapa visível.

Agente de IA via MCP

Responde quantos SQL o time gerou, ou quanto falta para a meta, usando a tabela de indicadores.

Alertas de SLA

Lead inbound sem primeiro toque em N horas úteis e deal parado na etapa além do limite.

Quer construir?

O histórico já vem do conector. O trabalho está em fechar as definições com o time e mapear etapas, papéis e exclusões. O detalhado traz as regras de negócio, as armadilhas e o teste de aceitação. Ou mande tudo direto para o seu agente com o MCP da Nekt.

Ver detalhado

O problema

O CRM mostra onde cada deal está agora, e não quando passou por cada etapa nem quem cuidava dele naquele dia. Cada painel reimplementa a definição de MQL do seu jeito e os números divergem na reunião de liderança. Quem conta pelo estado atual perde os deals que pularam etapa, conta deal perdido como avanço e dá a venda para o último dono.

Como costuma ser feito, e a regra

Cada linha é um erro que já aconteceu na prática.

O jeito comumA regra

A definição de MQL escrita dentro de cada painel ou medida do BI.

A definição de cada indicador mora num lugar só

Declare numa tabela de indicadores o que conta como MQL, SAL, SQL, demo e venda: a etapa ou evento que marca, a data oficial, a tabela de origem, o papel que recebe o crédito e as exclusões. Painéis, relatórios e o agente de IA leem dessa tabela. Separe tradução de regra: dizer que Closed Won e Ganho são a mesma etapa é de-para; dizer que Ganho é o marco de venda é definição de indicador.

Usar hs_v2_date_entered_<stageId> como data de quando o deal virou SQL.

Data oficial é a primeira entrada, tirada do histórico

A data de uma etapa é a primeira vez que o registro entrou nela ou em qualquer etapa posterior, lida do histórico de mudanças (propertiesWithHistory.dealstage no HubSpot, leadhistory e opportunityhistory no Salesforce, deal_flow no Pipedrive). Os campos prontos de data de entrada guardam a última entrada: se o deal voltou para a etapa, a data anda para frente. Use o campo pronto só como conferência.

Contar SQL só por quem tem a data de reunião agendada preenchida.

O funil é monotônico: chegar adiante prova o que veio antes

Tem SQL quem tem a data de reunião agendada ou de qualquer etapa depois dela (reunião realizada, proposta, contrato, ganho). Deal que foi direto para contrato agendou, mesmo sem o registro intermediário. Quando falta a data do lead (lead criado direto como oportunidade), a data âncora da coorte é a da oportunidade. Etapas de prospecção que existem só em um pipeline (por exemplo, tentativa de abertura em venda de campo) ficam fora do funil até o deal chegar à primeira etapa comum.

Calcular avanço pela ordem da etapa e decidir ganho pelo nome dela.

Perdido não é progressão, e algumas etapas não entram na conversão

Ir para Perdido nunca conta como avanço, mesmo que Perdido fique depois na ordem do pipeline. Etapas como lead frio e no-show saem da tabela de conversão, mas não bloqueiam a progressão: o deal que passou por no-show e depois fechou segue contando como agendado e ganho. Status do deal vem das flags de ganho e de fechamento (ganho, senão fechado é perdido, senão aberto), nunca do nome da etapa.

Pegar o MAX da data por etapa e tratar cada linha do histórico como uma entrada.

Uma visita nova só quando a etapa muda de fato

O histórico traz linhas repetidas, com o mesmo valor da linha anterior (sincronização, merge, reprocessamento). Marque como início de visita só a linha cuja etapa difere da anterior do mesmo registro. O tempo em etapa vai da entrada até a próxima mudança real; reentradas viram visitas separadas, e o total por etapa soma as visitas.

Filtrar o funil de coorte por data_sql para responder quantos SQL houve no mês.

Coorte e produção são perguntas diferentes

Coorte: a população é definida pela data de criação do lead, e cada etapa é contada para esses leads, em qualquer data. Produção: cada etapa é contada no mês do seu próprio evento, sem deduplicar por lead. Responda com a visão que a pergunta pede e diga qual usou. Nunca filtre a tabela de coorte pela data de SQL ou de venda: isso cria uma visão híbrida que não é nenhum dos dois KPIs.

Dar MQL, SQL e venda para o dono atual do deal.

O crédito vai para quem tinha o papel no momento

Um registro tem papéis diferentes ao mesmo tempo: SDR, que qualifica, e closer ou AE, que fecha. Guarde a linha do tempo de cada papel (histórico de hubspot_owner_id e do campo de SDR) e atribua cada etapa a quem tinha o papel na data do evento. Congele o papel comercial da pessoa (SDR, closer, time, região) na primeira vez que ela aparece ou use o histórico de cargos, para que uma promoção não reescreva o passado. Se o time tem janela de redistribuição de carteira no início do mês, defina o dono do mês como o dono no fim dessa janela.

MQL = lead criado.

MQL é fit declarado, não todo lead

Contar todo lead como MQL infla o número em cerca de três vezes. MQL é o lead que atende ao ICP pelas respostas declaradas na entrada (segmento, porte, volume), ou o lead menos os descartados por uma lista fechada de motivos de perda. Se o fit é recalculado depois incluindo quem já qualificou, ele fica circular: para qualidade na chegada, use só os campos declarados. SQL pode não ser subconjunto de MQL, e o funil MQL para SQL pode passar de 100%; decida a regra e diga na resposta.

Somar upgrades como vendas e contar reuniões automáticas como agendadas.

Declare o que não entra em cada etapa

Upgrade e expansão da base entram na receita nova da carteira, nunca em SQL, demo ou venda de aquisição. Reunião marcada por agente de IA ou por automação não conta como agendada até um humano confirmar. Mudanças feitas por usuários de integração ou automação ficam fora das contagens de movimentação por pessoa. Deals arquivados ou mesclados (hs_merged_object_ids) saem, e data de fechamento anterior à criação é tratada como erro de cadastro.

Somar receita das linhas de produto e somar todos os escopos da meta.

Receita é do deal; meta se compara num escopo só

Valor contratado é métrica do deal. Abrir por linha de produto serve para mix, nunca para somar receita como se cada linha fosse um deal. Na meta, a mesma planilha costuma trazer o total, o recorte por canal e o recorte por produto nas mesmas linhas: filtre um escopo antes de somar. O realizado entra no mês da data oficial de venda, e moeda estrangeira é convertida por uma taxa declarada.

Etapa, data oficial e quem recebe o crédito

Modelo de tabela de indicadores. Ajuste nomes e exclusões ao seu CRM.

LeadCriação do lead ou do contatodono do lead na criação

MQLPrimeira vez com fit declarado ou fora dos descartesdono do lead nessa data

SALAceite do lead pelo SDRSDR que aceitou

SQLPrimeira entrada em reunião agendada ou etapa posteriorSDR na data; sem upgrade

DemoReunião realizada ou proposta criadacloser na data

VendaPrimeira entrada em ganho (flag de ganho)closer e SDR de origem; sem upgrade

PerdidoFechado sem ganho, com motivo mapeadonunca conta como progressão

No-show, lead frioFora da conversãonão bloqueia a progressão

Definições

Data oficial da etapa

primeira data de entrada do registro na etapa ou em qualquer etapa posterior, lida do histórico de mudanças, no fuso local

MQL

lead com fit declarado ao ICP, ou lead menos descartados por motivo mapeado, contado na data em que passou a cumprir a regra

SQL

deal com data de reunião agendada ou de qualquer etapa posterior, excluindo upgrade e reunião não confirmada por humano

Venda

deal com flag de ganho, contado na primeira entrada em ganho, excluindo upgrade e expansão

Conversão de coorte

registros da coorte (mês de criação do lead) que chegaram à etapa B / registros da mesma coorte que chegaram à etapa A

Produção do mês

quantidade de eventos da etapa com data oficial dentro do mês, sem deduplicar por lead

Tempo em etapa

da entrada na etapa até a próxima mudança real de etapa, por visita, em dias úteis quando usado como SLA

Tempo de atendimento

da criação do lead inbound até o primeiro toque humano posterior a ela, em minutos de horário comercial (segunda a sexta, 8h às 18h, fuso local)

Atingimento

realizado do escopo no período / meta do mesmo escopo no período

Armadilhas que já aconteceram

Dois painéis, dois MQLs

A definição vivia dentro de uma medida do BI, foi reescrita em outro painel e os números divergiram na frente da liderança.

Uma tabela de indicadores declarada, lida por todos os painéis e pelo agente.

Motivo novo, SQL fantasma

A desqualificação dependia de um de-para de motivos numa planilha. Quando surgiu um motivo novo, ele não desqualificava e o lead seguia contando como SQL, sem erro nenhum.

Teste que lista motivos sem mapeamento e alerta, em vez de cair num ELSE silencioso.

Histórico que não existia

O rastreamento de campo da oportunidade só foi ligado no meio do ano, e os meses anteriores pareciam sem mudança de etapa. O histórico nativo de oportunidade, que grava fase sem depender de configuração, recuperou cerca de três vezes mais mudanças.

Confira de quando é cada fonte de histórico e use a que cobre o período.

Fuso aplicado duas vezes

Timestamps chegam em UTC e foram convertidos numa camada e de novo na seguinte, empurrando eventos da noite para o dia errado.

Converta para o fuso local uma única vez, na primeira camada tratada, e documente.

Mais da metade nunca virou SQL

Num pipeline de venda de campo com etapas de prospecção antes da reunião, contar todos os deals como SQL mais que dobrava o número.

SQL pelo teste monotônico, nunca pela contagem de deals do pipeline.

Meta triplicada

A tabela de metas trazia total, canal e produto nas mesmas linhas, e a soma sem filtro dava três vezes a meta real.

Coluna de escopo na meta e filtro obrigatório antes de somar.

Validado em dados reais. No HubSpot da própria Nekt, quando um deal voltou para uma etapa em que já tinha estado, o campo hs_v2_date_entered daquela etapa guardou a data da última entrada em praticamente todos os casos, e em nenhum a da primeira. Cerca de 2% das linhas do histórico de etapa repetem a etapa da linha anterior, e uma parte delas vem de merge de deals, por isso a visita nova só começa quando a etapa muda.

Teste de aceitação

O caso está pronto quando todos os itens passam.

Para um mês fechado, MQL, SQL e vendas por SDR na visão de produção batem com a contagem feita no CRM pelas mesmas datas oficiais (diferença zero, ou explicada por deal arquivado ou mesclado).
Nenhum deal tem venda sem ter SQL: todo registro com data de ganho tem data de SQL menor ou igual a ela.
Em todo deal que reentrou numa etapa, a data oficial é a primeira entrada e o número de visitas é maior que 1.
A soma do atingimento por canal, filtrando o escopo canal, fecha com o atingimento do escopo total (diferença abaixo de 1%, ou explicada por deal creditado a dois canais).
Nenhuma linha de movimentação tem como autor um usuário de integração ou automação.

Pacote para o agente

Cole no Claude, ChatGPT ou outro cliente com o MCP da Nekt conectado.

Markdown completo

Funil comercial B2B
- As definições de MQL, SAL, SQL, demo e venda estão na tabela de indicadores. Não improvise equivalentes.
- Data oficial de uma etapa = primeira entrada nela ou em etapa posterior, tirada do histórico. Os campos hs_v2_date_entered_<stageId> guardam a última entrada; não use como data oficial.
- SQL = tem data de reunião agendada ou de qualquer etapa posterior. Nunca teste só a data de agendamento.
- Perdido não é progressão. No-show e lead frio ficam fora da conversão, sem bloquear quem avançou depois.
- Status do deal: ganho pela flag de ganho; fechado sem ganho é perdido; o resto está aberto. Nunca pelo nome da etapa.
- MQL = fit declarado ao ICP. Todo lead não é MQL. SQL pode não ser subconjunto de MQL: diga isso se a conversão passar de 100%.
- Upgrade e expansão não entram em SQL, demo nem venda de aquisição.
- Reunião marcada por IA ou automação só conta como agendada depois da confirmação humana.
- Crédito vai para quem tinha o papel (SDR ou closer) na data do evento, nunca para o dono atual.
- Coorte (por criação do lead) e produção (por data de cada etapa) são visões diferentes. Diga qual está usando. Nunca filtre a coorte pela data de SQL.
- Tempo de atendimento e tempo em etapa como SLA são medidos em dias úteis ou horário comercial, no fuso local.
- Receita é do deal. Meta: filtre um escopo (total, canal, produto, pessoa) antes de somar.
Exceções por cliente:
- <cliente>: o pipeline <nome> tem etapas de prospecção antes do SQL; deals parados nelas não entram no funil.
- <cliente>: a carteira é redistribuída até o dia <n> do mês; o dono do mês é o dono nesse dia.
- <cliente>: valores em <moeda> convertidos pela taxa fixa de <x>.

Construa no meu workspace Nekt o caso "Funil B2B com histórico de etapas" seguindo as regras em https://academy.nekt.com/industrias/saas/funil-b2b-historico-etapas.md. 1) Encontre as tabelas de origem e confirme as colunas usadas pelas regras. 2) Crie uma transformação no grão indicado aplicando todas as regras. 3) Rode o teste de aceitação e me mostre o resultado de cada item. 4) Crie o context document do caso no workspace, com as exceções dos meus clientes em aberto para eu preencher.

Variações

CRM em migração

Dois CRMs no mesmo período: uma linha por deal com o sistema de origem e uma data de corte da migração, sem contar o mesmo deal duas vezes.

Forecast semanal

Foto semanal dos deals abertos com categoria de forecast; compare duas fotos filtrando as duas pelo trimestre vigente no início da semana.

Funil de self-service

Mesma estrutura de eventos para cadastro, ativação e assinatura, com o produto no lugar do CRM.