Contenuti
- Il sito può aver fatto tutto correttamente
- Il percorso non finisce con SMTP
- Il problema può iniziare ancora prima
- Anche una mail inviata al destinatario sbagliato è un problema
- E a volte il messaggio non parte proprio
- Il problema può trovarsi anche dopo l’email
- La domanda corretta non è “l’email è stata inviata?”
- Il sito ha fatto il suo lavoro?
- L’invio è soltanto una parte del percorso
Email inviata non significa email consegnataQuando un sito invia un’email, è facile considerare conclusa l’operazione.
Il modulo funziona.
Il messaggio viene generato.
Il server SMTP lo accetta.
Dal punto di vista del sito, tutto sembra essere andato bene.
Ma cosa significa realmente?
Che il messaggio è stato inviato. Non necessariamente che sia stato consegnato.
E tra le due cose c’è una differenza importante.
Il sito può aver fatto tutto correttamente
Immaginiamo un modulo di contatto.
Un visitatore inserisce i propri dati e invia la richiesta.
Il sito elabora il modulo.
Genera il messaggio.
Lo consegna al server SMTP.
Il server SMTP lo prende in carico.
A questo punto il sito può considerare conclusa la propria parte del processo.
Ma il percorso non è ancora necessariamente terminato.
Il messaggio deve ancora attraversare una serie di controlli e sistemi prima di arrivare alla casella del destinatario.
Il percorso non finisce con SMTP
Una semplificazione frequente è immaginare il processo così:
Sito → SMTP → destinatario
Nella realtà possono esserci molti altri passaggi.
Il messaggio può essere sottoposto a filtri antispam.
Il dominio mittente può essere controllato.
Il server destinatario può verificare l’autorizzazione all’invio.
Possono entrare in gioco SPF, DKIM e DMARC.
Il mittente o il server possono trovarsi in una blacklist.
Il messaggio può essere rifiutato.
Oppure può essere accettato e successivamente classificato come posta indesiderata.
Quindi possiamo avere una situazione nella quale:
SMTP OK
↓
mail presa in carico
↓
filtri
↓
controlli del destinatario
↓
SPF / DKIM / DMARC
↓
mail rifiutata, filtrata o non recapitata
Il sito, nel frattempo, può continuare a funzionare perfettamente.
Il problema può iniziare ancora prima
E non è nemmeno necessario arrivare alla consegna per avere un problema.
In una casistica reale, ad esempio, il sito mostrava correttamente un indirizzo email.
Il collegamento era corretto.
Ma su alcune configurazioni il click sul collegamento non produceva alcuna azione.
Il sito funzionava.
L’indirizzo era visibile.
Ma il percorso che avrebbe dovuto permettere all’utente di iniziare il contatto era interrotto.
Questo è un primo elemento importante:
Il fatto che il sito mostri un indirizzo email non significa che il processo di contatto sia operativo.
Anche una mail inviata al destinatario sbagliato è un problema
C’è poi un problema ancora più subdolo.
Un modulo può inviare correttamente le email.
Il server SMTP può accettarle.
Il messaggio può essere consegnato.
Ma il destinatario configurato può essere quello sbagliato.
È accaduto realmente con un modulo che, durante lo sviluppo, era stato configurato con un indirizzo utilizzato per i test.
Il sito è stato pubblicato senza modificare il destinatario.
Per mesi il sistema ha continuato a funzionare tecnicamente.
Le email venivano inviate.
Semplicemente, non arrivavano a chi doveva riceverle.
Dal punto di vista del sito il processo sembrava corretto.
Dal punto di vista dell’organizzazione, invece, le richieste dei clienti stavano andando altrove.
E a volte il messaggio non parte proprio
In un’altra casistica, il sito utilizzava un servizio SMTP esterno.
Le credenziali del servizio sono state modificate per una ragione di sicurezza.
Il cambiamento era corretto.
Ma le nuove credenziali non sono state aggiornate sul sito.
Il modulo continuava a raccogliere le richieste.
Gli utenti continuavano a compilare il form.
Il sito continuava a essere online.
Ma le notifiche email non venivano più inviate correttamente.
Il problema è rimasto nascosto per giorni.
In questo caso una seconda destinazione dei dati ha permesso di recuperare i contatti.
Senza quella ridondanza, il risultato sarebbe potuto essere molto diverso.
Il problema può trovarsi anche dopo l’email
Il percorso critico può essere ancora più lungo.
In una casistica diversa, il lead veniva acquisito e trasferito a un sistema di automazione.
Il sistema riceveva i dati.
Ma un campo del webhook non corrispondeva a quello atteso dal processo successivo.
Il sistema quindi riceveva il lead, ma non completava l’azione prevista.
Anche qui:
il dato arrivava.
Il processo no.
Per undici giorni nessuno si è accorto che qualcosa non funzionava.
Le campagne continuavano a generare contatti e l’azienda continuava a sostenerne il costo.
Ma il risultato commerciale previsto non veniva prodotto.
La domanda corretta non è “l’email è stata inviata?”
Questa domanda può essere utile.
Ma non è sufficiente.
Per un processo critico bisogna chiedersi:
“Il risultato che doveva essere prodotto è stato effettivamente ottenuto?”
Se il sito deve raccogliere una richiesta commerciale, non basta verificare che abbia generato una mail.
Bisogna sapere che la richiesta sia arrivata dove deve arrivare.
Se il sito deve inviare una notifica, non basta verificare che il server SMTP abbia accettato il messaggio.
Bisogna considerare cosa succede dopo.
E se il processo prevede ulteriori passaggi, bisogna osservare anche quelli.
Il sito ha fatto il suo lavoro?
Questa è la domanda che riporta tutto alla Continuità Operativa.
Un sito può:
- generare correttamente l’email;
- consegnarla al server SMTP;
- ricevere una risposta positiva;
- non ricevere alcun errore visibile;
e tuttavia non produrre il risultato che l’organizzazione si aspettava.
Perché il valore non sta nell’invio dell’email.
Il valore sta nel processo che quell’email doveva completare.
Un contatto deve raggiungere il commerciale.
Una richiesta deve arrivare a chi deve gestirla.
Una notifica deve essere ricevuta.
Un lead deve poter proseguire nel percorso previsto.
L’invio è soltanto una parte del percorso
Per questo motivo osservare soltanto il server SMTP o il log dell’invio può creare una falsa sensazione di sicurezza.
Il controllo di un singolo passaggio non garantisce necessariamente il risultato finale.
La Continuità Operativa segue il percorso critico fino alla destinazione del valore.
Perché:
Email inviata non significa email consegnata.
E soprattutto:
Email consegnata non significa necessariamente processo completato.
La domanda finale rimane sempre la stessa:
il sito ha fatto ciò per cui era stato progettato?
