Agentes não ganham uma caixa de entrada à parte. Valem a mesma lei CAN-SPAM, os mesmos limites do Gmail e a separação entre marketing e transacional no envio.
Um agente pode iniciar uma campanha pela mesma infraestrutura de envio que uma pessoa usaria. O Gmail continua vendo o remetente, o domínio e a mensagem.
Os provedores de e-mail avaliam domínios, IPs e taxas de reclamação. Eles não avaliam se foi uma pessoa que clicou em Enviar. Se o agente mandar um conteúdo promocional pelo IP transacional, você herda o mesmo problema que teria criado à mão, só que mais cedo.
Este post complementa o guia de entregabilidade de e-mail, sem substituí-lo. Aquele guia trata de reputação, autenticação e higiene de lista. Este trata dos erros que aparecem quando quem aperta o botão de enviar é um software.
A lei CAN-SPAM se aplica a mensagens comerciais. O critério do objetivo principal olha para o assunto e para o corpo da mensagem, não para quem os digitou.
Numa mensagem que mistura uma fatura e uma oferta, avalie o objetivo principal. O assunto, a posição das informações da conta e o destaque dado à promoção fazem diferença. Um breve rodapé promocional não torna comercial, automaticamente, um extrato de conta. O guia da FTC traz exemplos. As mensagens comerciais precisam de cabeçalhos e assuntos verdadeiros, de um endereço físico e de um opt-out que funcione.
O contrário também vale. Uma redefinição de senha que o agente disparou a partir de um evento de segurança real continua sendo transacional, desde que o corpo do e-mail se limite a esse evento.
Os requisitos do Gmail para remetentes incluem regras para todos os remetentes e regras mais rígidas para os remetentes em massa, que chegam a cerca de 5.000 mensagens por dia para contas pessoais do Gmail. Entre esses requisitos mais rígidos estão:
p=none ou mais rígida.List-Unsubscribe e List-Unsubscribe-Post.Os e-mails transacionais estão dispensados da regra do descadastro com um clique. Não estão dispensados da autenticação, nem das reclamações de spam, se você rechear o modelo com uma promoção.
O Yahoo pede que os remetentes de alto volume coloquem o marketing e o transacional em IPs diferentes e, de preferência, em domínios diferentes. Confira qual identidade de envio o agente vai usar, em vez de deixar isso por conta de um padrão vago.
Dê ao agente uma identidade de envio promocional para campanhas e automações: o domínio que você aquece, o IP em que você já espera reclamações, os cabeçalhos de descadastro que você testou.
Mantenha os e-mails transacionais em uma identidade separada. No Brew, essa identidade é um domínio com finalidade de envio transacional, e o e-mail em si é uma automação publicada com um gatilho. O agente pode criar o modelo. Mesmo assim, o caminho de envio de cada evento deve continuar sendo POST /v1/automations/triggers/{triggerEventId}/fire com um payload JSON, e não “envie este rascunho para a lista”.
Não deixe o agente escolher o endereço do remetente em uma pilha de domínios verificados “para ver qual chega”. É assim que você treina duas reputações ao mesmo tempo e não entende nenhuma das duas.
O risco não é um erro de digitação. É um parágrafo fluente que cita um número que você nunca publicou, ou um assunto que parece um recibo.
Antes de deixar um agente enviar sem uma fila de revisão:
Cory Nelson, da Harmonya, contou ao Noah Adelstein que fez essa leitura da primeira campanha antes de confiar no ciclo. É a ordem certa.
Autentique o domínio, escolha a identidade de envio certa e revise a primeira campanha comparando-a com o briefing aprovado. Confira também as permissões e as configurações de confirmação do assistente. Nem todos os clientes MCP pedem aprovação do mesmo jeito.
O briefing que impede números inventados está em como fazer o briefing de um agente de e-mail. A leitura da primeira campanha da Harmonya está em como a Harmonya fez da newsletter mensal um programa de ciclo de vida.
