Monte automações de e-mail úteis, com gatilhos explícitos, verificações de elegibilidade, esperas e testes que acompanham as mudanças no estado do cliente.
Uma automação de e-mail é uma decisão repetível sobre quando enviar uma mensagem. O editor é só uma parte dela. O evento, o estado atual do cliente e as regras de saída importam tanto quanto o texto.
Antes de desenhar uma sequência, anote por que cada mensagem deve existir e o que a tornaria inadequada no momento do envio.
Um cadastro, uma compra concluída, um pagamento com falha ou um marco no produto podem iniciar uma automação. Dê ao evento um significado claro. “Usuário ativo” é ambíguo; “primeiro relatório exportado” é algo que a aplicação consegue registrar e testar.
Inclua só os dados de que a mensagem precisa, com identificadores estáveis e um timestamp quando fizer sentido. Decida qual sistema é o dono de cada valor. A entrega de eventos pode ter novas tentativas, então use o comportamento de idempotência que a sua integração oferece e teste a entrega duplicada.
A integração com o Stripe traz eventos documentados de assinatura e de pagamento. Eventos personalizados da sua aplicação podem cobrir os marcos específicos do seu produto.
Uma espera muda quando a próxima etapa é executada. Ela não atualiza, por si só, as informações que a automação conhece.
Em um fluxo do Brew disparado por evento, os nós Filtro e Divisão por condição distinguem os dados do evento dos dados do contato. Uma condição em activated ou em payload.activated lê o evento original. Um payload de cadastro com activated: false pode estar desatualizado amanhã. Já uma condição em contact.activated lê o valor atual do campo do contato no Brew no momento em que esse nó de condição é executado, inclusive depois de uma etapa Aguardar.
Para um lembrete de configuração, declare um campo de contato booleano activated, mantenha-o sincronizado a partir da sua aplicação e coloque um filtro contact.activated equals false depois da espera. Um valor ausente não equivale a false, então teste os dois casos. Coloque uma condição antes de cada lembrete seguinte que dependa desse estado; uma atualização do contato ou um novo evento não cancela automaticamente uma execução já iniciada.
A leitura do contato não consulta o banco de dados do seu produto nem a sua plataforma de cobrança. Se a elegibilidade depender de uma atividade não sincronizada, de uma fatura específica ou do conteúdo atual do carrinho, agende essa verificação na sua aplicação. Na hora prevista, leia o registro de referência e só dispare um novo evento elegível se o lembrete ainda fizer sentido.
O guia da sequência de conversão de períodos de teste mostra as duas abordagens. A documentação de automações explica os caminhos de campo usados nas condições.
Uma automação de boas-vindas pode entregar o material ou o próximo passo prometido no cadastro. Uma notificação de pagamento pode explicar um evento de cobrança real. Um e-mail de marco no produto pode ajudar alguém a aproveitar o resultado do que acabou de concluir.
Mantenha a primeira versão pequena o bastante para ser inspecionada. Para cada mensagem, registre o público, o gatilho, os campos obrigatórios, a ação pretendida e as condições que devem impedir um envio. Inclua o status de inscrição e o comportamento de supressão nessa revisão.
No Brew, são as automações publicadas que controlam a execução. Criar ou editar um rascunho não é o mesmo que publicá-lo. As configurações da integração e o estado da automação têm funções diferentes; por exemplo, a opção Sincronizar nome completo da integração com o Stripe controla as atualizações de nome, não se as automações disparadas por eventos são executadas.
Teste uma execução normal, campos opcionais ausentes, um evento duplicado, um contato de marketing descadastrado e um cliente cujo estado muda antes da hora de um lembrete. Nas condições de contato, atualize o campo no Brew durante a espera e confirme que a condição seguinte pula o lembrete. Nos lembretes agendados pela aplicação, confirme que a aplicação deixa de disparar um novo evento elegível quando o cliente não se qualifica mais.
Inspecione o e-mail real, além do registro da execução. Confira os links, os campos de mesclagem, o domínio de envio e a versão publicada exata. Uma requisição de gatilho bem-sucedida, sozinha, não prova que a mensagem certa chegou à caixa de entrada certa.
Uma sequência perene pode ficar obsoleta sem ninguém perceber quando as etapas de configuração, os preços ou o acesso ao produto mudam. Dê um responsável a cada sequência e revise-a depois de cada lançamento relevante.
Meça o resultado pretendido e os efeitos indesejados. Se o objetivo é concluir a configuração, acompanhe essa ação junto com as reclamações e os descadastros. Use o guia de métricas para não tratar as aberturas como prova de que a automação ajudou.
