Sequências de Email com IA

A maioria das aplicações SaaS envia três emails. Um email de boas-vindas, um reset de password e talvez um recibo de pagamento. Isso cobre cerca de 10% do ciclo de vida.

Os outros 90% são silêncio. Um utilizador regista-se, explora durante um dia, e nunca mais volta. Ninguém faz follow-up. Ninguém explica o que o produto realmente faz. Ninguém envia um lembrete quando o trial está prestes a expirar. O utilizador vai embora antes de alguma vez chegar à parte da aplicação que o faria ficar.

Aqui está o que falta: os fluxos de email automatizados representam cerca de 2% do volume total de emails mas geram 37% da receita de email. Os emails que a maioria dos fundadores ignora são os que geram a maior parte do dinheiro.

Este post mostra um sistema que constrói todos esses emails de uma vez. Um comando. Seis agentes de IA a trabalhar em paralelo. Resultado: 17 templates de email, 6 funções de background job, eventos de gatilho ligados e código com verificação de tipos pronto a correr localmente.

As 6 sequências que a maioria das aplicações SaaS não tem

Um sistema de email de ciclo de vida cobre seis fases. Cada uma visa um momento diferente na jornada do utilizador.

Boas-vindas é a sequência de maior valor. Os primeiros emails de boas-vindas têm taxas de abertura médias de 55-70%. Os 10% melhores de empresas SaaS chegam a 75%+. Essa é a melhor atenção que alguma vez vais obter de um utilizador. Quatro emails ao longo dos primeiros sete dias, cada um a guiá-lo mais perto do momento em que o teu produto faz sentido para ele.

Nudge de Ativação apanha a maior queda. Alguém termina o onboarding, vê o dashboard e sai. Um email 48 horas depois com uma ação específica para experimentar traz uma parte de volta.

Educação de Funcionalidades previne um tipo diferente de churn. O utilizador está ativo mas usa apenas uma funcionalidade. Três emails ao longo de duas semanas, cada um a destacar uma funcionalidade que ainda não tocaram. Campanhas segmentadas como estas geram até 760% mais receita do que envios em massa.

Incentivo ao Upgrade dispara quando o utilizador atinge um limite real, não num temporizador. Tentaram fazer algo que o plano gratuito não permite. Esse é o momento em que percebem o valor. Três emails ao longo de cinco dias: o que aconteceu, o que o plano pago inclui, e uma oferta.

Prevenção de Churn corre num background job diário. Todas as manhãs às 9h, consulta a base de dados para utilizadores que não iniciaram sessão há 7 dias. Três emails ao longo dos 30 dias seguintes. Cada um usa um ângulo diferente: "aqui está o que estás a perder", "os teus dados ainda estão aqui", e "diz-nos o que correu mal."

Win-Back começa quando o Stripe envia um webhook de cancelamento. Três emails ao longo de 30 dias. O primeiro reconhece o cancelamento. O segundo destaca o que melhorou desde que saíram. O terceiro faz uma oferta. A mensagem enquadrada como perda (o que estás a abdicar) converte 21-32% melhor do que o enquadramento positivo (o que vais ganhar).

Um estudo de 38 empresas SaaS descobriu que apenas 2 cobriam todas as fases do ciclo de vida. A maioria para na boas-vindas e na faturação. Esse espaço é onde este sistema se encaixa.

Por que a maioria das ferramentas de email não ajudam

A abordagem padrão: abre a tua plataforma de email, escolhe um template, escreve o copy, define um atraso de 3 dias, repete.

Três problemas.

Temporizadores em lote, não comportamento. A maioria das ferramentas agenda emails com atrasos fixos. "Envia o email 2 três dias depois do email 1." Isso ignora o que o utilizador realmente fez. Um utilizador que ativou no dia 1 não devia receber o mesmo nudge que alguém que nunca iniciou sessão. Os emails baseados em gatilhos (enviados com base no que um utilizador faz) têm taxas de abertura 76% mais altas e taxas de clique 152% mais altas do que os envios temporizados.

Templates HTML que matam os cliques. Emails HTML ricos com formatação pesada, imagens e grelhas de layout parecem profissionais mas têm um desempenho inferior. Os emails em texto simples têm 42% mais cliques. Os clientes de email que importam (Gmail, Apple Mail) tratam bem o texto simples. O HTML pesado aciona filtros de spam e renderiza mal em metade dos dispositivos dos teus utilizadores.

Sem ligação à tua aplicação. As plataformas de email externas não conhecem a tua base de dados. Não conseguem verificar se um utilizador já ativou antes de enviar o nudge de ativação. Não conseguem ignorar o email de upgrade para alguém que fez upgrade ontem. O sistema de email e o produto vivem em mundos separados.

O sistema: um comando, duas fases

O pipeline é um slash command do Claude Code: /emails. Lê o teu produto, desenha as sequências e constrói tudo.

.claude/
  commands/
    emails.md              # A definição do comando
  skills/
    email-sequence/        # Frameworks de design de sequências
    react-email/           # Regras de construção de templates
webapp/
  emails/                  # Templates React Email (output)
  lib/inngest/functions/   # Funções de background job (output)
  lib/emails/send.ts       # Utilitário de envio (output)

Fase 1 (Design): Um agente lê a documentação do teu produto, jornadas de utilizadores, voz da marca e preços. Desenha todas as 6 sequências com linhas de assunto específicas, timing e objetivos para cada email. Depois para e apresenta o plano. Nada é construído até aprovares.

Fase 2 (Construção): Seis agentes constroem em paralelo. Um por tipo de sequência. Cada agente escreve templates React Email (layouts de email construídos com componentes React) e funções Inngest (background jobs que gerem timing, retries e verificações de estado). Um agente base corre primeiro para criar o layout partilhado e o utilitário de envio. Depois cinco agentes constroem as suas sequências ao mesmo tempo.

Fase 1: ler o produto, desenhar sequências, aguardar aprovação

O agente de design lê tudo o que precisa para escrever emails que soem como o teu produto, não como um template.

Contexto do produto que lê:

• Visão geral do produto (o que a aplicação faz, níveis de preço)
• Jornadas de utilizadores (quem se regista, o que lhes interessa)
• Diretrizes da marca (voz, tom, nome do produto)
• Mapa de funcionalidades (o que destacar nos emails de educação)
• Fluxo de autenticação (como o registo funciona, para que a sequência de boas-vindas corresponda)
• Configuração de faturação (níveis de preço, gatilhos de upgrade)
• Cores da marca (para que os templates de email correspondam à aplicação)

A partir disso, constrói um Email Brief: o nome do produto, o "momento aha" (a ação específica onde o produto faz sentido para o utilizador), o modelo de preços, as principais funcionalidades a educar, e os gatilhos de upgrade.

Depois desenha todos os 17 emails. Para cada um: linha de assunto, objetivo, timing e o ângulo do copy.

As linhas de assunto seguem investigação. Linhas de assunto curtas (2-4 palavras) atingem taxas de abertura médias de 46% num estudo de 5,5 milhões de emails. O sistema mantém cada assunto abaixo de 50 caracteres para o corte em inboxes móveis.

O plano completo vai para ti antes de um único template ser escrito. Podes cortar sequências, mudar o timing, reescrever linhas de assunto, ou remover emails completamente. A fase de construção usa o teu plano aprovado como especificação.

Fase 2: seis agentes constroem em paralelo

Após a aprovação, seis subagentes começam ao mesmo tempo. Cada um recebe o Email Brief, o plano aprovado, as cores da marca e as skills de que precisa.

Agente 0: layout base e utilitário de envio

Corre primeiro. Cria dois ficheiros partilhados que todos os outros agentes usam.

O layout base é um componente React Email (um template de email reutilizável construído com React). Inclui o logótipo da marca, container, rodapé com link de cancelamento de subscrição e as cores da marca convertidas do CSS da aplicação.

O utilitário de envio envolve o Resend (o serviço de entrega de email). Recebe um componente React Email, converte-o tanto para HTML como para texto simples, e envia-o. Cada sequência usa esta mesma função.

Agentes 1 a 5: um por sequência

Cada agente escreve duas coisas: os templates de email e a função de background job que orquestra a sequência.

Os templates são componentes React. Cada email é um ficheiro .tsx. Props com tipos para que a linha de assunto, o nome do utilizador e quaisquer dados dinâmicos sejam todos validados antes de o email ser enviado.

As funções de background job usam o Inngest (um motor de background job que gere agendamento, retries e fluxos de trabalho orientados a eventos). Cada função define quando a sequência começa, quanto tempo aguardar entre emails, e que verificações correr antes de enviar o seguinte.

A estrutura de ficheiros depois de todos os seis agentes terminarem:

webapp/emails/
  _components/
    base-layout.tsx                  # Layout de marca partilhado
  welcome/
    welcome-1-getting-started.tsx    # 4 templates
    welcome-2-activation-nudge.tsx
    welcome-3-feature-education.tsx
    welcome-4-check-in.tsx
  activation/
    activation-nudge.tsx             # 1 template
  education/
    education-1-feature-a.tsx        # 3 templates
    education-2-feature-b.tsx
    education-3-feature-c.tsx
  upgrade/
    upgrade-1-limit-hit.tsx          # 3 templates
    upgrade-2-value.tsx
    upgrade-3-offer.tsx
  churn/
    churn-1-miss-you.tsx             # 3 templates
    churn-2-data-waiting.tsx
    churn-3-feedback.tsx
  winback/
    winback-1-sorry.tsx              # 3 templates
    winback-2-improvements.tsx
    winback-3-offer.tsx

webapp/lib/inngest/functions/emails/
  welcome-sequence.ts
  activation-nudge.ts
  feature-education.ts
  upgrade-prompt.ts
  churn-prevention.ts
  winback-sequence.ts

17 templates. 6 funções. Um layout partilhado. Um utilitário de envio.

Ramificação comportamental: reage ao que os utilizadores fazem, não a quando se registaram

Esta é a parte que separa o sistema de um drip baseado em temporizador.

O Inngest suporta uma funcionalidade chamada step.waitForEvent. Em termos simples, pausa a sequência e aguarda que uma coisa específica aconteça antes de continuar. Se essa coisa não acontecer dentro de um limite de tempo, a sequência toma um caminho diferente.

Aqui está como isso se parece na prática.

Um utilizador regista-se. A sequência de boas-vindas começa. O Email 1 é enviado imediatamente. Depois a função chama step.waitForEvent e aguarda até 48 horas por um evento user.activated (significando que o utilizador completou a ação central do produto).

Se o evento chegar, a sequência ignora o nudge de ativação e salta para a educação de funcionalidades. O utilizador já encontrou o valor. Enviá-lo seria ruído.

Se o evento não chegar em 48 horas, o nudge de ativação dispara. Um email focado na ação específica que o utilizador ainda não tomou.

Essa ramificação acontece dentro de cada sequência. O incentivo ao upgrade verifica se o utilizador fez upgrade entre emails. A sequência de prevenção de churn verifica se o utilizador voltou a iniciar sessão. A sequência win-back verifica se o utilizador voltou a subscrever.

Entre cada chamada step.sleep() (a pausa entre emails), a função cria uma nova ligação à base de dados e verifica o estado atual do utilizador. Se o utilizador já converteu, a sequência para. Ninguém recebe um email de upgrade no dia a seguir ao upgrade.

É assim que os emails baseados em gatilhos parecem em código. Não um construtor de fluxo visual. Uma função que adormece, verifica o estado, ramifica e envia.

A ligação dos gatilhos

As sequências não começam por conta própria. Algo na aplicação tem de disparar o evento.

O sistema encontra estas localizações na tua base de código e liga as chamadas inngest.send(). O registo já tem um callback de auth. O Stripe já tem uma rota de webhook. A verificação de limite já devolve uma resposta quando um utilizador atinge o seu limite. Cada localização recebe uma linha que dispara um evento com o ID do utilizador, email e dados relevantes.

A prevenção de churn é diferente. Corre num cron job diário, não num evento. Todas as manhãs, a função Inngest consulta a base de dados para utilizadores que não estiveram ativos há 7+ dias e envia eventos individuais para cada um. A sequência por utilizador trata do resto.

O que os dados dizem

Os números que moldam este sistema vêm de como o email realmente funciona, não da teoria.

Uma sequência de onboarding de 7 emails (testada num produto SaaS real) moveu a conversão de trial para pago de 12% para 22% e cortou o churn mensal de 8% para 4,8%. Essas são as duas métricas que se compõem. Um aumento de 10 pontos de conversão mais uma redução de 3 pontos de churn muda a matemática em cada euro de marketing que gastas.

O texto simples vence nas taxas de clique porque parece uma mensagem de uma pessoa, não uma promoção. O sistema renderiza tanto uma versão HTML como uma versão de texto simples de cada email via a função render() do React Email. Os destinatários cujos clientes de email preferem texto simples recebem automaticamente a versão simples.

As linhas de assunto curtas funcionam porque as inboxes móveis truncam. Uma linha de assunto de 2-4 palavras é totalmente visível em todos os dispositivos. O sistema mantém cada assunto abaixo de 50 caracteres.

Os gatilhos comportamentais superam os temporizadores fixos porque a relevância importa mais do que o timing. Enviar o email certo depois da ação certa supera enviar qualquer email no dia 3 independentemente do que aconteceu.

Controlo de qualidade

Depois de todos os seis agentes terminarem, o sistema corre o verificador de tipos do TypeScript em todo o projeto:

cd webapp && npx tsc --noEmit

Zero erros de tipos. Cada template tem props com tipos. Cada função Inngest tem payloads de eventos com tipos. Cada chamada inngest.send() corresponde ao formato de evento esperado.

Depois fornece instruções de teste local:

# Terminal 1: inicia o servidor de desenvolvimento
npm run dev

# Terminal 2: inicia o servidor de desenvolvimento do Inngest
npm run dev:inngest

# Abre http://localhost:8288
# Envia um evento de teste: app/user.signed-up
# Observa a sequência de boas-vindas executar passo a passo

O servidor de desenvolvimento do Inngest mostra cada execução de função em tempo real. Podes ver cada passo correr, cada contagem decrescente de espera, cada email que seria enviado. Nada vai para inboxes reais em desenvolvimento local.

Regras para construíres isto tu próprio

O padrão funciona com qualquer fornecedor de email, qualquer motor de background job, qualquer framework. Aqui está o que o faz funcionar.

Lê o teu produto antes de desenhar emails. O erro mais comum é escrever emails que soam genéricos porque quem os escreveu não entendeu o produto profundamente. Alimenta o sistema com a documentação do teu produto, jornadas de utilizadores e voz da marca antes de tocar num template.

Desenha todas as sequências antes de construir qualquer uma delas. Apresenta o plano completo. Obtém aprovação. Depois constrói. Mudar uma linha de assunto num plano é gratuito. Mudá-la num template construído significa re-renderizar, re-testar e re-implementar.

Verifica o estado do utilizador entre cada email. Nunca assumes que o utilizador está ainda no mesmo estado em que estava quando a sequência começou. Um step.sleep("3d") (aguardar 3 dias) significa três dias de potenciais mudanças. Consulta a base de dados antes de enviar.

Uma ação por email. Não dois botões. Não três links. Um próximo passo claro. Os emails com uma única call to action têm taxas de clique mais altas porque não há decisão a tomar.

Constrói texto simples junto com HTML. Não trates o texto simples como um pensamento posterior. Renderiza ambas as versões a partir do mesmo template. Os emails em texto simples têm 42% mais cliques em testes diretos.

Liga os gatilhos a eventos existentes, não a novos. O registo já acontece. O cancelamento já acontece. Os limites atingidos já acontecem. O sistema de email liga-se a eventos que a tua aplicação já dispara. Isso é zero nova infraestrutura.

Para além do email

O padrão de agentes paralelos (um agente base constrói infraestrutura partilhada, depois agentes especializados constroem em cima ao mesmo tempo) funciona para mais do que email.

Sistemas de notificação. Mesma estrutura: desenha todos os tipos de notificação, constrói templates, liga gatilhos. Notificações push, alertas in-app e SMS seguem todos as mesmas fases do ciclo de vida.

Fluxos de onboarding. Um agente lê o contexto do produto e desenha o fluxo. Agentes separados constroem cada passo (modal de boas-vindas, tour de funcionalidades, checklist, estados vazios). A ramificação comportamental decide quais os passos a mostrar com base no que o utilizador já fez.

Documentação. Um agente constrói a estrutura e os componentes partilhados. Agentes especializados escrevem secções individuais em paralelo. Mesma forma. Mesmo padrão de coordenação.

A mesma ideia central em todos os casos. Lê o contexto do produto primeiro. Desenha antes de construir. Constrói em paralelo com infraestrutura partilhada. Verifica o estado antes de agir. Verifica os tipos no final.