Il cliente vede «reso approvato», il magazzino aspetta il pacco e l’amministrazione legge «da rimborsare». Se il tuo e-commerce usa un solo stato per queste tre cose, basta un rientro parziale per perdere il filo. Una gestione resi ecommerce affidabile separa richiesta del cliente, movimento della merce e movimento del denaro, collegandoli allo stesso numero di pratica.
Prima di comprare un software, prendi tre casi anonimizzati: un articolo restituito su due acquistati, un cambio taglia e un rimborso non riuscito. Per ciascuno scrivi chi decide, quale informazione serve e che cosa deve vedere il cliente. Queste prove distinguono una funzione utile da un altro pannello da aggiornare a mano.
Qui trovi uno schema RMA, un esempio numerico e una checklist da usare con il tuo fornitore. È una guida di progettazione del software, non un modello legale di condizioni di vendita.
Tre stati separati, una sola pratica
RMA significa Return Merchandise Authorization: nel gestionale è il riferimento della pratica di rientro. Non deve trasformarsi in un ostacolo all’esercizio dei diritti del consumatore. Un messaggio valido ricevuto via email va gestito anche se non arriva dal tuo portale.
| Livello | Stati di esempio | Che cosa evita |
|---|---|---|
| Richiesta | Ricevuta, in valutazione, istruzioni inviate, chiusa | Confondere la decisione con il pacco |
| Merce | Attesa, rientrata in parte, in verifica, destinata | Rivendere un articolo non controllato |
| Denaro | Da determinare, autorizzato, inviato, riuscito, anomalia | Comunicare un rimborso mai completato |
Sono stati progettuali, non nomi obbligatori di una piattaforma. Ogni transizione conserva autore o sistema sorgente, data e motivo. Il supporto può inviare istruzioni; il magazzino registra quantità e condizioni; l’amministrazione autorizza l’operazione economica. Le autorizzazioni del software devono riflettere queste differenze.
La documentazione Shopify su resi e cambi distingue creazione, elaborazione e rimborso, anche parziali. Prima di aggiungere un servizio esterno, verifica ciò che la tua piattaforma già copre e ciò che richiede una configurazione o un piano diverso.
Recesso, difetto e cambio commerciale non sono la stessa regola
Non impostare «14 giorni» come filtro universale che rifiuta ogni pratica successiva. Il recesso negli acquisti online dei consumatori prevede normalmente 14 giorni, con eccezioni; un difetto di conformità segue invece la garanzia legale. Una politica volontaria di cambio può concedere condizioni ulteriori. Sono percorsi da distinguere nel software, non categorie intercambiabili. Fonti: MIMIT, diritto di recesso e Your Europe, garanzie per i consumatori.
Per il recesso, il termine di rimborso decorre dalla comunicazione del consumatore, non automaticamente dal controllo di magazzino. Salvo l’offerta del venditore di ritirare i beni, il rimborso può essere trattenuto fino al rientro o alla prova di spedizione, considerando ciò che avviene prima. La policy va verificata prima di tradurla in regole. Il sistema deve conservare queste date, mostrare le scadenze e gestire le eccezioni. Your Europe, vendita a distanza.
Evita blocchi rigidi basati su un motivo obbligatorio o sull’assenza di una foto per ogni richiesta. Chiedi solo le informazioni pertinenti al percorso. Costi di restituzione, trattenute, buoni e condizioni speciali vanno validati rispetto alla vendita concreta: il fatto che un’app permetta una commissione non significa che sia applicabile al tuo caso.
La scheda RMA minima da portare al fornitore
Un allegato perso non si recupera aggiungendo dieci campi obbligatori. Conserva pochi identificatori stabili e rendi esplicite le fonti. La scheda seguente serve a discutere i requisiti, non a raccogliere dati personali su questa pagina.
| Gruppo di dati | Campi essenziali | Fonte da verificare |
|---|---|---|
| Identità della pratica | ID reso, ID ordine, canale, data richiesta | E-commerce o assistenza |
| Righe | ID riga originale, SKU, variante, quantità richiesta e ricevuta | Ordine storico e magazzino |
| Regola applicata | Percorso, versione policy, decisione, responsabile | Condizioni applicabili e operatore |
| Merce | Sede, esito controllo, quantità vendibile/non vendibile | Magazzino |
| Valore | Prezzo pagato, quota sconto, importo autorizzato, valuta | Ordine e pagamento originari |
| Rimborso | ID operazione, importo, stato, anomalie | Provider di pagamento |
| Comunicazioni | Evento comunicato, destinatario, esito invio | Servizio notifiche |
Usa il prezzo dell’ordine, non quello attuale del catalogo. Conserva il legame con la riga acquistata: lo stesso SKU può comparire con sconti o condizioni differenti. Per ordini provenienti da marketplace stabilisci prima chi ha il potere di rimborsare; non duplicare l’azione nel gestionale e nel canale.
Esempio: due articoli, uno sconto, rientri in giorni diversi
Caso ipotetico, costruito per provare il software, non risultato di un cliente. Un ordine contiene due articoli da 50,00 € ciascuno, con sconto complessivo di 10,00 € ripartito in parti uguali. Il valore pagato per ogni riga è 45,00 €. Per isolare il calcolo, nell’esempio non ci sono costi di consegna, cambi, ulteriori trattenute o altri pagamenti.
| Evento | Quantità rientrata cumulata | Rimborso autorizzato cumulato | Rimborso riuscito cumulato |
|---|---|---|---|
| Richiesta per entrambi gli articoli | 0 | 0,00 € | 0,00 € |
| Prima operazione autorizzata per una riga | 1 | 45,00 € | 0,00 € |
| Provider conferma il primo rimborso | 1 | 45,00 € | 45,00 € |
| Seconda operazione autorizzata | 2 | 90,00 € | 45,00 € |
| Provider conferma la seconda | 2 | 90,00 € | 90,00 € |
La sequenza illustra gli stati; non stabilisce quando sia lecito attendere la merce. Le scadenze e le condizioni del percorso applicabile prevalgono sull’esempio. In produzione va gestita anche la prova di restituzione quando rilevante.
Un errore frequente è rimborsare 50,00 € per la prima riga perché il catalogo espone ancora quel prezzo. Un altro è mostrare 90,00 € come già restituiti mentre la seconda operazione è in attesa. Nel pannello servono colonne distinte e un collegamento alla transazione, non un’unica etichetta verde.
Quando ci sono più aliquote, promozioni o importi non divisibili al centesimo, usa l’allocazione già registrata nell’ordine. Concorda arrotondamenti e documenti contabili con chi gestisce l’amministrazione; non ricostruire l’IVA dividendo il totale per il numero di prodotti.
La merce ricevuta non torna subito disponibile
Definisci almeno tre destinazioni: rivendibile, da controllare o ricondizionare, non vendibile. Il ricevimento registra la presenza fisica; una decisione successiva stabilisce la disponibilità commerciale. Se il collo contiene un prodotto diverso o manca un accessorio, la pratica deve rimanere riconoscibile senza alterare la riga originaria.
Per un cambio, verifica separatamente la disponibilità dell’articolo sostitutivo. «Cambio richiesto» non equivale a «pezzo riservato». Specifica quando scatta la prenotazione dello stock e come viene liberato se il cliente rinuncia. Prova questi passaggi nel tuo ambiente: le funzioni e i limiti dipendono dalla piattaforma e dalle integrazioni adottate.
Questa parte non sostituisce il processo dell’ordine: se gli identificatori a monte sono incoerenti, parti dalla guida al software per la gestione degli ordini clienti.
Rimborso inviato, in attesa o fallito: cosa mostrare
Il clic dell’operatore avvia una richiesta, non dimostra l’accredito sul conto del cliente. Stripe documenta rimborsi parziali e stati di attesa o errore: l’applicazione deve gestirli senza chiudere automaticamente la pratica. Conserva l’ID del rimborso e rendi visibili le anomalie a chi può intervenire. Documentazione Stripe sui rimborsi.
Ogni operazione economica deve avere un identificatore stabile. Se la connessione si interrompe dopo l’invio, verifica l’esito prima di creare una seconda richiesta. Non basta disabilitare il pulsante: due operatori o un retry del server possono agire sullo stesso caso.
I webhook possono essere duplicati o arrivare fuori ordine. Verifica la firma, deduplica gli eventi e riconcilia lo stato con il provider; non contare ogni notifica come un nuovo rimborso. La documentazione Stripe sui webhook esplicita queste condizioni. Per l’architettura complessiva, consulta l’integrazione API tra sistemi aziendali.
Otto prove prima di mettere il flusso online
- Reso parziale: una riga restituita non chiude o rimborsa le altre.
- Sconto storico: importi calcolati sull’acquisto, anche dopo una modifica del catalogo.
- Doppia azione: due operatori sullo stesso caso producono una sola operazione autorizzata.
- Webhook ripetuto: nessun doppio rimborso, movimento stock o messaggio al cliente.
- Pagamento in anomalia: la pratica rimane assegnata e visibile finché il problema non è risolto.
- Pacco inatteso: SKU o quantità differenti vengono registrati senza correggere retroattivamente l’ordine.
- Scadenza sensibile: la coda segnala i termini applicabili anche se l’ispezione non è terminata.
- Accesso non autorizzato: un cliente non vede il reso altrui cambiando l’ID nell’indirizzo; chi riceve la merce non ottiene automaticamente il permesso di rimborsare.
Esegui i test in sandbox, con ordini fittizi e senza denaro reale. Il verbale deve riportare input, risultato atteso, risultato osservato e responsabile della correzione. Un test fallito non diventa accettabile perché la demo del percorso normale funziona.
Quando basta una funzione nativa e quando serve sviluppo
| Situazione | Primo passo ragionevole |
|---|---|
| Un negozio, pochi operatori, percorso standard | Configurare e provare le funzioni già disponibili |
| Più canali con regole simili | Valutare un’estensione e verificare copertura delle integrazioni |
| Stati discordanti tra assistenza, ERP e pagamenti | Progettare il collegamento e la riconciliazione |
| Permessi, eccezioni o approvazioni distintive | Delimitare la parte su misura, senza riscrivere tutto il negozio |
Confronta configurazione, canone, gestione delle eccezioni, esportazione dei dati e manutenzione dei collegamenti. Una funzione pronta che supera le prove può essere la scelta migliore. Un sistema personalizzato ha senso quando elimina un vincolo dimostrato, non per aggiungere il tuo logo a una dashboard.
Per i costi generali del canale, usa la guida su quanto costa aprire un e-commerce. Per delimitare il progetto operativo, parti dalla digitalizzazione dei processi aziendali.
Misura tempi ed eccezioni, non soltanto quanti resi arrivano
Misura il tempo tra richiesta e primo riscontro, tra ricevimento e classificazione e tra autorizzazione e esito del rimborso. Tieni separate le attese del cliente da quelle interne. Altrimenti una media unica nasconde dove il processo si ferma.
Per confrontare periodi, definisci il denominatore: articoli restituiti di una coorte diviso articoli consegnati della stessa coorte, dopo una finestra di osservazione coerente. Dividere i resi di oggi per gli ordini di oggi confronta popolazioni diverse. Affianca cause, pratiche scadute e anomalie di riconciliazione: servono a decidere il prossimo intervento, non a promettere un calo percentuale senza dati.
Domande frequenti
Qual è la differenza tra reso e rimborso?
Il reso riguarda la restituzione della merce; il rimborso riguarda il denaro. Possono procedere in momenti diversi e vanno tracciati separatamente, nel rispetto delle condizioni e dei termini applicabili.
Serve un software dedicato per gestire i resi?
Non sempre. Prova prima le funzioni della piattaforma con resi parziali, cambi e anomalie. Un’estensione o un collegamento su misura serve quando emergono limiti concreti tra canali, permessi e sistemi.
Quando un articolo restituito torna vendibile?
Quando è stato verificato e assegnato alla destinazione corretta secondo il processo del negozio. Il semplice ricevimento del pacco non dimostra che il prodotto sia pronto per una nuova vendita.
Il rimborso risulta pending: posso chiudere la pratica?
Non considerarlo concluso soltanto perché è stato richiesto. Conserva il riferimento del provider, controlla lo stato successivo e assegna un responsabile alle anomalie prima della chiusura economica.
Fonti e verifica
Fonti consultate il 04/09/2026. Le funzioni dei prodotti possono cambiare; le condizioni del negozio vanno validate sul caso concreto prima di automatizzarle.