# Sequência de e-mails para converter testes grátis de SaaS

URL canônica: https://brew.new/pt-br/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events
Por Thomas Park
Publicado em 2026-09-26
Atualizado em 2026-09-29

Um e-mail de conversão do período de teste deve responder ao que o usuário fez. Quem ainda não criou um projeto precisa de ajuda com a configuração. Quem usa o produto todo dia precisa de uma explicação clara do plano pago. Mandar a mesma contagem regressiva para as duas pessoas ignora essa diferença.

Este guia separa a estrutura da sequência da lógica da aplicação que decide quem deve receber cada e-mail.

## Escolha um evento de ativação

Escolha uma ação que mostre que o usuário chegou ao primeiro resultado útil do produto. Ela precisa ser específica o bastante para o seu back-end registrar: um projeto criado, uma importação concluída ou um colega de equipe convidado. Uma visualização de página raramente basta sozinha.

Registre o horário do cadastro, o fim do período de teste, a ativação e o status de pagamento no sistema que é dono desses dados. Trate os campos de contato da plataforma de e-mail como dados sincronizados, não como prova de que um fluxo iniciado antes está lendo o estado atualizado.

## Dê um único objetivo a cada mensagem

| Mensagem | Quando é útil | Elegibilidade verificada na hora do envio |
| --- | --- | --- |
| Boas-vindas | Depois do cadastro ou da verificação | A conta existe e pode receber esta mensagem |
| Ajuda com a configuração | Cerca de dois dias depois, ajustado ao seu produto | Não ativou |
| Próxima ação útil | Depois da ativação | Ativou e não concluiu essa ação |
| Fim do período de teste | Antes do prazo real do período de teste | O período de teste continua ativo e a conta não é paga |
| Último acompanhamento | Depois do fim do período de teste, se fizer sentido | Continua sem pagar, elegível e com permissão para receber e-mails de marketing |

Esses momentos são pontos de partida para testar, não intervalos com o melhor desempenho medido. Informe o prazo real do período de teste e o que acontece depois dele. Não invente escassez nem dê a entender que vai haver uma cobrança quando não há nenhuma forma de pagamento cadastrada.

## Escolha a fonte das verificações de elegibilidade

Em um fluxo do Brew disparado por evento, `payload.activated` lê o evento original, enquanto `contact.activated` lê o valor atual do campo do contato do destinatário no Brew no momento em que um nó Filtro ou Divisão por condição é executado. Para pular os lembretes de configuração depois da ativação, declare esse campo booleano, mantenha-o sincronizado a partir do seu produto e verifique `contact.activated equals false` depois de cada etapa Aguardar relevante. Um valor ausente não equivale a false; teste esse caso separadamente.

Essas leituras usam o contato armazenado no Brew, não o banco de dados da sua aplicação nem uma consulta em tempo real ao Stripe. Receber um evento de ativação ou de pagamento não cancela automaticamente uma execução anterior. O grafo precisa de uma condição antes de cada envio que depende do estado.

Para dados que ficam fora do Brew, faça a sua aplicação agendar uma tarefa. Quando chegar a hora, leia a conta ou a fatura atual e dispare um evento personalizado separado no Brew só se o destinatário ainda for elegível. Inclua nesse novo evento os dados atuais de que a personalização precisa.

Por exemplo, um lembrete agendado pela aplicação funciona como no roteiro abaixo: depois que o cadastro é efetivado, a aplicação dispara o evento de boas-vindas; quando a tarefa de lembrete vence, ela lê a conta atual e termina sem disparar nenhum evento de e-mail se a pessoa já ativou ou pagou, ou dispara o evento de lembrete de configuração com os dados atuais se ela ainda for elegível.

```text
Signup committed → fire welcome event
Reminder job becomes due → read current account
  Already activated or paid → finish without firing an email event
  Still eligible → fire setup-reminder event with current data
```

Use o ID real do gatilho que o Brew retornou e o esquema declarado do gatilho. Siga o [guia de configuração de automações](https://docs.brew.new/create-emails/build-an-automation) e a documentação sobre [contratos de payload tipados](https://docs.brew.new/api-reference/guides/typed-payload-contracts). Use o mecanismo de idempotência documentado nas novas tentativas de disparo de eventos.

## Use o Stripe para os dados que ele controla

Se o Stripe gerencia o período de teste, os eventos de assinatura dele dão o contexto de cobrança. A [integração com o Stripe](/pt-br/browse/integrations/stripe) oferece gatilhos para os eventos compatíveis, entre eles o `customer.subscription.trial_will_end`. A ativação no produto continua sendo responsabilidade da sua aplicação, a menos que você envie essa informação separadamente.

Para um lembrete posterior relacionado a pagamento, confira o registro atual no Stripe. Atualizar o cartão com sucesso não prova que uma fatura foi paga. Coordene com os e-mails que o próprio Stripe envia, para que o cliente receba um único aviso para cada finalidade.

## Escreva o e-mail depois de definir a regra de elegibilidade

Comece pela situação real do destinatário. Explique uma ação útil e coloque um link direto para ela. Um e-mail de configuração pode oferecer um exemplo curto e um endereço para respostas. Um e-mail sobre o plano pago deve descrever o limite ou o recurso relevante e o preço real, com um link para os preços atuais.

Mantenha o consentimento de marketing, o comportamento de descadastro e a finalidade do domínio alinhados com a mensagem. Um cadastro no período de teste não justifica e-mails promocionais sem relação com ele.

## Comprove que as saídas funcionam

Teste o que acontece quando um contato ativa ou paga antes de cada verificação de elegibilidade. Com condições de contato, atualize os campos relevantes no Brew durante a espera e confirme que o lembrete é ignorado. Com verificações agendadas pela aplicação, confirme que as contas não elegíveis não geram um evento de lembrete. Teste também novas tentativas, prorrogações do período de teste, exclusão de conta, descadastros e campos ausentes. Confira tanto os logs da aplicação quanto o histórico de execuções do Brew.

Avalie a ativação e a conversão em assinatura paga com os dados do seu produto, e as falhas de entrega com a plataforma de e-mail. As taxas de abertura sozinhas não mostram se a sequência ajudou quem está no período de teste. Veja exemplos no guia de [sequência de boas-vindas](/pt-br/blog/welcome-email-sequence) e a divisão da implementação no [guia MCP vs API REST](/pt-br/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use).