E-commerce
1 juillet 2026
« J'ai renvoyé mon colis, pourquoi pas de remboursement ? » « Le portail dit « inspecté », que signifie-t-il ? » « Ça fait 10 jours sans nouvelle, où en est mon retour ? » Trois tickets WISMR où un suivi retour mal expliqué génère relances, chargeback et surcharge agents post-RMA.
Le support statuts retour e-commerce couvre étapes reçu, inspecté, remboursement en cours et délai banque. Distinct bot retours #10 (initier RMA) et statut refund #370 : ici, timeline retour entrepôt inspection refund trigger.
Ce guide #639 couvre policy RSTAT-SUP, flow RS-1 à RS-8 et matrice RSTAT-MAP. Paire SAV du futur bot WISMR (#640).
Sommaire
Pourquoi les statuts de retour génèrent-ils des tickets support ?
Le client a créé un RMA et renvoyé le colis. Il consulte le portail chaque jour sans comprendre la différence entre « en transit », « reçu » et « inspecté ». Sans SOP, l'agent promet remboursement immédiat alors que l'inspection n'est pas terminée ou confond statut retour et statut remboursement banque.
Cinq frictions typiques WISMR
Statuts opaques : libellés portail incompris client
Délai inspection : reçu vs inspecté vs refund flou
Scan carrier retardé : colis déposé statut inchangé J+3
Inspection refusée : état produit partial refund incompris
Refund vs banque : Shopify refunded relevé vide confondu
Narvar observe que la transparence sur étapes retour réduit les relances post-RMA (Narvar, retours 2025). Sans RSTAT-MAP, agents improvisent délais et statuts.
RSTAT #639 vs bot retours #10, refund statut #370, RETLOCK #633 et bot #640
Cinq contenus, cinq layers suivi retour distincts.
Matrice rapide
#639 RSTAT : timeline reçu inspecté refund trigger WISMR
Bot retours #10 : initier RMA échange remboursement distinct suivi statut
Refund statut #370 : délai banque post-refund Shopify distinct timeline retour
Retour relais #633 : dépôt casier scan carrier amont entrepôt distinct
#640 RSTATbot : bot tier 1 statuts timeline handoff
#639 = où en est mon retour entrepôt. #370 = où est mon argent après refund lancé.
Quelles typologies rstat_* classifier ?
Huit scénarios tickets statut retour.
Huit typologies rstat
rstat_how_it_works : client ne comprend étapes retour portail
rstat_label_pending : RMA créé colis pas encore expédié client
rstat_in_transit : retour en route vers entrepôt carrier scan
rstat_received : colis reçu entrepôt inspection pas commencée
rstat_inspecting : contrôle qualité en cours délai map
rstat_inspection_hold : état refusé partial refund litige
rstat_refund_pending : refund déclenché processing Shopify
rstat_stuck_no_update : aucun changement statut au-delà SLA map
Tags : rstat, wismr, return_status. RSTAT-MAP-GROUNDED : status_label next_step depuis map only.
Comment structurer la matrice RSTAT-MAP ?
La matrice RSTAT-MAP documente chaque statut retour pour agents et futur bot #640.
Colonnes RSTAT-MAP
rstat_status_code : label_pending in_transit received inspecting etc
customer_label_fr : libellé portail affiché client map
customer_copy : phrase explain statut client map
next_step_expected : prochaine étape timeline map
sla_hours_typical : délai médian statut map
inspection_sla_days : délai contrôle qualité si received map
refund_trigger_on : inspected_pass partial_fail map
portal_3pl_map : Loop ReturnGO Shopify status mapping
proactive_email_template : notification auto changement statut
escalate_if_exceeds_sla : Y/N ops ticket map
Sync portail retour, emails proactive status change, macros helpdesk et page FAQ statuts retour.
Policy RSTAT-SUP en six règles
Six règles support statuts retour.
RSTAT-MAP-GROUNDED : statut next_step sla depuis map only
STATUS-API-VERIFY : return status API before statut cite
NO-REFUND-PROMISE-BEFORE-INSPECT : refund après refund_trigger_on map
REFUND370-REROUTE : post-refund banque → #370 ref_stat distinct timeline retour
INSPECTION-HOLD-CITE : inspection_hold partial policy cite map
STUCK-SLA-ESCALATE : rstat_stuck_no_update dépasse sla → ops
Flow RSTAT RS-1 à RS-8
Flow agent huit étapes statut retour.
RS-1 Intake : rstat_* intent + rma_id order_ref tracking return
RS-2 Status lookup : RSTAT-MAP status rules sla refund trigger
RS-3 Return API : return_status received_date inspection refund API
RS-4 Classify : transit received inspecting hold refund stuck
RS-5 Policy triage : NO-REFUND-PROMISE INSPECTION-HOLD STUCK-SLA
RS-6 Respond : macro RSTAT grounded map customer_copy timeline
RS-7 Execute : escalate ops partial refund photos carrier claim
RS-8 Close : tag rstat_resolved rstat_status_code refunded Y/N
SLA : rstat_received répondu avec customer_copy next_step sla_hours_typical map en une interaction.
Macros RSTAT essentielles
Quatre macros agents statuts retour.
RSTAT-EXPLAIN-01
« Retour [rma_id] : étapes 1) expédier 2) reçu entrepôt 3) inspection 4) remboursement. Statut actuel : [customer_label_fr map] : [customer_copy map]. Prochaine étape : [next_step_expected map]. »
RSTAT-TIMELINE-01
« Commande [order_ref] retour [rma_id] : [rstat_status_code API map]. [Si in_transit : scan carrier [date].] [Si received : inspection sous [inspection_sla_days map] j.] [Si inspecting : contrôle qualité en cours délai normal [sla_hours_typical map] h.] »
RSTAT-INSPECT-01
« Inspection [rma_id] : [passed / hold / partial map]. [Si hold : [INSPECTION-HOLD-CITE map raison état].] [Si passed : refund selon [refund_trigger_on map] sous [sla map].] Photos demandées si litige. »
RSTAT-REFUND-LINK-01
« Refund [rma_id] : statut [refund_pending / success Shopify API]. Montant [amount map]. [Si success : délai banque #519 bank_ref ou #370 ref_stat.] NO-REFUND-PROMISE si inspection non terminée. »
Cas limites : partial refund, retour perdu, multi-RMA et échange en cours
Cinq cas hors macro statut retour standard.
Remboursement partiel : #368 partial distinct full refund timeline
Colis retour perdu : carrier claim STUCK-SLA escalate ops
Multi-RMA une commande : split status par ligne panier
Échange pas refund : #366 reship distinct rstat refund
Retour refusé livraison : #511 REFDEL timeline distinct RMA client
WISMR actif = rma_status open ou refund_pending. Ne pas promettre refund si rstat_status_code received ou inspecting only.
KPI rstat essentiels
Cinq métriques pilotage RSTAT.
rstat_wismr_ticket_rate : tickets rstat_* / RMA actifs
rstat_status_cite_rate : % réponses RSTAT-MAP-GROUNDED map
rstat_stuck_escalate_rate : stuck_no_update / total rstat tickets
rstat_inspection_sla_met : inspections dans sla / received
rstat_false_refund_promise_rate : promesse refund avant inspect audit cible 0
Cible : rstat_status_cite_rate supérieur à 95 % et rstat_wismr_ticket_rate baisse 20 % post emails proactive.
Anti-patterns RSTAT
Cinq erreurs fréquentes support statuts retour.
Promettre refund avant inspection : NO-REFUND-PROMISE-BEFORE-INSPECT
Statut inventé sans API : STATUS-API-VERIFY return lookup
Confondre refund banque #370 : REFUND370-REROUTE timeline distinct
Ignorer stuck SLA : STUCK-SLA-ESCALATE ops ticket
Libellé portail non expliqué : customer_copy RSTAT-MAP verbatim
RSTAT avec Qstomy
Qstomy sur Shopify : detect rstat intent, RSTAT-MAP RAG grounded, return_status API lookup, timeline cite, handoff #640 bot tier 1 WISMR.
Pipeline : #640 bot explain statuts tier 1 → #639 agents inspect hold stuck escalate ops.
Explorez support IA et demander une démo.
Checklist, FAQ et aller plus loin
Checklist RSTAT (8 étapes)
RSTAT-MAP v1 : statuts portail customer_copy sla refund trigger
Policy RSTAT-SUP : 6 règles NO-REFUND-PROMISE STATUS-API-VERIFY
8 typologies rstat_* : tags helpdesk wismr
4 macros RSTAT-* : EXPLAIN TIMELINE INSPECT REFUND-LINK
Emails proactive statut : received inspecting refund templates
Page FAQ statuts : timeline visuelle reçu inspecté remboursé
Formation agents 30 min : RSTAT vs #10 vs #370 vs WISMO livraison
Dashboard KPI : rstat_* section 9 wismr_ticket_rate
FAQ
Différence « reçu » et « inspecté » ?
RSTAT-TIMELINE-01 : received = entrepôt a le colis. inspecting = contrôle qualité en cours.
Quand suis-je remboursé ?
RSTAT-REFUND-LINK-01 refund_trigger_on map. Puis délai banque #370 ou #519.
Statut bloqué 10 jours ?
rstat_stuck_no_update STUCK-SLA-ESCALATE ops si dépasse sla_hours_typical map.
Relation #640 bot ?
#640 = bot tier 1 statuts timeline. #639 = agents inspect hold stuck escalate ops.
Aller plus loin
Cette semaine : indexer RSTAT-MAP statuts portail, activer emails proactive received inspecting, test macro RSTAT-TIMELINE-01 agents.
Enzo
1 juillet 2026
