Agenzie
Un funnel, venti clienti, venti reputazioni tenute separate
Un'agenzia di tre persone che gestisce il marketing per venti attività locali ha lo stesso problema venti volte e la stessa soluzione venti volte — solo che la lista, l'identità di invio, il dominio e il registro dei consensi di ciascun cliente devono restare interamente suoi. Il lavoro interessante sta in quel "solo che".
Un progetto per cliente, e il confine è compito del database
Tutto ciò che è qui ha come ambito un tenant e un progetto insieme — contatti, funnel, creatività, campagne, identità di invio, report. Questo ambito è applicato dalla sicurezza a livello di riga nel database, non da una clausola che qualcuno deve ricordarsi di aggiungere a una query. Un progetto dimenticato non vede nulla, invece delle righe del primo progetto.
Il che significa che la lista di un cliente non può finire per errore nella campagna di un altro, e che un report riguarda un cliente perché strutturalmente non può riguardarne due.
Ogni cliente invia come se stesso
Un'identità di invio appartiene a un progetto: il loro dominio, le loro chiavi DKIM, la loro casella o il loro account provider, il loro limite di frequenza. La campagna sfortunata di un cliente non può danneggiare la deliverability di un altro, perché non hanno mai condiviso nulla da danneggiare.
Questo chiude anche in anticipo una conversazione scomoda. Il cliente possiede il proprio invio, la propria lista e il proprio registro dei consensi. Quando se ne va — e qualcuno se ne andrà — se ne va con tutto, e tu non hai costruito una situazione di ostaggio da dover spiegare.
- 1ContattiPer progetto. Applicato nel database, non da una query che devi ricordarti.
- 2InvioIl loro dominio, il loro DKIM, la loro casella o provider, il loro limite di frequenza.
- 3ConsensoIl loro registro. Li segue, prove incluse, se se ne vanno.
- 4ReportPer progetto per costruzione. Non c'è modo di aggregare due clienti per errore.
- iCiò che conserviLe definizioni dei funnel e il tuo modo di lavorare. Questo è il tuo prodotto, ed è la parte che vale la pena riutilizzare.
Nessuna reputazione condivisaNessuna lista condivisa
Riutilizzo senza copia-incolla
Costruisci il funnel una volta. Distribuiscilo quante volte sono i tuoi clienti.
Un funnel è un grafo, e un grafo è JSON con uno schema pubblicato. Il che significa che ciò che riutilizzi è un documento, non uno screenshot di una schermata da ricostruire a mano in ogni account.
I funnel della tua casa
Benvenuto, carrello abbandonato, assente, intervallo, recupero. Scritti una volta da chi li sa scrivere meglio, conservati nel tuo repository, e creati in un progetto cliente con una chiamata API.
Verificati allo stesso modo ovunque
Il validatore gira sul tuo funnel in ogni progetto in cui arriva. Un grafo che farebbe un loop senza un'attesa, o invierebbe senza un oggetto, viene rifiutato lì proprio come lo sarebbe qui.
Simulato prima di partire
Fai una prova con un contatto reale della lista di quel cliente attraverso il funnel e leggi cosa gli invierebbe. Fallo una volta per ogni deployment e la conversazione "è partito sbagliato" smette di succedere.
Migliorato in un solo posto
Quando impari qualcosa — il secondo promemoria funziona meglio alle dieci del mattino — cambi la tua definizione e la fai avanzare. I clienti che stanno già eseguendo la vecchia versione finiscono sulla vecchia versione; nessuno in corsa viene disturbato.
Anche i creativi
Un creativo è un documento con variabili di merge. La stessa e-mail di benvenuto, renderizzata con il brand, i colori e il logo di ogni cliente — recuperati dal loro sito web alla prima esecuzione.
Oppure lascia fare a un agente
Punta un assistente al server MCP, con ambito limitato a un progetto, e fagli redigere e verificare il funnel per quel cliente. Tutto ciò che arriva a una persona reale richiede comunque una conferma esplicita e resta dentro la quota.
Undici clienti, undici mittenti, un solo posto dove guardare.
Il problema del report mensile
La maggior parte del dolore di reporting di un'agenzia non è produrre numeri. È produrre numeri che sopravvivono alla domanda di follow-up del cliente, e produrli senza tre ore di screenshot il primo del mese.
Due cose aiutano qui. I report sono route API, quindi il pacchetto mensile può essere assemblato da uno script ed esportato come PDF invece che da una persona con un foglio di calcolo. E i numeri sono onesti sui bot: grezzi e filtrati sono entrambi disponibili, etichettati, così quando un cliente chiede perché il tasso di apertura è calato dopo il loro trasferimento, lo spieghi in una frase invece di difenderlo in quattro.
Le stesse tessere arrivano in dash-b — performance delle campagne, abbandono del funnel, crescita della lista, deliverability per dominio — così un cliente che vuole una bacheca live può averne una, sul proprio account, con le proprie credenziali e senza nessuna chiave tua nella pagina.
- 1Per ogni progettoUn token, un ambito di progetto, lo stesso script.
- 2PullPerformance delle campagne, abbandono del funnel, crescita della lista, deliverability per dominio.
- 3RenderizzaIl loro documento creativo come pagina di report, poi in PDF.
- 4InviaOppure inseriscilo nella loro bacheca. Quella che il cliente legge davvero.
- iCosa è cambiatoTre ore di screenshot sono diventate un job pianificato, perché i report sono stati route fin dall'inizio.
Grezzi e filtrati, entrambi etichettati
La conversazione sul consenso, fatta per tempo
Ogni agenzia ha incontrato il cliente che arriva con un foglio di calcolo di quattromila indirizzi e una risposta vaga su da dove vengano. Qui non è una discussione che devi vincere; è un campo.
L'importo arriva come interesse legittimo al massimo, mai come consenso, e la miscela di basi giuridiche viene mostrata prima che parta qualsiasi campagna. Se una lista non può ricevere invii, lo dice al momento dell'import invece che al momento del reclamo. Questo trasforma un giudizio scomodo in una lettura condivisa della stessa schermata — che è una posizione molto migliore per te quando il cliente insiste.
Vale la pena dirlo ad alta voce al cliente: la reputazione messa a rischio da una lista cattiva è la sua, sul suo dominio, perché ogni progetto invia come se stesso. È un argomento più forte di qualsiasi regolamento, ed è quello che di solito fa presa.