5mila email da case Salesforce a settimana, in modo affidabile
Come abbiamo progettato il percorso da un case di assistenza Salesforce alla giusta email transazionale HubSpot — e ritorno, così che ogni invio lasci una traccia di consegna sul case da cui è partito.
L’azienda lavora nelle energie rinnovabili: monitora e mantiene impianti installati presso le proprietà dei clienti finali, per conto delle aziende che detengono i contratti di servizio.
Circa 5mila case Service Cloud a settimana, molti dei quali aperti in automatico — la piattaforma di monitoraggio si accorge che un impianto ha smesso di trasmettere, e il case esiste prima che il cliente sappia che c’è qualcosa che non va.
Per ognuno di quei case deve partire un messaggio.
La domanda era come inviarne così tanti in modo affidabile, con ogni messaggio guidato dai parametri che il case già porta con sé, tenendo nel frattempo i costi di licenza sotto controllo.
Il lavoro vero si è rivelato essere due cose:
Step 1: Scenari diversi, e tutti i se
Impianto fermo, manutenzione programmata, richiesta di accesso alla proprietà, preavviso: ogni tipo di case vuole un messaggio diverso, con contenuti diversi, in un momento diverso della vita del case.
Il mestiere non è inviare. È risolvere quale template si applica, riempirlo con i valori giusti presi dal case e farlo partire nel momento giusto.
A 5mila case a settimana, sbagliare quella scelta anche su una piccola quota significa centinaia di clienti che ricevono il messaggio sbagliato.
Così il progetto mette la decisione in un posto solo. Un evento sul case fa scattare un’azione nativa di Salesforce. Un piccolo strato su Cloudflare Workers la raccoglie, risolve quale template e quali variabili si applicano e invia tramite HubSpot — dove i template li costruiscono le stesse persone che già costruiscono le email verso i clienti, nello strumento che già usano.
Tre modi in cui parte un invio: immediato, per gli eventi che scattano da sé; manuale, nell’istante in cui qualcuno cambia uno stato nell’interfaccia Salesforce; e schedulato, a intervallo fisso — che esiste perché quando un singolo guasto a monte apre decine di case insieme, inviare per case si trasforma in una valanga di messaggi quasi identici. L’intervallo li ricompone in uno.
Step 2: Tracciabilità e letture verificate
Oggi un indirizzo sbagliato fallisce in silenzio. Nessuno sa se un cliente abbia ricevuto una comunicazione critica — niente aperture, niente clic, nessun modo di capire se un messaggio è finito nello spam.
In questo modello di business la cosa pesa due volte.
Contrattualmente, perché le aziende che pagano il servizio pretendono visibilità su come vengono contattati i clienti finali, visibile sul record del case. Registrare la deliverability qui non è un vezzo di reportistica; soddisfa un obbligo che esiste già.
E come tutela, perché l’azienda manda preavvisi quando certe condizioni ridurranno il rendimento dell’impianto. Se in seguito un cliente contesta quel rendimento, la difesa è la prova che il preavviso è stato inviato e aperto — non la convinzione che sia partito qualcosa.
Così il progetto chiude il cerchio. Aperture, clic e bounce tornano indietro a intervalli regolari e vengono scritti in Salesforce, agganciati al case che li ha originati — nello stesso storico attività in cui finisce tutto ciò che un operatore scrive a mano.
Nessun endpoint pubblico è esposto: l’innesco usa le azioni native di Salesforce invece di tirare su un URL affacciato su internet. E i dati dei clienti non escono mai da Salesforce — lo strato su Cloudflare Workers tiene solo i metadati del case, quanto basta a ricollegare un invio al suo case quando tornano le metriche. Nessun corpo del messaggio, nessuna anagrafica cliente.
Una licenza che faceva più del necessario
La risposta del fornitore era una licenza completa per circa un decimo delle sue funzioni.
Una deliverability che nessuno vedeva
Un indirizzo sbagliato fallisce in silenzio, e c’è un obbligo contrattuale che dipende dal fatto che non succeda.
Dati dei clienti che restano nel CRM
Il middleware tiene solo i metadati del case — nessun corpo del messaggio, nessuna anagrafica cliente.
Ogni email inviata, sul case da cui è partita.
Ogni tipo di case riceve il messaggio scritto per lui, invece di un unico avviso generico tirato su tutte le situazioni.
Ogni case porta una traccia di consegna, così “il cliente l’ha ricevuto?” smette di essere una domanda a cui in azienda non sa rispondere nessuno.
L’obbligo contrattuale verso le aziende che pagano il servizio è soddisfatto dal record del case stesso, invece che da un report separato che qualcuno mette insieme.
I preavvisi diventano difendibili. Una contestazione sul rendimento trova la prova che l’avviso è stato inviato e aperto.
Un singolo guasto a monte smette di produrre una valanga di messaggi quasi identici agli stessi clienti.
E chi scrive le email dell’azienda verso i clienti scrive anche queste, in HubSpot, dove già costruisce le campagne — senza un ticket allo sviluppo per cambiare una frase.
Problemi di dati di questa forma?
Se qualcosa qui somiglia alla tua situazione, dicci quale parte. Risposta garantita entro 2 ore lavorative (CET).
Arrigo Lupori
Fondatore e Amministratore