00 · Leitura de contexto

Como eu entendi o problema

Quando li o case, minha primeira reação foi: o gargalo aqui não é ferramenta, é processo. O fluxo atual Speedio → CSV → Clay → CSV → HubSpot faz tudo funcionar, mas exige trabalho manual em cada etapa. Dobrar volume assim significa dobrar dor. Então a pergunta que guiou tudo foi: como a gente conecta isso de ponta a ponta sem criar um monstro difícil de manter?

O segundo ponto que ficou claro: os Desafios 1 e 2 não são problemas separados. Automação sem scoring gera volume sem direção. Scoring sem automação não escala. Os dois precisam funcionar juntos, e as decisões de arquitetura de um afetam o outro diretamente.

Também tentei ter clareza sobre quem lê isso: a pessoa que cuida do número global quer saber se a meta de 800 SQLs é atingível e como. O head de IS quer entender se o BDR vai ter a vida facilitada ou complicada. E quem avalia a arquitetura quer ver se as decisões fazem sentido técnico e se aguenta crescer. Tentei responder às três ao mesmo tempo.

Algumas coisas ficaram sem resposta volume atual por BU, estado do waterfall no Clay, campos custom no HubSpot. Essas lacunas afetam detalhes de implementação, mas não mudam a direção da solução. Marquei onde isso importa ao longo dos slides.

01 · Máquina de listas · arquitetura

Do CSV manual para um fluxo orquestrado

A lógica do fluxo é simples: o Pipefy segura a entrada ninguém roda coleta sem um card aprovado. O n8n orquestra tudo no meio. O Clay enriquece. O HubSpot recebe. Cada ferramenta faz o que faz bem, e nenhuma faz o que não é dela.

PPipefy LDR preenche card: BU, volume, filtros → move para "Aprovado"
→
n8n8n Webhook Trigger (demanda) ou Cron semanal
SSpeedio API coleta com filtros por BU (CNAE, faturamento, UF)
→
CClay waterfall de enriquecimento + decision makers
HHubSpot upsert com CNPJ como chave de deduplicação
→
PPipefy card atualizado + Slack #gtm-ops notificado

Por que Pipefy como intake?

Sem aprovação formal no card, o n8n não dispara. Evita coletas não planejadas que consomem crédito Clay à toa o que no Enterprise é cara.

Por que n8n no meio?

Speedio não tem integração nativa com Clay ou HubSpot. O n8n é o orquestrador: webhooks, retry, validação e observabilidade num lugar só.

Por que Clay faz o waterfall?

Delegar ao Clay evita duplicar a requisição à Speedio e estourar rate limit. Os créditos Enterprise (+100k/mês) absorvem isso com folga.

01 · Máquina de listas · nós do n8n

Os 9 nós do workflow n8n

# Nó O que faz Configuração
1Webhook / Schedule TriggerPonto de entradaWebhook do Pipefy ou cron 0 6 * * 1
2Set NodeMonta os filtros para a SpeedioExtrai BU, filtros e volume do payload
3HTTP RequestChamada para a Speedio APIPOST com Bearer token + paginação
4Split In BatchesQuebra em lotes de 50Respeita rate limit de 1.000 req/h
5Wait NodePausa entre lotes4s 50 leads/4s = 750 req/h (margem segura)
6IF NodeValidação mínima de dadosDescarta lead sem CNPJ, sem telefone E sem email
7HTTP RequestEnvia lead para o ClayPOST no webhook da tabela Clay (um por lead)
8HTTP RequestAtualiza card no PipefyPATCH: status "Em enriquecimento"
9Slack NodeNotificação no #gtm-opsBU, volume coletado, válidos, timestamp

Ponto de risco crítico: se as chamadas de decision makers fossem feitas no n8n, cada empresa exigiria 2 requisições → 12.000 req para 6.000 leads = 12× o rate limit por hora. Delegar ao Clay resolve isso sem sobrecarregar a coleta.

01 · Webhooks & volume

Os 4 webhooks do fluxo

① Pipefy → n8n

Automations do Pipefy → trigger "Card moves to phase: Aprovado" → POST para o Webhook Trigger Node.

② n8n → Clay

Clay → nova tabela → Add source → Webhook (gera URL única). Cola no HTTP Request do n8n. Um POST por lead.

③ Clay → HubSpot

Integração nativa do Clay não webhook. Upsert Contact + Company. Chave: CNPJ + email validado.

④ Clay → n8n (callback opcional)

"Run when all enrichments complete" → POST no n8n → atualiza card Pipefy para "Concluído". Fecha o loop de rastreabilidade.

O webhook ④ é opcional mas fecha a rastreabilidade: o LDR sabe exatamente quando a lista saiu do Clay e está pronta no HubSpot sem precisar perguntar para ninguém.

01 · Riscos & feedback loop

Riscos nomeados, não escondidos

Risco Impacto real Como tratamos
Rate limit Speedio (1.000 req/h)Coleta interrompe sem avisoBatch de 50 + Wait 4s + retry com backoff exponencial + alerta no Slack
Clay falha silenciosa em campos críticosLead incompleto chega no HubSpotIF Node valida campos obrigatórios; incompletos vão para fila de revisão no Pipefy
Créditos Clay acima do planejadoLimite mensal esgota antes do tempoDashboard semanal + alerta automático em 70%
Duplicidade no HubSpotRegistros conflitantes do mesmo leadUpsert explícito com CNPJ + email nunca Insert puro
n8n como ponto único de falhaFluxo trava sem ninguém perceberHealth check via cron auxiliar → alerta no Slack se workflow não executar
Lead sem email E sem telefoneContato inviável na cadênciaIF Node filtra antes do Clay; vão para Pipefy com tag "Dado incompleto"

Feedback loop o que conecta o D1 ao D2: quando um lead vira SQL ou é descartado com motivo no HubSpot, esse dado retroalimenta o modelo. Quinzenalmente, comparo convertidos vs. descartados e isso calibra os filtros de coleta da Speedio e os pesos do scoring no Clay. O scoring retroalimenta os filtros, não o contrário.

01 · Mapeamento de campos

Campos no HubSpot sem planilha paralela

Esses campos sustentam tanto o trabalho diário do BDR quanto as variáveis do modelo de scoring. A escolha foi intencional para não precisar criar campos extras depois que o scoring entrar.

Empresa
  • Company Name ← razao_social
  • CNPJ (custom · chave de upsert)
  • Industry ← cnae_primario
  • Secondary Industry (custom)
  • Revenue Range ← faixa_faturamento
  • Number of Employees
  • City / State
  • Phone + Generic Email
  • Website
Decision maker
  • First / Last Name
  • Job Title ← position
  • Department
  • Seniority (custom) ← level
  • Email ← mchecker_email
  • Email Valid Status (custom)
  • LinkedIn URL
Enriquecido pelo Clay
  • Tech Stack (tecnologias em uso)
  • Recent Hiring Signal
  • Lead Score (custom)
  • Lead Tier (custom)

O BDR vê o tier direto na fila do HubSpot sem abrir planilha, sem interpretar fórmula.

01 · Decisão LGPD

IP tracking do Clay: por que não usar aqui

Problema técnico

No Brasil, rastreamento de IP para identificar empresa visitante não tem cobertura confiável. A maioria das empresas usa provedores compartilhados, e a taxa de match com empresa específica é baixa demais para ser acionável. O custo de implementação não se paga.

Problema jurídico

Mesmo que a cobertura fosse boa, coletar IP sem consentimento prévio conflita com o Art. 7º da LGPD. Legítimo interesse pode ser alegado, mas exige LIA documentado e expõe a operação a risco regulatório especialmente no FSI, onde bancos avaliam rigorosamente os parceiros que tratam seus dados.

O que funciona: usar os sinais de intenção que o Clay já captura no enriquecimento tecnologias em uso, contratações recentes, stack via Speedio. Base legal mais sólida (dados públicos), sem dependência de rastreamento, e na prática entrega mais contexto acionável para o BDR do que um IP jamais entregaria.

02 · Lead scoring · BU CRM

Modelo de scoring BU CRM

Por que CRM? ICP mais amplo no Brasil, mais fácil de capturar via Speedio. O pitch se fecha bem: a empresa automatiza o processo do cliente dela, mas o processo comercial dela ainda é manual. A contradição é o argumento.

Variáveis & pesos · soma 100 pontos

Porte (funcionários)
20 pts
Fit estrutural
Setor (CNAE)
20 pts
Fit estrutural
Cargo do contato
20 pts
Decisor
Presença digital
15 pts
Maturidade
Tech stack
10 pts
Maturidade
Contratações recentes
10 pts
Intenção
Dados validados
5 pts
Eliminatório

Lógica dos pesos: porte + setor + cargo (60%) definem fit estrutural lead fora do ICP não converte independente de qualquer outro sinal. Presença digital + tech stack são proxies de maturidade. Hiring é o sinal de intenção mais confiável disponível no Brasil. Dados validados pesam pouco mas são eliminatórios na prática via IF Node do n8n.

02 · Tiers & implementação Clay

Classificação em tiers

O BDR não precisa entender a fórmula ele vê o tier na fila e sabe o que fazer.

🔴 Hot

Liga hoje · todos os canais disponíveis

≥ 70
🟠 Warm

Esta semana · email + 2 tentativas de call

≥ 45
🟡 Cool

Cadência longa de email · 30 dias

≥ 25
⚪ Cold

Não trabalha · revisão em 60d ou descarte

< 25

Hot em 70 (não 60) porque o modelo é puramente firmográfico sem dado comportamental, melhor ser conservador no topo.

Fórmulas no Clay

# cada dimensão = 1 coluna de fórmula

score_porte = IF(qnt_func >= 500, 20,
                IF(qnt_func >= 100, 15,
                IF(qnt_func >= 50,  10, 0)))

score_setor = IF(cnae IN lista_A, 20,
                IF(cnae IN lista_B, 10, 0))

score_cargo = IF(level == "C-level", 20,
                IF(level == "Gerente", 15,
                IF(level == "Coord",    8, 0)))

# ... idem digital, techstack, hiring, dados

lead_score = score_porte + score_setor +
             score_cargo + score_digital +
             score_techstack + score_hiring +
             score_dados

tier       = IF(lead_score >= 70, "Hot",
              IF(lead_score >= 45, "Warm",
              IF(lead_score >= 25, "Cool", "Cold")))
Ver tabela real no Clay →

Abre em uma nova aba · tabela compartilhada

02 · Sinais de intenção · contexto BR

Intent data no Brasil o que realmente funciona

G2, Bombora, review de concorrente esses sinais simplesmente não existem aqui com a maturidade que têm fora. Então o modelo precisa se sustentar com o que tem, e tem coisa boa.

Contratações recentes via LinkedIn

Vaga aberta para Coord. de CRM, Analista de Processos ou Head de Vendas é o sinal mais limpo que encontrei. Indica momento de estruturação com budget já alocado não é intenção futura, é movimento presente.

Stack tecnológico via Clay

Empresa que já usa Salesforce ou HubSpot tem cultura de ferramenta o pitch de processo faz sentido para elas. Ausência total de stack pode ser oportunidade ou resistência; depende do porte e setor.

Faixa de faturamento R$ 10M R$ 100M

Abaixo disso falta budget para solução enterprise. Acima geralmente já tem ferramenta consolidada. Essa faixa é onde as empresas estão estruturando processo comercial e precisam de ajuda para fazer isso direito.

CNAE secundário como proxy

Promoção de vendas (7319002) ou teleatendimento (8220200) no CNAE secundário é sinal direto de que automação de relacionamento comercial já faz parte do negócio deles.

Com esses quatro sinais combinados hiring + stack + faturamento + CNAE o modelo firmográfico brasileiro consegue discriminar bem sem depender de dado comportamental. A calibração quinzenal com histórico de conversão vai ajustando os pesos ao longo do tempo.

02 · Calibração

Como saber se o modelo está funcionando

Métrica principal: taxa de conversão por tier

Se o modelo funciona, Hot converte significativamente mais que Warm, que converte mais que Cool. Taxa parecida entre tiers significa pesos errados não dados ruins.

Cronograma de validação

Semana 1Sem esperar dado novo

Pontuar retrospectivamente os últimos 30 dias do HubSpot

Já dá para ter hipótese inicial de correlação com o que já converteu sem custo de espera.

Semana 2Proxy antecipado

BDRs trabalhando a lista ranqueada · monitorar conexão por tier

Conexão não é SQL, mas é o primeiro sinal de que o modelo está discriminando certo. Custo zero de espera.

Semana 3Primeira revisão

Primeira revisão de pesos com dado real

Se Hot não conecta pelo menos 2× mais que Warm, o ranqueamento está errado e dá para corrigir já.

Dia 30Análise definitiva

Primeira análise de SQL por tier com volume suficiente

Ajuste de thresholds + recalibração das variáveis que não estão contribuindo.

Sinal de alerta: se no dia 30 a conversão de Hot for menor que 2× a de Warm, o problema está provavelmente nas variáveis de topo porte e setor. Recalibrar por lá primeiro, não nas dimensões de menor peso.

03 · Diagnóstico de lista ruim

"Essa lista que você montou
para o FSI está ruim."

Segunda-feira. 70 contatos. 3 conexões. Zero reuniões.

Antes de qualquer coisa, eu precisaria entender se o problema está na lista ou em como ela foi trabalhada. 3 de 70 pode ser dado ruim, perfil errado, horário ruim, ou volume de tentativas insuficiente e a correção é completamente diferente em cada caso. Sair atirando para o lado da lista sem verificar é tão ruim quanto ignorar o problema.

O que eu olharia primeiro

1
Em que horário foram feitas as ligações?
3/70 = 4%. Para FSI, uma taxa saudável seria 8 15%. Se tudo foi cedo ou no fim do dia, pode ser só timing.
chegando até o lead?
2
Qual era o cargo das pessoas abordadas?
No FSI, o decisor real é C-level ou VP. Se a lista estava cheia de analistas e coordenadores, o problema não é a lista em si é o perfil que entrou nela.
falando com quem decide?
3
Quantos contatos tinham email e telefone validados?
Se metade tinha dado inválido, o problema é de enriquecimento não de execução. O BDR não tem como ligar para número que não existe.
qualidade do dado
4
Das 3 conexões, o que aconteceu?
"Sem interesse", "não é o momento", "falei com a pessoa errada" cada resposta aponta para um lugar diferente. Essa é a pergunta mais importante.
o pitch está chegando certo?
5
Esse perfil já converteu antes, em outras listas?
Se sim, provavelmente é dado ou execução. Se nunca converteu, pode ser que esse ICP simplesmente não funciona para FSI e aí a conversa é outra.
existe histórico?
03 · Hipóteses por camada

Separar antes de concluir dois grupos de hipóteses

Hipóteses de lista

  • ICP errado para FSI setor com ciclo longo, agenda bloqueada, resistência cultural a cold call.
  • Dados desatualizados rotatividade alta no mercado financeiro BR; quem era decisor pode ter saído.
  • Enriquecimento incompleto telefones inválidos e emails sem validação chegaram à cadência sem filtro.

Hipóteses de execução

  • Horário fora da janela FSI conecta melhor entre 10h 12h e 14h 16h.
  • Volume de tentativas insuficiente 70 ligações podem ser 70 contatos com 1 tentativa cada. O mercado recomenda 6 8 por contato.
  • Pitch genérico para FSI bancos respondem a compliance, eficiência operacional e redução de risco; não a "automação de processos".

Como distinguir sem cravar antes de investigar

< 5%

Problema é lista ou dado

Ninguém atende. Investigar cargos, validade de dado e horário antes de olhar para o pitch.

5 8%

Hipóteses mistas

Investigar as duas camadas em paralelo antes de concluir qualquer coisa.

> 8%

Conexão boa, zero reuniões

Estão atendendo mas não compram o pitch. Investigar qualidade das conversas, não a lista.

Cuidado real: processo é 100% manual hoje, sem feedback loop estruturado. Os dados de call no HubSpot podem não estar suficientemente limpos. Plano B: conversa estruturada com o BDR para reconstruir horário de cada call, cargo abordado, tentativas por contato e o que foi dito nas 3 conexões.

03 · Plano de ação · 2 dias

Plano de ação · 2 dias úteis

Dia 1 Investigação nos dados

Manhã antes das 10h

  • Comunicar ao head de IS a pausa e o prazo de retorno.
  • Puxar do HubSpot: taxa de conexão por horário, distribuição de cargo, % dados validados, tentativas por contato único.

Tarde

  • Cruzar com histórico esse perfil já converteu antes?
  • Identificar se o problema está num subgrupo específico.
  • Montar diagnóstico inicial: qual hipótese os dados suportam com mais força.

Dia 2 Hipótese e proposta

Manhã

  • Conversa com head de IS: apresentar o que os dados mostram sem conclusão sobre performance do BDR, só sobre lista e dado.
  • Trazer hipóteses por camada e pedir contexto das 3 conexões.

Tarde proposta de correção

  • Se for lista: nova rodada com filtros ajustados cargo mais alto, validação rígida, horário orientado para FSI.
  • Se for execução: fica com o gestor do time. Meu papel foi entregar o diagnóstico.

Entrega no fim do dia 2: documento curto com o que os dados mostraram, qual hipótese é mais provável e o que foi ajustado. Sem achismo. Sem apontar culpado.

04 · Primeiros 30 dias

O que eu faria nos primeiros 30 dias

A ordem importa: automação sem scoring é volume sem direção. Scoring sem automação não escala. As duas precisam funcionar juntas para 800 SQLs/mês ser atingível.

Semana 1Entender

Mapear o estado real onde o processo manual quebra hoje

O que o time sente como dor, o que o histórico do HubSpot diz sobre conversão por BU. Não construir solução em cima de premissa errada.

Semana 2Construir

Construir e testar o fluxo de automação para uma BU

Validar com o LDR antes de escalar. Uma BU funcionando bem vale mais do que quatro pela metade.

Semana 3Calibrar

Rodar o scoring em paralelo com o processo atual

Pontuar retroativamente os últimos 30 dias e verificar se o modelo discrimina o que já converteu. Calibrar com histórico antes de comprometer cadência de BDR.

Semana 4Escalar

Apresentar resultados e escalar para as demais BUs

Ajustar pesos com dado real, escalar automação e definir ritmo de calibração. Fechar o ciclo de aprendizado antes de aumentar volume.

1 / 18
Capa