E-commerce
7 août 2026
« Où est mon remboursement ? » « Vous avez dit 48 h, ça fait 10 jours. » « Shopify affiche remboursé mais ma banque dit rien. » Trois messages où un bot générique promet un crédit immédiat ou invente une date sans lire le statut refund réel.
Gorgias estime que 12 à 18 % des tickets post-retour concernent le statut ou le délai de remboursement, souvent résolvables par lookup order (Gorgias, SAV 2026). Shopify rappelle que les remboursements peuvent rester en pending processor 5-10 jours ouvrés avant crédit banque (Shopify, remboursements 2026).
Ce guide #370 formalise le chatbot IA statut remboursement e-commerce : rassurer sans surpromettre. Nouveau cas d'usage IA post-retour distinct de bot retours (#10) (RMA) et de carte expirée (#369) (ops moyen fermé) : intents ref_stat_*, flow REF-STAT-GATE et garde-fous anti-promesse.
Sommaire
Pourquoi automatiser le statut remboursement par bot ?
Un bot statut remboursement répond : mon refund est-il lancé, en attente banque, ou bloqué. Il ne promet pas de date exacte CB : il cite statut Shopify, délai type et prochaine étape.
Trois échecs bot générique
Promesse 24 h : bot garantit crédit sans lookup refund
Date inventée : « vous serez remboursé demain » sans pending status
Refund non lancé ignoré : bot dit OK alors que retour pas reçu entrepôt
Narvar observe que la transparence sur délais remboursement réduit de 20 à 30 % les relances « où est mon argent » post-retour (Narvar, retours 2025).
Angle #370
Le #10 guide retour/RMA. Le #369 traite moyen paiement fermé ops. Le #370 implémente la couche bot ref_stat_* lookup timeline refund post-retour ou post-annulation.
ROI ref stat bot
Sur marque DTC 120 tickets « statut refund »/mois, bot ciblé 70 à 80 % auto-résolus vs bot générique 25 %.
Exemple DTC
Marque mode, 98 tickets ref_stat/mois. Après bot REF-STAT-GATE : ref_stat_bot_resolution 81 %, ref_stat_false_promise 1,5 %, temps réponse 25 s, CSAT refund status 4,6/5.
Moment parcours
Post-RMA J+1 à J+15, post-annulation, post-partial (#368). Trigger : remboursement, refund, argent, banque, délai.
Prérequis ops
Policy délais refund publiée (/retours). Webhook return received → refund trigger documenté. Bot handoff #369 si ref_exp signals.
Rassurer sans surpromettre
Ton empathie + faits : montant, date lancement, statut processor, délai banque type 5-10 j. Jamais « demain sur votre compte ».
Déterministe vs LLM
Statut et délais = lookup order timeline. LLM reformule message rassurant, ne décide pas si refund lancé.
Volume saisonnier
Pic janvier post-fêtes retours (#253) et soldes. Bot réduit charge agents sur WISMO-refund hybrid.
Chargeback prévention
Client non informé sur délai banque ouvre chargeback J+7. Bot REF-STAT-GATE + email proactive réduit litiges « refund not received » de 25 à 40 % selon boutiques DTC équipées.
Différence WISMO vs refund status
WISMO = colis en transit. ref_stat = argent après retour. Router distinct évite réponse tracking quand client demande remboursement.
En quoi diffère-t-il du bot retours #10 et du REF-EXP #369 ?
Huit contenus voisins, huit rôles bot distincts post-retour.
Bot retours (#10)
Bot retours (#10) : RMA et échange. Le #370 intervient après retour expédié ou refund lancé.
Carte expirée (#369)
REF-EXP (#369) : ops moyen fermé, IBAN. Le #370 handoff ref_stat_expired si > 10 j ou failed.
Remboursement partiel (#368)
Partial (#368) : montant partiel. Le #370 cite partial_amount si ref_stat_partial.
Bot éligibilité (#365)
Éligibilité (#365) : amont retour. Le #370 = aval refund timeline.
Paiements fractionnés (#194)
Fractionné (#194) : sync BNPL. Le #370 handoff ref_stat_bnpl si Klarna/Alma.
Préqualification (#138)
Préqualification (#138) : collecte amont. Le #370 assume retour déjà initié ou annulation.
Retours fêtes (#253)
Retours fêtes (#253) : volume pic. Le #370 scale statut lookup janvier.
Promesse #370
Intents ref_stat_*, flow REF-STAT-GATE, garde-fous REF-STAT-GUARD, handoff #369/#194, KPI ref_stat_bot.
Quels intents ref_stat le bot doit-il classifier ?
Cartographier les intents ref_stat avant flows. Scope : informer statut, pas lancer refund bot seul.
Douze intents statut refund bot
ref_stat_where_money : où est mon remboursement générique
ref_stat_not_started : retour pas reçu entrepôt, refund pas lancé
ref_stat_pending_processor : Shopify pending, attente normal
ref_stat_success_waiting_bank : success Shopify, délai banque
ref_stat_partial_amount : partial lancé, montant question
ref_stat_failed : processor failed, handoff #369
ref_stat_expired_card : carte expirée, handoff REF-EXP
ref_stat_bnpl : Klarna/Alma échéancier, handoff #194
ref_stat_cancel_order : annulation pré-expédition refund
ref_stat_arn_request : demande référence ARN banque
ref_stat_too_early : client relance J+1, éducation délai
ref_stat_angry_handoff : menace chargeback, escalade P1
Champs session obligatoires
order_id, return_status, refund_status, refund_amount, refund_date, days_since_refund, arn, payment_method, ref_stat_intent.
Router parent
« remboursement », « refund », « argent », « banque », « délai » post-order → ref_stat_*. « Comment retourner » → #365 ou #10.
Mining tickets 90 j
Export « remboursement », « pas reçu », « statut ». Prioriser flows top verbatims.
Priorisation MVP
Semaine 1 : ref_stat_success_waiting_bank + ref_stat_not_started. Semaine 2 : ref_stat_pending + ref_stat_too_early. Semaine 3 : ref_stat_failed + handoff #369.
Comment construire le flow REF-STAT-GATE ?
Le flow REF-STAT-GATE route chaque message via lookup order timeline avant réponse statut.
Sept gates séquentielles
Gate auth : email + order_id
Gate return status : RMA créé, colis transit, reçu entrepôt
Gate refund exists : refund event timeline oui/non
Gate refund status : none, pending, success, failed
Gate payment method : CB, PayPal, BNPL → branch si besoin
Gate days_since : too_early vs normal vs escalate
Gate sortie : message statut, éducation délai, handoff
Branche ref_stat_not_started
Retour pas reçu : « Nous traitons le remboursement sous 48 h après réception entrepôt. Tracking retour : [status]. » Pas promesse refund lancé.
Branche ref_stat_success_waiting_bank
« Remboursement de [X] € lancé le [date]. Statut : traité. Délai crédit banque : 5-10 j ouvrés. Vérifiez compte complet si carte expirée. »
Branche ref_stat_pending_processor
« Remboursement en cours côté processeur. Délai normal 3-5 j ouvrés avant statut final. Nous vous invitons à revenir si J+7 sans changement. »
Branche ref_stat_failed
Handoff #369 REF-EXP immédiat. Bot ne retente pas refund seul.
Template délai banque
Fixe policy : CB UE 5-10 j, PayPal 3-5 j, BNPL voir #194. Bot cite fourchette, pas date exacte.
ref_stat_arn_request
Si ARN disponible metafield Shopify Payments : bot partage REF-STAT-ARN template. Client communique à banque si crédit absent J+10.
Escalade days_since seuil
Success + days_since > 10 : handoff #369 ref_exp. Pending + days_since > 7 : supervisor vérification processor.
Quelles sources de data le bot statut lit-il ?
Le bot statut refund lit data live Shopify + return portal sans halluciner timeline.
Sources Shopify obligatoires
Order timeline : refund events, amounts, status
Fulfillment/return : return received date entrepôt
Payment method : gateway, last4, PayPal email
ARN metafield : si capturé post-refund Shopify Payments
Partial refunds : liste montants PART-REF #368
Sources portail retour
Loop/ReturnGO API : return status in_transit, delivered, inspected
Policy RAG : délais /retours indexés
REF-EXP doc #369 : handoff rules expired/failed
Sync webhook return received
Trigger refund ops sous 48 h post-réception. Bot ref_stat_not_started cite ETA refund launch from policy.
BNPL flag
Tag order klarna/alma : ref_stat_bnpl handoff #194, pas délai CB standard.
Quels garde-fous REF-STAT-GUARD imposer ?
Les garde-fous REF-STAT-GUARD évitent promesses refund et dates inventées.
Six règles strictes
Pas date exacte CB : fourchette 5-10 j seulement
Pas refund lancé bot : informer statut, handoff si action requise
Lookup avant réponse : auth + timeline obligatoires
Failed = handoff #369 : pas retry bot
BNPL = handoff #194 : pas délai CB générique
Empathie sans admission faute : « nous comprenons » sans « erreur boutique » sans preuve
Prompt system ref stat
« Tu informes sur statut remboursement selon timeline order. Tu ne promets jamais crédit demain. Tu cites montant, date lancement, statut processor, délai banque type. Si failed ou expired card, handoff #369. Si BNPL, handoff #194. » Voir anti-hallucination.
ref_stat_too_early
J+1 post-refund success : éducation patiente, pas escalade. « Délai normal en cours. »
Audit false promise
Sample 50 conversations/mois : ref_stat_false_promise_rate. Cible < 2 %. Revue mensuelle transcripts bot vs timeline order.
Sur quels parcours client déployer le bot statut ?
Le bot statut refund se déploie sur points de contact post-retour anxieux.
Flow chat « où est mon remboursement »
Auth → REF-STAT-GATE → message statut ou handoff.
Flow email retour reçu J+0
« Retour reçu, remboursement sous 48 h » + lien chat statut pré-rempli order_id.
Flow email refund lancé J+0
« Remboursement [X] € lancé. Crédit banque 5-10 j. Questions ? [chat] » Réduit ref_stat relances.
Flow compte client
Badge commande : « Remboursement lancé le [date], délai banque en cours » lookup live.
Flow portail retour Loop
Statut « Refund processing » : bouton « Détails délai » → chat ref_stat.
Flow ref_stat_angry_handoff
Menace chargeback J+7 : P1 supervisor payload timeline + ARN.
Proactive notification
Webhook refund success → email/SMS auto avec fourchette délai. Bot handle follow-up questions.
Widget post-retour portail
Loop status « Refund initiated » : CTA chat intégré avec order_id session. Client ne quitte pas portail pour email SAV.
Multicanal cohérent
Même REF-STAT-GATE sur chat site, WhatsApp si connecté Shopify lookup, et email auto-reply parser ref_stat keywords.
Comment configurer le bot statut sur Shopify ?
Le setup bot statut refund Shopify connecte timeline, portail retour et RAG délais.
Checklist technique
Documenter délais refund policy /retours
Sync return received webhook + refund trigger SLA
Indexer timeline refund API order lookup
Intégrer Loop return status API
Configurer router ref_stat_* mots-clés
Implémenter REF-STAT-GATE section 4
Rédiger prompt REF-STAT-GUARD section 6
Brancher handoff #369 et #194 payloads
Tester 25 scénarios régression
Dashboard ref_stat_bot_resolution hebdo
Email templates alignés
Même wording délais bot et emails post-refund. Cohérence réduit ref_stat_too_early disputes.
Lancement progressif
Phase 1 : ref_stat_success + not_started. Phase 2 : pending + too_early. Phase 3 : failed + bnpl handoffs.
Quels KPI ref_stat_bot mesurer ?
Sans KPI ref_stat_bot, impossible de prouver ROI vs agents seuls.
Sept métriques clés
ref_stat_bot_resolution : résolu sans agent / sessions ref stat
ref_stat_deflection : tickets refund status évités / sessions
ref_stat_false_promise_rate : promesse date/montant incorrecte bot
ref_stat_handoff_rate : #369 + #194 + angry / sessions
ref_stat_too_early_rate : J+1-3 relances / total ref stat
ref_stat_repeat_contact_7d : client revient 7 j / sessions
CSAT intent ref_stat : satisfaction statut bot
Benchmark DTC
Objectif ref_stat_bot_resolution > 78 %, ref_stat_false_promise < 2 %, ref_stat_repeat_contact_7d < 15 %, CSAT > 4,5/5.
Impact chargeback
Mesurer chargebacks « refund not received » avant/après bot proactive + REF-STAT-GATE.
Réduction tickets agents
Tracker heures agent refund status avant/après. Cible -40 % volume ref_stat tickets.
Corrélation CSAT et délai
Mesurer CSAT ref_stat par tranche days_since_refund. Ajuster messaging ref_stat_too_early si CSAT chute J+1-3 malgré éducation.
Quels edge cases et handoffs prévoir ?
Sept edge cases ref stat bot exigent handoff ou message spécifique.
Split refund multi-colis
Partial refund colis 1 seulement. Bot cite line items refunded. Lien split (#356).
Gift order refund status
Refund vers acheteur. Destinataire contacte : expliquer moyen paiement acheteur, pas transfert info CB.
Store credit vs CB refund
Si partial (#368) a choisi avoir : bot cite code credit, pas délai banque.
Manual IBAN pending
#369 manual refund en cours : bot cite délai virement 5 j, pas statut Shopify success.
Return lost transit
Colis retour perdu : handoff ops, pas ref_stat_success message.
Multi-refund same order
Lister tous refund events timeline avec montants cumulés.
Markets multi-devise
Citer montant devise order originale, pas conversion approximative.
Preorder cancel refund
ref_stat_cancel_order : délai charge-later capture void 5-7 j.
Exchange vs refund confusion
Client a demandé échange (#367) mais attend refund : bot vérifie resolution_type order. Handoff si mismatch reship vs refund lancé.
Comment Qstomy informe le statut remboursement ?
Qstomy lookup refund timeline, applique REF-STAT-GATE et handoff #369/#194 si needed.
Capacités statut remboursement
ref_stat_lookup : timeline refund + return status live
ref_stat_gate : 7 gates déterministes section 4
ref_stat_delay_edu : fourchette délai payment method
ref_stat_arn_share : ARN si disponible metafield
ref_stat_handoff : #369 failed/expired, #194 bnpl
Scénario DTC chiffré
Marque home, 112 tickets ref_stat/mois, agents répétaient délais incohérents.
Après Qstomy REF-STAT flows : 74 % auto-résolus, ref_stat_bot_resolution 83 %, ref_stat_false_promise 1,2 %, repeat contact 7d 11 %, CSAT 4,7/5.
Explorez support IA, Shopify, demander une démo.
Quelle checklist pour lancer REF-STAT ?
Checklist bot statut refund (10 étapes)
Auditer tickets ref_stat 90 j
Publier délais refund /retours alignés bot
Connecter order timeline + return portal API
Indexer RAG policy délais + REF-EXP #369
Implémenter REF-STAT-GATE section 4
Configurer router ref_stat_* intents
Rédiger prompt REF-STAT-GUARD section 6
Emails post-refund alignés bot wording
Tester 25 scénarios régression
Dashboard ref_stat_bot_resolution hebdo
En bref
#370 = bot statut remboursement post-retour, pas RMA (#10)
REF-STAT-GATE : return → refund status → délai → message
12 intents ref_stat_* : pending, success, failed, BNPL
Rassurer sans surpromettre : fourchette, pas date exacte
KPI ref_stat_bot_resolution : cible > 78 %
FAQ
Bot peut-il lancer un remboursement ?
Non. Informer statut et handoff agent si action ops requise.
Différence avec #369 ?
#370 = lookup statut et délais. #369 = ops moyen fermé et IBAN manual.
Client J+2 après refund success ?
ref_stat_too_early : éducation délai 5-10 j normal.
BNPL Klarna ?
Handoff #194, pas message délai CB standard.
Refund failed Shopify ?
Handoff immédiat #369 REF-EXP, bot ne retente pas.
Aller plus loin
Testez mystery shop : order refund success J+3, vérifiez bot cite montant + date + fourchette 5-10 j sans promesse demain.
Partagez ce guide #370 avec support et ops : un bot statut remboursement bien calibré transforme l'anxiété post-retour en confiance factuelle, sans promesse de date impossible.
Enzo
7 août 2026
