Reinviare le conferme d'ordine: una piccola funzione che i clienti apprezzano davvero

Ecco una richiesta che ogni casella di assistenza PrestaShop vede arrivare di continuo: "Non ho ricevuto la conferma dell'ordine: potete reinviarla?" Sembra una cosa banale, ed è proprio per questo che molti negozi la gestiscono male. Il cliente ha effettuato l'ordine, l'e-mail è partita, poi è sparita in una cartella spam, nella scheda Promozioni o dopo una cancellazione fatta per errore. A quel punto non ha più il riferimento dell'ordine, nessuna prova di pagamento, nessun link di tracciamento, e un dubbio fastidioso: l'ordine sarà davvero andato a buon fine? La soluzione è piccola, è già in gran parte dentro PrestaShop e toglie silenziosamente di mezzo una delle attività più ripetitive del tuo team. Questa guida parla proprio di quella funzione: reinviare l'e-mail di conferma dell'ordine, dal back office oggi e in autonomia dal cliente domani.

Ultimo aggiornamento: giugno 2026.

Questo è solo un tassello di un flusso di gestione ordini più ampio. Se vuoi una panoramica completa su come gestire gli ordini in modo efficiente — stati, azioni massive, routine quotidiane — parti dai flussi di gestione ordini che ti fanno risparmiare ore. Qui restiamo su un obiettivo preciso: rimettere una conferma d'ordine nelle mani del cliente.

Perché le e-mail di conferma spariscono

I titolari di negozi tendono a dare per scontato che "e-mail inviata" significhi "e-mail letta". Non è così. Le e-mail transazionali — la conferma dell'ordine, l'avviso di spedizione, la fattura — devono superare gli stessi filtri antispam e la stessa classificazione in schede della posta in arrivo di qualsiasi altro messaggio. Una quota significativa di messaggi transazionali legittimi non arriva mai nella casella principale; la percentuale esatta cambia moltissimo in base alla configurazione di invio, quindi meglio non fissarsi su un numero. Quello che puoi controllare è se un'e-mail persa diventa una richiesta di assistenza o un clic in autonomia.

La causa più profonda, in molti negozi PrestaShop, è l'infrastruttura di invio. Se il tuo negozio invia e-mail tramite PHP mail() (Parametri avanzati → E-mail, impostazione predefinita in molte installazioni) invece che tramite SMTP autenticato, le conferme hanno molte più probabilità di essere contrassegnate o scartate silenziosamente: nessun allineamento SPF/DKIM, un IP server senza reputazione di invio, niente che il server ricevente possa considerare affidabile. Prima di creare qualsiasi funzione di reinvio, vale la pena correggere la causa principale: passa a SMTP, invia l'e-mail di prova da quella stessa schermata e verifica che SPF e DKIM siano pubblicati per il tuo dominio. Un pulsante di reinvio sopra un mittente configurato male non fa che reinviare messaggi che verranno filtrati di nuovo.

Reinviare una conferma dal back office: cosa offre già PrestaShop

La maggior parte dei commercianti non se ne accorge, quindi vale la pena essere precisi: PrestaShop può reinviare un'e-mail di stato dalla pagina dell'ordine, senza moduli aggiuntivi, ma con un'avvertenza importante. Apri Ordini → Ordini, entra nell'ordine e guarda il pannello Stato nella parte alta. Il menu a tendina lì presente non si limita a etichettare l'ordine: riapplicare o cambiare lo stato verso uno stato a cui è associato un template e-mail attiva di nuovo quel template. Quello che non può fare in modo pulito è reinviare la conferma d'ordine originale: quella conferma viene generata durante la validazione dell'ordine, non da una normale e-mail di stato ordine, quindi non esiste una funzione nativa con un clic per "reinviare la conferma" riproducendola senza cambiare lo stato dell'ordine (e senza i relativi effetti collaterali). Per ottenere un reinvio pulito, senza effetti collaterali, della conferma originale serve una logica personalizzata o un modulo.

Il meccanismo è la configurazione degli stati ordine. Ogni stato (puoi consultarli in Parametri negozio → Impostazioni ordine → Stati, memorizzati nella tabella ps_order_state) contiene l'opzione "Invia un'e-mail al cliente quando l'ordine passa a questo stato" e un template collegato. Gli stati "In attesa di pagamento" / "Pagamento accettato" / "Preparazione in corso" corrispondono ciascuno a un template come payment o preparation. La conferma d'ordine originale (order_conf) è diversa: viene inviata durante il processo di validazione dell'ordine/pagamento, non come una normale e-mail di stato ordine che puoi riattivare dal menu a tendina. Quindi, per un'e-mail di stato, la mossa pratica è questa: riportare l'ordine allo stato che il cliente avrebbe dovuto ricevere e PrestaShop reinvia quell'e-mail di stato. Sotto il cofano passa da OrderState e dall'inserimento nella cronologia dell'ordine (OrderHistory::addWithemail()), lo stesso percorso usato dall'e-mail automatica originale: il cliente riceve quindi un messaggio identico e formattato correttamente, non un'approssimazione scritta a mano.

Qui c'è un punto delicato, ed è il motivo per cui esiste uno strumento dedicato. Cambiare lo stato dell'ordine per riattivare un'e-mail scrive anche una nuova riga nella cronologia dell'ordine e può spostare lo stato del flusso operativo dell'ordine. A seconda dello stato, può anche attivare comportamenti legati a fatture o documenti di consegna, eseguire hook e far partire automazioni di moduli collegate a quello stato (mentre i movimenti di giacenza entrano in gioco solo con stati di annullamento/rimborso/riassortimento). Se volevi solo reinviare l'e-mail, hai appena sporcato la cronologia dell'ordine, forse attivato effetti collaterali collegati a quello stato e confuso chi leggerà la cronologia più avanti. Per un caso isolato può andare. Come abitudine quotidiana su decine di ordini, diventa disordinato.

La via più pulita dal back office: un vero "reinvia" che non tocca lo stato

Quello che i team di assistenza vogliono davvero è un pulsante che reinvii la conferma senza cambiare nulla nell'ordine: stesso template, stessi dati, nessuna nuova riga di stato, nessun effetto collaterale. È il vuoto che colma il nostro modulo Resend Order Confirmation: aggiunge un controllo di reinvio con un clic alla pagina di dettaglio dell'ordine nel back office. Che cosa significa, in pratica? Quando un cliente scrive, l'operatore apre l'ordine, fa un clic e la conferma originale parte di nuovo: niente caccia al template giusto, niente e-mail manuale da comporre, nessun cambio di stato che sporca la cronologia dell'ordine. L'operatore impiega quindici secondi invece di cinque minuti e la scheda ordine resta pulita.

È una piccola funzione, ma il calcolo del tempo è concreto. Gestire un reinvio manualmente — trovare l'ordine, verificare l'identità, individuare il template, reinviare o cambiare stato — richiede facilmente da cinque a dieci minuti di tempo qualificato dell'assistenza per ogni richiesta, tra cambi di contesto e ricontrolli. Un negozio che riceve anche solo poche richieste di questo tipo a settimana perde ore ogni mese in un'attività che non richiede giudizio. È tempo che sarebbe meglio dedicare alle richieste che hanno davvero bisogno di una persona: una consegna danneggiata, una contestazione di rimborso, un cambio indirizzo dopo la spedizione.

Reinvio tramite stato o reinvio dedicato: quale usare

Meglio che reinviare: fare in modo che il cliente non debba chiedere

La richiesta di assistenza più veloce è quella che non viene mai aperta. PrestaShop espone già molti dati dell'ordine nell'account cliente: quando un cliente connesso va in Cronologia ordini (il controller history) e clicca su Dettagli (il controller order-detail, servito da order-detail.tpl), può vedere l'ordine completo, le righe prodotto, la cronologia degli stati e l'eventuale fattura. Per la maggior parte delle richieste "dov'è la mia conferma?", la risposta è già in quella pagina: il cliente semplicemente non sapeva dove guardare.

Due mosse chiudono il cerchio:

• Rendere autosufficiente la pagina di dettaglio dell'ordine. Se il contenuto completo della conferma — riferimento ordine, articoli, totali, indirizzo di consegna, metodo di pagamento — è visibile nell'account, l'e-mail diventa una comodità invece dell'unica prova disponibile. Un cliente che può vedere il proprio ordine online raramente ha bisogno che gli venga reinviato via e-mail.
• Aggiungere un link "reinvia conferma" nell'account. Un singolo link nella pagina di dettaglio dell'ordine che reinvia la conferma all'e-mail dell'account trasforma una richiesta di assistenza in un clic autonomo. Non arriva mai nella tua casella. È lo stesso meccanismo di reinvio del pulsante nel back office, semplicemente esposto al cliente connesso per i suoi ordini.

Vale la pena essere onesti su un limite: la gestione autonoma aiuta solo i clienti che hanno usato un account. Un ospite che ha completato l'acquisto senza registrarsi — e ha digitato male l'e-mail — non può accedere per trovare nulla, ed è proprio il caso in cui la tua configurazione SMTP e un reinvio pulito dal back office contano di più. Quindi servono entrambi: autonomia per chi ha un account, reinvio pulito dal back office per tutti gli altri.

La stessa logica vale per ogni e-mail transazionale

Quando tratti "il cliente ha perso l'e-mail" come un problema risolvibile e ripetibile, invece che come una seccatura da gestire una per una, lo stesso schema si estende a tutta la comunicazione legata agli ordini:

• Fatture. La fattura è l'e-mail che i clienti chiedono più spesso di reinviare: per la contabilità, per le note spese, per una richiesta di rimborso. PrestaShop allega la fattura PDF all'ordine dal momento in cui esiste un numero di fattura valido; assicurati che i clienti possano scaricarla dal loro account e, se esporti regolarmente le fatture per la contabilità, consulta gli export CSV per ordini e fatture.
• Notifiche di spedizione. "Dov'è il link di tracciamento?" è lo stesso problema con un altro nome: è un'e-mail di stato (il template shipped) che il cliente ha perso. La logica di reinvio è identica.
• Conferme dopo la modifica di un ordine. Se hai modificato righe ordine, prezzo o indirizzo dopo l'ordine del cliente, la conferma originale ora è sbagliata: reinviare quella vecchia è peggio che inutile. Emetti di nuovo la conferma corretta solo dopo che la modifica è definitiva; il funzionamento della modifica di un ordine esistente è trattato in modifica degli ordini: correggere gli errori dopo l'invio da parte del cliente.

Non gonfiare i numeri: pulisci prima gli ordini di test

Una nota operativa che colpisce spesso i negozi mentre costruiscono o testano funzioni e-mail: è facile bombardarsi da soli di reinvii mentre si rifiniscono i template, ed è altrettanto facile lasciare dietro di sé una pila di ordini fittizi. Se hai fatto test su un negozio live o quasi live, elimina i dati di prova prima che falsino il conteggio degli ordini e attivino e-mail indesiderate: vedi eliminare gli ordini di test prima della messa online.

Domande frequenti

Perché non posso semplicemente reinviare la conferma d'ordine originale dalla pagina dell'ordine in PrestaShop standard? Perché la conferma (il template order_conf) viene generata una sola volta durante la validazione dell'ordine, non come normale e-mail di stato ordine. Il menu a tendina Stato riattiva solo le e-mail associate a uno stato dell'ordine: quindi l'unico modo nativo per "reinviare" è cambiare lo stato, cosa che scrive una nuova riga nella cronologia e può innescare effetti collaterali. Un reinvio pulito, senza effetti collaterali, della conferma originale richiede una logica personalizzata o un modulo.

Reinviare un'e-mail addebita di nuovo il cliente o modifica l'ordine? No. L'invio di un'e-mail non tocca mai pagamento, giacenze o totali: recapita solo di nuovo un messaggio. Il rischio di cui le persone si preoccupano nasce dalla scorciatoia di cambiare lo stato per attivare l'e-mail, non dall'e-mail in sé. Un reinvio dedicato che non cambia lo stato lascia l'ordine completamente intatto.

Le mie conferme continuano a finire nello spam anche dopo il reinvio. Che fare? Un reinvio non risolve un problema del mittente: la seconda copia viene filtrata nello stesso modo della prima. Controlla Parametri avanzati → E-mail: se stai usando PHP mail(), passa a SMTP autenticato, invia l'e-mail di prova da quella schermata e verifica che SPF e DKIM siano pubblicati per il tuo dominio. Sistema prima il mittente, poi reinvia.

Un ospite ha completato l'ordine e ha digitato male l'e-mail: può ricevere la conferma? Non in autonomia, perché non c'è un account a cui accedere. È esattamente il caso in cui un reinvio dal back office è importante: correggi l'e-mail sull'ordine, se la tua versione lo consente, poi reinvia la conferma all'indirizzo corretto.

Il modulo funziona sulla mia versione di PrestaShop? Il controllo di reinvio si aggancia alla pagina di dettaglio dell'ordine e allo stesso percorso e-mail che PrestaShop usa già, quindi funziona sui rami 1.6, 1.7, 8 e 9 che supportiamo: il meccanismo sottostante OrderHistory/mail è rimasto compatibile.

In sintesi

"Reinviatemi la conferma" è una richiesta minuscola che rivela come un negozio tratta i suoi clienti. Gestita male, diventa un'attività manuale da cinque minuti e comunica al cliente che non eri pronto per un problema ovvio. Gestita bene, diventa invisibile: il mittente è configurato in modo che meno e-mail vadano perse, il reinvio dal back office è un clic pulito che non scombina la cronologia dell'ordine e di solito il cliente può aprire da solo l'ordine e reinviarsi la conferma senza scrivere a nessuno. Niente di tutto questo è ingegneria rivoluzionaria: è quel tipo di dettaglio silenzioso e rifinito che fa percepire un negozio come affidabile, e che i clienti ricordano la prossima volta che scelgono dove acquistare.