Cada contacto entra numa sequência, recebe os emails no seu próprio calendário, e o caminho muda no instante em que responde. E o que oferecemos não é um PDF — é um micro-SaaS feito à medida da vertical. Construído numa instância isolada do Dispatch — sem tocar no QI nem no GLSP.
Arrasta o fundo para navegar, scroll para zoom, arrasta os nós. Responder a qualquer um dos 3 emails chama sempre o humano.
A mesma plataforma, dois motores opostos. É isto que justifica construir de novo em vez de adicionar uma feature.
A campanha é a unidade. Fan-out de todos os emails de uma vez (batch.send). Sem memória do lead.
O lead é a unidade. Avança passo-a-passo no seu calendário (emails.send individual + threaded). Estado próprio.
O diferencial não é o cold email — toda a gente faz. É o que ele entrega: em vez de um PDF, um micro-SaaS "reverse lead magnet" feito à medida da vertical, com valor em menos de 60s só a partir do URL do lead.
Em vez de filtrar Apollo às cegas, partir de registos oficiais (0% lixo) — uma app por vertical serve todos os leads dela.
2 a 3 emails curtos, sem link, a oferecer construir algo à medida. O objetivo é um reply — só aí, já no domínio quente, segue o link da app pré-preenchida. Volume artesanal: 10-20/dia no arranque.
É isto que distingue cold de newsletter. O caminho do lead bifurca conforme o que ele faz.
Pausa a automação + alerta Telegram. O João responde de joao@digitalimpact.pt e envia o link da app pré-preenchida → call. Sem auto-nurture.
No fim da sequência sem resposta → entra num re-engajamento de ~7 emails. Intenção a decidir, §09.
Hard bounce (webhook) → bounced, nunca mais envia. A prevenção pré-envio é que conta.
Opt-out (token HMAC, já existe) → unsubscribed, sai da máquina.
O worker do cron substitui o processCampaignChunk actual. O pipeline inbound é totalmente novo — é o que activa o handoff humano.
O cold sai sempre do domínio descartável. Quando a conversa aquece, passa para o inbox de sempre — que nunca envia cold.
Cada fase entrega algo verificável. As fases 0-4 não enviam um único email.
Supabase nova + PM2 dispatch-di + Caddy + .env + migrations base 0001-0006.
As 5 tabelas novas + RLS + tipos TS. Só na DB nova.
Envio gota-a-gota, cap, janela, warm-up ramp. Adapter pattern, emails.send threaded.
Resend Inbound + matching + pausa + Telegram. Activa o handoff humano.
Construtor de sequências + dashboard de enrollments. Reaproveita o shell actual.
Validação pré-envio (sintaxe + MX/DNS), warm-up lento, monitorizar bounce. Arranca a 10-20/dia.
Cold é proibido nos ESPs. Consequência súbita: aviso, throttle ou suspensão.
Cenário mais provável. Cold via ESP + domínio novo cai mais em Promoções/Spam.
Listas cold têm muito mais inválidos. Num domínio frio o estrago é rápido (QI deu ~17%).
Cold B2B na UE é zona cinzenta. B2C cold sem consentimento está fora.
digitalimpactpro.pt verificado, conta própria coldemails@digitalimpact.pt, região eu-west-1 (Ireland). Separada das contas do QI e GLSP.
Como usas hoje o joao@digitalimpact.pt (webmail cPanel / IMAP / cliente) — para garantir inbox real quando o lead responder.
Re-engajamento automático de quem não respondeu vs sequência manual para warm leads vs qualificação progressiva. Muda conteúdo e cadência.