E-commerce
2 août 2026
« Puis-je encore retourner ma commande ? » « Votre site dit 30 jours mais le portail refuse. » « C'est un produit hygiène, vous acceptez quand même ? » Trois messages où un bot générique promet un retour sans vérifier date, SKU ou exclusions policy.
Narvar observe que 67 % des consommateurs consultent la politique de retour avant d'acheter, et que l'écart entre promesse site et refus portail génère litiges et chargebacks (Narvar, retours 2025). Loop Returns estime qu'un check éligibilité self-service bien calibré peut dévier 40 à 55 % des tickets retour simples avant agent (Loop Returns, policy 2026).
Ce guide #365 formalise le chatbot IA éligibilité retour e-commerce : vérifier délai, exclusions et règles avant RMA. Il complète préqualification retour (#138) (collecte motif amont) avec l'angle lookup déterministe order + policy RET-ELIG + handoff late (#364). Distinct de bot retours (#10) (parcours échange/remboursement complet).
Sommaire
Pourquoi automatiser l'éligibilité retour par bot ?
Un bot éligibilité retour répond : suis-je encore éligible, pourquoi le portail bloque, quelle alternative si refus. Il ne crée pas le RMA seul sans règles : il applique RET-ELIG-GATE avant lien portail ou handoff.
Trois échecs bot générique
Promesse retour : bot garantit refund sans lookup delivery_date
Délai inventé : « 30 jours » alors que SKU final sale 0 j
Hygiène ignorée : bot ouvre RMA sur sous-vêtements portés
Shopify rappelle que l'éligibilité retour doit être cohérente entre PDP, portail et SAV pour éviter litiges (Shopify, return policy 2026).
Angle #365
Le #138 collecte motif et fiche handoff. Le #10 guide échange/remboursement post-éligibilité. Le #365 implémente la couche bot ret_elig_* : date check, exclusions SKU, extension fêtes, handoff late_ret (#364).
ROI ret elig bot
Sur marque mode 720 retours/mois, bot éligibilité ciblé 65 à 75 % auto-résolus vs 25 % bot retour générique qui handoff systématique.
Exemple DTC
Marque accessoires, 48 tickets elig/mois dont 31 % hors délai mal routés. Après bot RET-ELIG-GATE : ret_elig_bot_resolution 78 %, ret_elig_false_promise 2 %, temps réponse 28 s, CSAT elig 4,5/5.
Moment parcours
Pre-RMA : client hésite, portail error, chat « puis-je retourner ». Trigger : retour, échange, délai, éligible, expired.
Prérequis ops
Policy retour publiée + LATE-RET (#364) pour hors délai. Metafields return_window, final_sale, product_hygiene. Bot cite RAG policy, pas invente règles.
Pourquoi bot dédié éligibilité
Coupler au bot retour complet (#10) dilue précision : client « retourner » reçoit procédure échange sans date check. Router ret_elig_* en amont évite RMA invalides et charge entrepôt.
Volume et saisonnalité
Tickets éligibilité pic janvier (retours fêtes #253) et fin de mois (deadline 30 j). Bot ret_elig_holiday_extend gère extension temporaire sans agent.
Coût fausse promesse bot
Bot qui promet retour hors délai crée RMA rejeté entrepôt + chargeback. RET-ELIG-GUARD interdit lien RMA si days_over > 0 sans grille LATE-RET.
Déterministe vs LLM
La décision éligible oui/non est calculée (dates, tags, metafields). Le LLM reformule la réponse et propose alternatives, il ne décide pas seul.
En quoi diffère-t-il de la préqualification #138 et du bot retours #10 ?
Sept contenus retours, sept rôles bot distincts.
Préqualification (#138)
Préqualification (#138) : collecte motif, fiche handoff. Le #365 = check éligibilité déterministe avant collecte motif.
Bot retours (#10)
Bot retours (#10) : parcours échange/remboursement. Le #365 intervient en gate amont, handoff #10 si eligible=true.
Retour hors délai (#364)
Late return (#364) : policy LATE-RET ops humaine. Le #365 handoff ret_elig_late via grille exceptions bot ou agent.
Politique retour
Politique retour : rédaction contrat. Le #365 = exécution automatisée règles policy.
Retours fêtes (#253)
Retours fêtes (#253) : extension janvier. Le #365 : intent ret_elig_holiday_extend lookup flag shop.
Retours bundle
Retours partiels bundle : kit SKU. Le #365 vérifie return_bundle_partial_allowed metafield.
Colis endommagé (#363)
Colis endommagé (#363) : sinistre transit. Si ret_elig_motif=damage : router dmg workflow, pas retour standard.
Promesse #365
Intents ret_elig_*, flow RET-ELIG-GATE, garde-fous RET-ELIG-GUARD, handoff #364/#10, KPI ret_elig_bot.
Quels intents ret_elig le bot doit-il classifier ?
Cartographier les intents ret_elig avant flows. Scope : vérifier et expliquer, pas approuver exception sans grille.
Douze intents éligibilité bot
ret_elig_check : suis-je éligible ? date lookup
ret_elig_deadline_info : quand expire mon délai ?
ret_elig_portal_blocked : portail refuse, pourquoi ?
ret_elig_final_sale : soldes finales, pas retour
ret_elig_hygiene : produit hygiène ouvert
ret_elig_late : hors délai, handoff #364
ret_elig_holiday_extend : extension fêtes active
ret_elig_gift_order : commande cadeau, règle destinataire
ret_elig_bundle_partial : retour partiel kit autorisé ?
ret_elig_preorder : précommande, deadline depuis livraison
ret_elig_marketplace : order canal externe, redirect
ret_elig_denied_handoff : conteste refus bot, escalade
Champs session obligatoires
order_id, delivery_date, return_deadline, days_remaining, days_over, sku_tags, final_sale, hygiene_flag, holiday_extend_active, eligible (bool). Voir taxonomie (#135).
Router parent
« éligible », « délai retour », « portail refuse », « plus de 30 jours » → ret_elig_*. « Comment retourner étape par étape » sans check → #10 retours.
Mining tickets 90 j
Export tags return + « expired », « hors délai », « final sale ». Prioriser flows top verbatims avant intégration Loop API.
Priorisation MVP
Semaine 1 : ret_elig_check + ret_elig_deadline_info. Semaine 2 : ret_elig_final_sale + ret_elig_hygiene. Semaine 3 : ret_elig_late + handoff #364.
Comment construire le flow RET-ELIG-GATE ?
Le flow RET-ELIG-GATE route chaque message via lookup order et policy avant réponse éligibilité.
Sept gates séquentielles
Gate auth : email + order_id
Gate canal : marketplace → ret_elig_marketplace redirect
Gate SKU : final_sale, hygiene, digital → exclusions
Gate date : delivery_date + window → days_remaining ou days_over
Gate holiday : holiday_extend_active recalcule deadline
Gate late : days_over > 0 → ret_elig_late ou grille LATE-RET (#364)
Gate sortie : eligible + lien RMA, ou refus + alternative, ou handoff
Branche ret_elig_check eligible
Si days_remaining > 0 et exclusions OK : « Vous avez [N] jours restants (deadline [date]). Lien retour : [portail]. » Pas promesse refund, lien self-service.
Branche ret_elig_portal_blocked
Recalculer même logique que portail. Si mismatch merchant_error (PDP disait 45 j, policy 30 j) : handoff ret_elig_denied avec flag error.
Branche ret_elig_late
Citer deadline passée. Si days_over 1-3 et LTV OK : proposer formulaire exception #364. Sinon refus empathique + avoir template LATE-RET-DENY.
Max tours clarification
2 clarifications max (quel SKU multi-line). Puis handoff agent payload elig complet.
Output eligible=true
Bot envoie deep link portail Loop/ReturnGO pré-rempli order_id + line_item. Session flag rma_link_sent=true.
Quelles sources de data le bot éligibilité lit-il ?
Un bot éligibilité sans data live Shopify hallucine délais et exclusions.
Sources Shopify obligatoires
Order fulfillment : delivery_date par line ou fulfillment
Product tags : final-sale, hygiene, no-return, bundle
Metafields produit : return_window_override, return_excluded
Metafields shop : default_return_window_days, holiday_extend_end
Customer LTV : segment pour grille late exception
Sources portail retour
Loop / ReturnGO API : eligible boolean mirror, RMA URL
Policy RAG : texte /retours indexé, exclusions listées
LATE-RET doc #364 : grille exceptions pour ret_elig_late
Sync delivery_date
Webhook fulfillment delivered ou carrier API. Si delivery_date null : bot ret_elig_preorder ou handoff WISMO in_transit.
Cohérence portail vs bot
Bot doit appeler même API eligible que portail. Test CI : 20 orders sample, bot result = portail result 100 %.
Gift order flag
Metafield gift_order ou note checkout. ret_elig_gift_order applique règle +14 j destinataire si policy LATE-RET section 5.
Quels garde-fous RET-ELIG-GUARD imposer ?
Les garde-fous RET-ELIG-GUARD évitent RMA invalides et promesses refund bot.
Six règles strictes
Pas RMA si eligible=false : refus + alternative, pas lien portail bypass
Auth avant elig : order_id + email obligatoires
LLM ne décide pas : eligible = fonction dates + tags, LLM reformule
Hygiène jamais override bot : handoff supervisor seul, pas exception auto
Late exception limitée : grille #364, pas invention agent bot
Citer deadline exacte : date calculée, pas « environ 30 jours »
Prompt system ret elig
« Tu vérifies éligibilité retour selon RET-ELIG-GATE. Tu ne promets jamais remboursement. Si eligible, tu envoies lien portail. Si hors délai, tu appliques LATE-RET ou handoff. Si final_sale ou hygiene, tu refuses avec policy citation. » Voir anti-hallucination.
Audit false promise
Sample 50 conversations/mois : ret_elig_false_promise_rate = bot dit oui alors eligible=false. Cible < 3 %.
Refus templates
Trois templates fixes : final_sale, hygiene, late_denied. LLM personnalise empathie, pas règle.
Sur quels parcours client déployer le bot éligibilité ?
Le bot éligibilité intervient sur points de contact pre-RMA.
Flow chat « puis-je retourner »
Auth → RET-ELIG-GATE → eligible lien RMA ou ret_elig_late handoff.
Flow portail error redirect
Page erreur portail : bouton « Pourquoi refusé ? » → chat ret_elig_portal_blocked explication.
Flow email post-livraison J+25
Rappel deadline 5 j restants + lien chat ret_elig_check. Réduit late_ret volume.
Flow PDP widget FAQ
« Délai retour ce produit ? » pre-achat : lookup return_window_override metafield sans order.
Flow compte client
Section commandes : badge « Retour possible jusqu'au [date] » calculé bot rule engine.
Flow ret_elig_denied_handoff
Client conteste : supervisor payload order, calc eligible, screenshot PDP si merchant_error claim.
Handoff #10 post-eligible
Si eligible=true et client veut échange taille : router bot retours (#10) avec contexte elig OK.
Comment configurer le bot éligibilité sur Shopify ?
Le setup bot éligibilité Shopify connecte order API, portail retour et RAG policy.
Checklist technique
Documenter return_window shop + overrides SKU metafields
Sync delivery_date webhook fulfillment
Intégrer Loop/ReturnGO eligible API (Shopify App Store)
Indexer policy /retours + LATE-RET #364 RAG
Configurer router ret_elig_* mots-clés
Implémenter RET-ELIG-GATE section 4
Rédiger prompt RET-ELIG-GUARD section 6
Tester 25 scénarios régression CI
Dashboard ret_elig_bot_resolution hebdo
Intégration helpdesk
Handoff sidebar : eligible oui/non, deadline, days_over, sku_exclusions, rma_link_sent.
Lancement progressif
Phase 1 : ret_elig_check + deadline_info. Phase 2 : exclusions final_sale/hygiene. Phase 3 : ret_elig_late + #364 handoff.
Test régression mensuel
20 orders fixture : eligible true/false, holiday extend, bundle, late 2j. Bot vs portail parity check.
Quels KPI ret_elig_bot mesurer ?
Sans KPI ret_elig_bot, impossible de prouver ROI vs macros #364 seules.
Sept métriques clés
ret_elig_bot_resolution : résolu sans agent / sessions ret elig
ret_elig_deflection : tickets elig évités / sessions
ret_elig_rma_link_sent_rate : eligible + lien / ret_elig_check
ret_elig_late_handoff_rate : late / sessions elig
ret_elig_false_promise_rate : oui bot alors eligible=false
ret_elig_portal_parity_rate : bot = portail / sample audit
CSAT intent ret_elig : satisfaction check éligibilité
Benchmark DTC
Objectif ret_elig_bot_resolution > 75 %, ret_elig_false_promise < 3 %, ret_elig_portal_parity 100 % sur sample, CSAT > 4,4/5.
Impact late_ret volume
Mesurer late_return_volume (#364) avant/après bot rappel J+25. Cible -20 % tickets late_ret_few_days_over.
Coût RMA invalides évités
Tracker colis retour rejetés entrepôt sans RMA valide. Bot elig doit réduire ce volume de 30 à 50 %.
Quels edge cases et handoffs prévoir ?
Sept edge cases ret elig bot exigent handoff ou procédure spéciale.
Split shipment delivery dates
Colis 1 J+5, colis 2 J+28 : elig par line_item delivery_date. Lien split (#356).
Multi-SKU order partiel
Line 1 eligible, line 2 final_sale : bot explique mix, lien RMA partiel portail.
Extension fêtes + late overlap
Holiday extend jusqu'au 31 jan. Client 5 fév : ret_elig_late standard, pas extend.
Preorder delivered late
Deadline depuis delivery réelle, pas order date. Bot cite tracking delivered_at.
B2B ou wholesale order
return_excluded tag B2B : handoff account manager, pas RMA DTC.
Client sans compte, cadeau
Auth email destinataire + order_id gift. ret_elig_gift_order règle +14 j si policy.
Dommage colis vs retour satisfaction
Motif « colis cassé » : router dmg (#363), pas ret_elig_check standard.
Contest merchant_error PDP
Client screenshot PDP 45 j vs policy 30 j : handoff ret_elig_denied supervisor, flag merchant_error.
Comment Qstomy vérifie l'éligibilité retour ?
Qstomy branche intents ret_elig sur order Shopify, portail Loop et grille LATE-RET #364.
Capacités éligibilité retour
ret_elig_lookup : delivery_date + window + exclusions live
ret_elig_gate : RET-ELIG-GATE 7 gates déterministes
ret_elig_rma_deep_link : portail pré-rempli order
ret_elig_late_grille : LTV + days_over → exception ou refus
ret_elig_handoff : payload #364 ou #10 selon sortie
Scénario DTC chiffré
Marque mode, 620 retours/mois, 18 % tickets « suis-je éligible » avant RMA.
Après Qstomy ret_elig flows : 71 % auto-résolus, ret_elig_bot_resolution 79 %, ret_elig_false_promise 1,8 %, late_ret volume -22 %, CSAT 4,6/5.
Explorez support IA, Shopify, demander une démo.
Quelle checklist pour lancer le bot RET-ELIG ?
Checklist bot éligibilité (10 étapes)
Auditer tickets elig 90 j et tagger ret_elig_*
Documenter return_window + exclusions metafields
Sync delivery_date fulfillment webhook
Intégrer Loop/ReturnGO eligible API
Indexer RAG policy /retours + LATE-RET #364
Implémenter RET-ELIG-GATE section 4
Configurer router ret_elig_* intents
Rédiger prompt RET-ELIG-GUARD section 6
Tester 25 scénarios régression CI
Dashboard ret_elig_bot_resolution hebdo
En bref
#365 = bot éligibilité retour, pas parcours complet (#10) ni collecte motif (#138)
RET-ELIG-GATE : auth → SKU → date → holiday → late → sortie
12 intents ret_elig_* : check, late, final_sale, hygiene
Déterministe : LLM reformule, ne décide pas eligible
KPI ret_elig_bot_resolution : cible > 75 %
FAQ
Bot éligibilité = bot retour complet ?
Non. #365 vérifie règles avant RMA. #10 guide échange/remboursement post-éligibilité.
Différence avec préqualification #138 ?
#138 collecte motif et fiche handoff. #365 calcule eligible oui/non avec dates et exclusions.
Bot peut-il accorder exception hors délai ?
Seulement si grille LATE-RET #364 OK (LTV, days_over 1-3). Sinon handoff agent.
Produit final sale au portail ?
Bot ret_elig_final_sale refuse avec citation policy, pas lien RMA.
Comment tester parity portail ?
20 orders fixture mensuel : bot eligible = portail eligible 100 %.
Aller plus loin
Testez mystery shop : order J+28, vérifiez bot ret_elig_check cite deadline exacte + lien RMA. Order final_sale : refus sans lien.
Partagez ce guide #365 avec product et support : un bot éligibilité bien calibré évite RMA invalides et transforme le doute client en prochaine étape claire.
Enzo
2 août 2026
