E-commerce
30 juillet 2026
« Mon colis est cassé, l'assurance couvre ? » « Comment déposer une réclamation Route ? » « J'ai payé la protection, pourquoi on me renvoie vers la garantie ? » Trois messages où un bot générique confond sinistre transport, garantie produit et retard express.
Route indique que sa protection couvre colis perdus, volés ou endommagés en transit, avec réclamation via Resolve Center sous 30 jours (Route, policies 2026). Onward estime qu'une automatisation claims self-serve peut réduire de 30 à 40 % les tickets livraison sinistre (Onward, protection Shopify 2026).
Ce guide #362 formalise le chatbot IA assurance livraison : expliquer couverture, exclusions et démarche. Il complète support assurance (#361) (policy SHIP-INS ops) avec l'angle cas d'usage IA : lookup protection, FAQ couverture, redirect claim et triage warranty.
Sommaire
Pourquoi automatiser l'assurance livraison par bot ?
Un bot assurance livraison répond sur couverture, exclusions et lien réclamation. Il ne rembourse pas seul : il route vers Resolve Center ou handoff agent selon policy SHIP-INS (#361).
Trois échecs bot générique
Promesse remboursement : bot garantit refund sans lookup protection
Confusion garantie : colis intact, bot ouvre dossier assurance
Retard = sinistre : express late traité comme claim couvert
Route précise que les retards express non dommage ne sont pas couverts (Route, exclusions 2026).
Angle #362
Le #361 documente macros SHIP-INS et flow INS-CLAIM humain. Le #362 implémente la couche bot intents ins_bot_* : coverage FAQ, claim redirect, warranty triage, photo collect.
ROI ins bot
Sur marque Route 42 % adoption, 67 tickets insurance/mois : bot ciblé 70 à 80 % auto-résolus vs 20 % bot WISMO générique.
Exemple DTC
Marque déco, 71 tickets ins/mois. Après bot INS-BOT : ins_bot_resolution 79 %, ins_wrong_routing_warranty 4 %, temps réponse 35 s, CSAT sinistre bot 4,6/5.
Moment du parcours
Post-livraison : colis cassé, volé, tracking bloqué. Pre-achat : « c'est quoi la protection checkout ? » Trigger : assurance, Route, protection colis, réclamation.
Prérequis ops
Policy SHIP-INS (#361) publiée. Metafield route_protected sur order. Bot cite policy RAG, pas invente couverture.
Pourquoi bot dédié assurance
Coupler au bot WISMO dilue la précision : client « colis cassé » reçoit tracking update. Router ins_bot_* évite mismatch et applique garde-fous sinistre spécifiques.
Volume et saisonnalité
Tickets assurance pic novembre-janvier (vol colis) et juin-août (absences livraison). Bot ins_bot_coverage pré-achat lisse questions checkout en pic conversion.
Coût promesse refund bot
Un bot qui promet remboursement avant approbation Route crée double paiement ou chargeback. INS-BOT-GUARD interdit toute promesse financière : lien claim ou handoff uniquement.
Adoption protection et bot
Route vise 40 à 50 % opt-in selon vertical. Le bot ins_bot_coverage pré-achat répond aux hésitations sans alourdir le panier : le client comprend la valeur avant de cocher la protection.
En quoi diffère-t-il du support #361 et du warranty #349 ?
Sept contenus livraison sinistre, sept rôles bot distincts.
Support assurance (#361)
Guide #361 : policy SHIP-INS, macros SHIP-INS-*. Le #362 = automation bot lookup + redirect claim.
Colis endommagé (#363)
Le futur support colis endommagé (#363) : photos, remplacement ops humain. Le #362 couvre éligibilité assurance et lien claim avant workflow #363.
Bot warranty (#349)
Bot warranty (#349) : défaut produit. Le #362 handoff si colis intact via ins_bot_warranty_triage.
Express (#338)
Express (#338) : retards cut-off. Le #362 : ins_bot_express_delay, exclusion assurance.
Bot WISMO (#184)
Bot WISMO (#184) : tracking. Le #362 = sous-intent sinistre post-livraison, pas statut transit seul.
Split (#357)
Bot split (#357) : multi-colis. Le #362 gère sinistre sur colis N spécifique.
Retours post-sinistre
Bot retours intervient après résolution claim. Le #362 ne crée pas RMA : il qualifie sinistre et envoie vers claim ou warranty d'abord.
Promesse #362
Intents ins_bot_*, flow INS-BOT-GATE, garde-fous INS-BOT-GUARD, handoff #361/#363, KPI ins_bot.
Quels intents ins_bot le bot doit-il classifier ?
Cartographier les intents ins_bot avant flows. Scope : expliquer et router, pas approuver claim.
Dix intents assurance bot
ins_bot_coverage : qu'est-ce qui est couvert ?
ins_bot_exclusion : retard, mauvais article, qualité
ins_bot_claim_link : déposer réclamation Route
ins_bot_not_protected : pas souscrit checkout
ins_bot_lost : colis perdu tracking
ins_bot_stolen : vol après livraison
ins_bot_damaged : colis cassé réception
ins_bot_warranty_triage : redirect garantie si intact
ins_bot_express_delay : retard non couvert
ins_bot_denied_handoff : claim refusé, escalade
Champs session obligatoires
order_id, route_protected, carrier, tracking_status, delivery_date, sinistre_type, photos_uploaded (bool). Voir taxonomie (#135).
Router parent
« assurance », « Route », « protection », « réclamation », « colis cassé couvert » → ins_bot_* (#362). « Où est mon colis » sans sinistre → WISMO (#184).
Mining tickets 90 j
Export tags insurance #361. Prioriser flows top verbatims avant intégration API Route.
Priorisation MVP
Semaine 1 : ins_bot_coverage + ins_bot_claim_link. Semaine 2 : ins_bot_damaged + ins_bot_warranty_triage. Semaine 3 : ins_bot_not_protected + handoff.
Comment construire le flow INS-BOT-GATE ?
Le flow INS-BOT-GATE route chaque message via lookup protection avant réponse sinistre.
Six gates séquentielles
Gate auth : email + order_id
Gate protection : route_protected oui/non
Gate intent : coverage vs sinistre vs exclusion
Gate sinistre type : lost / stolen / damaged / delay
Gate délai : 30 j OK ou handoff denied
Gate sortie : FAQ, claim link, photo collect, handoff
Branche ins_bot_claim_link
Si route_protected=true : lien Resolve Center + rappel délai 30 j + preuves photos. Si false : ins_bot_not_protected + options carrier (#361 SHIP-INS-NOPROTECT).
Branche ins_bot_damaged
Collecte photos emballage avant redirect claim. Si intact produit mentionné → ins_bot_warranty_triage.
Branche ins_bot_express_delay
Citation exclusion Route retard intact. Lien express (#338) si demande remboursement port.
Max tours
3 clarifications max. Puis handoff agent avec payload sinistre.
Checklist photos bot
Avant ins_bot_claim_link sur damaged : bot demande confirmation 3 photos (emballage extérieur, intérieur, produit + étiquette carrier). Session flag photos_acknowledged=true avant envoi lien Resolve.
Quelles sources de data le bot assurance lit-il ?
Le bot assurance lit Shopify order + Route protection flag + policy SHIP-INS RAG.
Cinq sources Shopify
Order API : payment, fulfillment, tags gift
Metafield route_protected : protection active
Tracking carrier : delivered_at, status
Premium amount : line item protection
Resolve Center URL : par order Route
Route documente le process claims merchant portal (Route, claims 2026).
Policy RAG #361
Chunks SHIP-INS couverture, exclusions, délais, preuves. Bot cite policy, pas surpromesse.
Apps alternatives
Onward, ShipProtect : adapter claim URL selon protection_provider metafield.
Cache protection status
Refresh à chaque session ins_bot. Route ne permet pas ajout post-achat (Route, FAQ 2026).
Sync checkout opt-in
Webhook order/create tag route_protected si line item protection présent. Bot lit flag en session sans delay pour éviter faux ins_bot_not_protected sur commandes récentes.
Quels garde-fous imposer au bot assurance ?
Les garde-fous INS-BOT-GUARD évitent remboursement promis et mauvais routing.
Cinq règles strictes
Pas remboursement bot : redirect claim ou handoff agent
Auth avant sinistre : order_id + email obligatoires
Warranty triage : intact → #349, pas claim
Retard ≠ couvert : express delay exclusion explicite
Photos damage : checklist avant claim link
Prompt system ins bot
« Tu expliques couverture assurance colis selon policy SHIP-INS. Tu ne promets jamais remboursement. Si route_protected, tu envoies lien Resolve Center. Si colis intact et produit défectueux, tu redirect garantie. » Voir anti-hallucination.
Réponse type ins_bot_coverage
« Votre commande #7842 inclut la protection livraison. Couvert : perte transit, vol signalé, casse à réception. Non couvert : retard seul, mauvais article, défaut produit hors transport. Réclamation : [lien] sous 30 jours. »
Tests régression
25 scénarios : protected claim, not protected, damaged photos, warranty redirect, express delay, stolen, lost, denied handoff, gift, split colis 2. ins_bot_hallucination cible 0 %.
Logging audit
Log order_id, route_protected, intent, claim_link_sent. Audit mensuel 10 sessions : vérifier aucune promesse refund bot.
Seuil valeur haute
Orders > 500 € : bot stop auto claim link, handoff agent supervisor même si protected. Évite litige complexe sur bot seul.
Quels flows bot pour sinistres et FAQ assurance ?
Le bot assurance intervient sur points de contact sinistre et pré-achat FAQ.
Flow chat colis cassé
Auth → ins_bot_damaged → checklist photos → ins_bot_claim_link si protected.
Flow checkout widget FAQ
« Protection colis » pre-achat : ins_bot_coverage + ins_bot_exclusion sans order lookup.
Flow tracking page
Bouton « Problème livraison ? » → router ins_bot si delivered, WISMO si in_transit.
Flow email sinistre
Lien chat pré-rempli order_id. Bot reprend protection status sans redemander.
Flow claim denied
Client conteste refus Route → ins_bot_denied_handoff supervisor payload claim_id.
Flow ins_bot_not_protected
Bot explique options : dossier transporteur (délai 15-30 j), geste commercial selon grille #361, pas lien Resolve. Collecte photos si damaged. Handoff agent si client insiste remboursement immédiat.
Handoff payload ins bot
order_id, route_protected, sinistre_type, photos_collected, claim_link_sent, session_log, handoff_reason.
Proactif post-livraison
Si delivered + protected : message 24 h « Problème colis ? Déposez réclamation ici ». Réduit ins_bot_claim_howto tickets.
Comment brancher le bot assurance sur Shopify ?
Le setup bot assurance Shopify connecte Route, router intents et RAG SHIP-INS.
Checklist technique
Installer Route ou app protection (Shopify App Store)
Sync metafield route_protected webhook order
Indexer policy SHIP-INS #361 RAG
Configurer router ins_bot_* mots-clés
Rédiger prompt INS-BOT-GUARD section 6
Brancher Resolve Center URL API ou template
Tester 25 scénarios régression
Dashboard ins_bot_resolution hebdo
Intégration helpdesk
Handoff payload visible sidebar : protection oui/non, sinistre type, photos OK.
Lancement progressif
Phase 1 : coverage + claim link. Phase 2 : damaged + warranty triage. Phase 3 : not protected + denied handoff.
Fallback sans Route
Bot ins_bot_coverage depuis policy merchant self-insured. ins_bot_claim_link → formulaire SAV #361, pas Resolve.
Quels KPI mesurer sur le bot assurance ?
Sans KPI ins_bot, impossible de prouver ROI vs macros #361 seules.
Sept métriques clés
ins_bot_resolution : résolu sans agent / sessions ins bot
ins_bot_deflection : tickets insurance évités / sessions
ins_claim_link_sent_rate : protected + lien / ins_bot_claim
ins_warranty_redirect_rate : triage OK / damaged intents
ins_bot_handoff_rate : escalades / sessions
ins_bot_hallucination_rate : promesses refund bot
CSAT intent ins_bot : satisfaction sinistre bot
Benchmark DTC
Objectif ins_bot_resolution > 75 %, ins_warranty_redirect_rate > 90 % sur intact mentions, CSAT > 4,5/5.
Corrélation #361
insurance_support_volume humain doit baisser 40 %+ post-bot sur intents coverage et claim howto.
Revue mensuelle
Top handoff reasons, top sinistre type, ajuster RAG exclusions.
Dashboard segmenté
Séparer ins_bot_coverage CSAT vs ins_bot_damaged : un intent faible guide enrichissement checklist photos ou RAG exclusion.
Test A/B widget checkout
Mesurer ins_bot_deflection avec FAQ protection inline chat vs sans widget. Marques adoption Route < 35 % gagnent souvent 0,3 point conversion quand le bot répond couverture avant hésitation opt-in.
Quels cas limites et escalades prévoir ?
Sept edge cases ins bot exigent handoff ou procédure spéciale.
Split colis 2 endommagé
Sinistre sur tracking colis 2. Vérifier protection couvre commande. Lien bot split (#357).
Cadeau destinataire sinistre
Destinataire contacte : vérifier acheteur protected. Policy gift claim selon #361, pas envoi lien sans auth acheteur si requis.
Claim hors 30 j
Bot cite exclusion délai. Handoff supervisor si montant > seuil et circonstances atténuantes.
Client menace chargeback
Priorité P1, claim link si protected, supervisor si not protected.
International customs damage
Vérifier exclusion policy Route international. Handoff ops si doute couverture.
Multi-sinistre repeat client
3+ claims 90 j : handoff fraud review, pas auto claim link.
Produit haute valeur > seuil
Montant order > 500 € : handoff agent même si protected, pas bot seul.
Mauvais article reçu
Colis intact mais SKU incorrect : ins_bot_exclusion, pas claim assurance. Router vers retour échange ou SAV produit, pas Resolve Center. Confusion fréquente post-sinistre où le client mélange dommage transport et erreur picking entrepôt.
Client insiste sur remboursement immédiat
Bot ne promet jamais remboursement instantané. Message : délai traitement assureur 5 à 10 jours ouvrés après dossier complet. Handoff si menace chargeback ou avis négatif public.
Comment Qstomy gère l'assurance livraison ?
Qstomy route les intents ins_bot_* depuis order API, route_protected et policy SHIP-INS RAG.
Capacités
ins_protection_lookup : Route oui/non + premium
ins_coverage_faq : couvert vs exclusions policy
ins_claim_redirect : Resolve Center URL
ins_damage_photo_checklist : collecte avant claim
ins_warranty_triage : handoff #349 si intact
Scénario DTC chiffré
Marque mobilier, 64 tickets ins/mois, bot WISMO générique confondait sinistre et tracking.
Après Qstomy ins bot : 77 % auto-résolus, ins_bot_resolution 81 %, ins_bot_handoff_rate 14 %, CSAT 4,7/5.
Explorez support IA, Shopify, demander une démo.
Quelle checklist pour lancer le bot assurance ?
Checklist bot assurance (10 étapes)
Valider policy SHIP-INS #361
Auditer tickets insurance 90 j
Connecter route_protected metafield
Indexer RAG couverture exclusions
Documenter flow INS-BOT-GATE section 4
Configurer router ins_bot_* intents
Rédiger prompt INS-BOT-GUARD section 6
Tester 25 scénarios régression
Intégrer handoff #361 et #363
Dashboard ins_bot_resolution hebdo
En bref
#362 = bot assurance livraison, pas support ops seul (#361)
INS-BOT-GATE : auth → protection → sinistre → claim link
10 intents ins_bot_* : coverage, claim, damaged, warranty
Pas remboursement bot : redirect Resolve ou handoff
KPI ins_bot_resolution : cible > 75 %
FAQ
Différence avec #361 ?
#361 = macros agents SHIP-INS. #362 = automation bot couverture et claim.
Bot approuve les claims ?
Non. Route ou agent approuve. Bot envoie lien et checklist preuves.
Colis intact produit cassé ?
ins_bot_warranty_triage → garantie #349, pas assurance.
Retard express couvert ?
Non si colis intact. ins_bot_express_delay + lien #338.
Sans Route installé ?
Bot FAQ policy merchant + handoff formulaire SAV #361.
Aller plus loin
Testez staging : commande Route protected, message « colis cassé couvert ? », vérifiez coverage FAQ + claim link sans promesse refund.
Partagez ce guide #362 avec ops et CRM : un bot assurance bien calibré transforme le sinistre en démarche 30 secondes, pas en dispute garantie.
Enzo
30 juillet 2026
