Trasforma le email in fatturato con Brew.
Per gli agenti non esiste un’inbox a parte: stesse regole del CAN-SPAM, stesse soglie di Gmail, stessa separazione tra marketing e transazionali nell’invio.
Un agente può avviare una campagna attraverso la stessa infrastruttura di invio che userebbe una persona. Gmail continua a vedere il mittente, il dominio e il messaggio.
I provider di posta valutano domini, IP e tassi di segnalazione di spam. Non valutano se a fare clic su Invia sia stata una persona. Se l’agente fa passare un contenuto promozionale dall’IP transazionale, ti ritrovi con lo stesso problema che avresti creato a mano, solo più in fretta.
Questo articolo affianca la guida alla deliverability, non la sostituisce. Quella guida tratta reputazione, autenticazione e pulizia della lista. Questo si concentra sugli errori che emergono quando a premere “invia” è un software.
La normativa CAN-SPAM si applica ai messaggi commerciali. Il criterio dello scopo principale guarda all’oggetto e al corpo del messaggio, non a chi li ha scritti.
Se un messaggio mescola una fattura e un’offerta, valutane lo scopo principale. Contano l’oggetto, la posizione delle informazioni sull’account e il rilievo dato alla promozione. Un breve footer promozionale non rende automaticamente commerciale un estratto conto. La guida della FTC riporta alcuni esempi. I messaggi commerciali devono avere header e oggetti veritieri, un indirizzo postale e un opt-out funzionante.
Vale anche il contrario. Un’email di reimpostazione della password attivata dall’agente in seguito a un vero evento di sicurezza resta transazionale, purché il contenuto non si allontani da quell’evento.
I requisiti di Gmail per i mittenti prevedono regole per tutti i mittenti e regole più rigide per i mittenti di grandi volumi, quelli che arrivano a circa 5.000 messaggi al giorno verso account Gmail personali. Tra questi requisiti più rigidi ci sono:
p=none o più rigida.List-Unsubscribe e List-Unsubscribe-Post.Le email transazionali sono esenti dalla regola della disiscrizione con un clic. Non sono esenti dall’autenticazione, né dalle segnalazioni di spam se nel modello infili una promozione.
Yahoo chiede ai mittenti di grandi volumi di tenere marketing e transazionali su IP diversi e, preferibilmente, su domini diversi. Verifica quale identità di invio userà l’agente, invece di affidarti a un’impostazione predefinita poco chiara.
Dai all’agente un’identità di invio promozionale per campagne e automazioni: il dominio di cui fai il warm-up, l’IP su cui ti aspetti le segnalazioni di spam, gli header di disiscrizione che hai testato.
Tieni le email transazionali su un’identità separata. In Brew quell’identità è un dominio con finalità di invio transazionale, e l’email vera e propria è un’automazione pubblicata con un trigger. L’agente può comporre il modello. Il percorso di invio per ogni evento, però, deve restare POST /v1/automations/triggers/{triggerEventId}/fire con un payload JSON, non “invia questa bozza alla lista”.
Non lasciare che l’agente scelga l’indirizzo del mittente tra un mucchio di domini verificati “per vedere quale arriva”. È il modo migliore per costruire due reputazioni contemporaneamente senza capirne nessuna.
Il rischio non è un refuso. È un paragrafo scorrevole che cita un numero che non hai mai pubblicato, o un oggetto che sembra una ricevuta.
Prima di lasciare che un agente invii senza una coda di revisione:
Cory Nelson di Harmonya ha raccontato a Noah Adelstein di aver fatto questa revisione della prima campagna prima di fidarsi del ciclo. È l’ordine giusto.
Autentica il dominio, scegli l’identità di invio corretta e confronta la prima campagna con il brief approvato. Controlla anche i permessi e le impostazioni di conferma dell’assistente. Non tutti i client MCP chiedono l’approvazione allo stesso modo.
Il brief che evita i numeri inventati è spiegato in come scrivere il brief per un agente email. La revisione della prima campagna di Harmonya è raccontata in come Harmonya ha trasformato una newsletter in un programma lifecycle.
