E-commerce
17 juillet 2026
« Mon produit est en panne, c'est garanti ? » « L'extension que j'ai payée couvre la casse ? » « Quelles preuves envoyer pour la garantie ? » Ces questions arrivent quand le client mélange retour boutique, garantie légale 2 ans et extension checkout.
US Tech Automations estime qu'automatiser vérification éligibilité et communication statut warranty réduit le temps de traitement d'environ 70 % (US Tech Automations, warranty 2026).
Ce guide #349 formalise le chatbot IA garantie : expliquer couverture, exclusions et procédure sans promesse risquée. Il complète garantie (#62) (automation SAV) et extension (#348) avec l'angle cas d'usage IA clarifier warranty sans surpromesse.
Sommaire
Pourquoi automatiser les questions garantie par bot ?
Une promesse warranty bot non fondée coûte un remplacement injustifié ou un litige quand le claim est refusé. Le bot informe et route, il ne tranche pas seul un dossier complexe.
Volume tickets warranty
Sur électronique, électroménager et équipement sport, warranty figure dans le top 4 post-livraison. Chaque dossier mal qualifié coûte 15-25 min agent. Un bot qui explique régimes et collecte preuves filtre 50 à 65 % des tickets simples.
Trois risques sans bot warranty structuré
Surpromesse : « oui c'est garanti » sans vérifier éligibilité
Confusion régimes : retour, légale, extension mélangés
Handoff vide : agent repose les mêmes questions
Service-Public rappelle que la garantie légale de conformité couvre les défauts pendant 2 ans (Service-Public, garantie légale).
Angle #349
Le #62 automatise le workflow warranty SAV. Le #348 traite extension checkout ops. Le #349 définit le bot IA couverture, exclusions et procédure claim avec garde-fous anti-surpromesse.
Moment du parcours
Pré-achat : question couverture PDP. Post-achat : panne, éligibilité, dépôt claim, statut dossier.
Exemple DTC
Marque électroménager : 120 tickets warranty/mois, 45 % confusion régimes. Après bot warranty_* + policy grounded : 62 % auto-résolus, warranty_surpromise_incidents 0, CSAT warranty bot 4,5/5.
IA responsable
Le bot warranty dit « éligibilité probable, confirmation agent » ou « exclusion policy, voici pourquoi », jamais « remplacement garanti » sans dossier.
Coût surpromesse bot
Un bot qui promet remplacement avant validation coûte produit, extension remboursée et chargeback. Guardrails warranty protègent la marge autant que la conformité légale.
En quoi diffère-t-il des guides garantie et extension ?
Sept contenus voisins, sept rôles.
Automation garantie (#62)
Guide #62 : portail, collecte preuves, workflow SAV. Le #349 implémente la couche IA explication et triage.
Extension (#348)
Extension (#348) : policy EXT-WAR, claims extension checkout. Le #349 intègre ext_warranty dans matrice bot.
Diagnostic panne (#342)
Diagnostic (#342) : qualifie panne. Le #349 route warranty après failure qualifiée.
Réparation (#341)
Réparation (#341) : flux atelier. Le #349 distingue warranty repair vs payant.
Fausses promesses (#209)
Fausses promesses (#209) : délais et remboursements. Le #349 : promesses warranty bot.
Gouvernance IA (#124)
Gouvernance (#124) : cadre global. Le #349 applique guardrails warranty spécifiques.
Promesse #349
Intents warranty_*, matrice 3 régimes bot, anti-surpromesse, procédure claim, handoff payload, KPI warranty_bot_resolution.
Quels intents warranty le bot doit-il classifier ?
Cartographier les intents warranty bot avant flows.
Douze intents warranty
warranty_coverage_legal : garantie légale 2 ans
warranty_coverage_commercial : garantie constructeur
warranty_coverage_ext : extension checkout
warranty_eligibility : suis-je couvert pour cette panne ?
warranty_exclusion : choc, eau, usure couverts ?
warranty_procedure : comment déposer un claim
warranty_proofs : quelles pièces joindre
warranty_status : où en est mon dossier
warranty_vs_return : retour ou garantie
warranty_denied_appeal : claim refusé, recours
warranty_third_party : redirection assureur tiers
warranty_register : enregistrement produit garantie
Champs session obligatoires
order_id, purchase_date, sku, warranty_regime (legal/commercial/ext/none), failure_type, photos_received, eligibility_hypothesis, escalation_reason. Voir taxonomie (#135).
Mining tickets 90 j
Export « garantie », « warranty », « panne », « defectueux », « extension ». Prioriser flows sur 80 % volume par SKU.
Verbatims prioritaires
« C'est encore sous garantie ? », « choc mais ça marchait avant », « extension payée pourquoi refus », « quelle différence retour 30 j ». Quatre formulations couvrent 60 % tickets warranty DTC équipement.
Distinction warranty vs troubleshooting
Intent panne (#229) peut se résoudre sans claim. Bot route troubleshooting si usage/defaut incertain, warranty_eligibility si defect confirmé post-tests (#342).
Comment construire l'arbre warranty bot ?
L'arbre warranty bot mène de « en panne » à explication, procédure ou escalade.
Six gates séquentielles
Gate produit : order trouvée, SKU identifié
Gate régime : retour vs légale vs extension
Gate date : achat < 2 ans, extension active ?
Gate panne : defect vs usure vs exclusion
Gate preuves : photos, série, facture collectées
Gate sortie : info coverage, procédure claim, handoff
Branche warranty_vs_return
Achats < 30 j + changement d'avis → route retour policy. Défaut produit → warranty_eligibility. Bot ne mélange pas les deux.
Branche warranty_eligibility
Date achat + failure_type + exclusions policy → hypothesis eligible/excluded/uncertain. Uncertain = handoff agent, pas promesse bot.
Enchaînement #342 → #349
Diagnostic panne payload → warranty_eligibility avec failure_type connu. Gain temps agent et cohérence dossier.
Règle max tours
6-8 questions max avant handoff. Client demande humain : handoff avec payload partiel accepté.
Documentation arbre WAR-BOT
Chaque branche Notion : intent, gates, sortie bot, macro #62/#348 équivalente, payload handoff. Revue trimestrielle si nouvelle extension ou changement policy UE.
Branche warranty_exclusion
Client demande « choc couvert ? » : bot lit exclusions JSON, répond non + cite policy. Si client décrit choc + panne : exclusion + options repair payant.
Quelles sources de data le bot warranty lit-il ?
Le bot warranty répond depuis des sources policy vérifiables.
Cinq sources Shopify
Order date + line items : éligibilité temporelle
Metafield order.ext_warranty : extension active (#348)
Metafield product.warranty_policy : JSON couverture/exclusions
Page /garantie : chunks RAG policy officielle
Claim status API : statut dossier si portail
Matrice 3 régimes JSON
product.warranty_policy : {legal: true, commercial_years: 2, ext_sku: EXT-2Y, exclusions: [choc, eau, vol]}. Bot lit table, LLM reformule.
Policy extension #348
Si order.ext_warranty : bot cite conditions extension, route ext_warranty_third si assureur tiers.
Pas de RAG libre seul
Couverture = metafield + page garantie indexée. Pas génération LLM « probablement couvert ». Voir anti-hallucination.
Historique claim client
Si portail #62 : bot lit claim_id statut ouvert/fermé. Évite double dépôt claim et tickets statut répétitifs.
Numéro série et enregistrement
Metafield product.serial_required : bot demande série avant warranty_procedure si garantie commerciale constructeur l'exige.
Comment empêcher le bot de surpromettre la garantie ?
L'anti-surpromesse warranty est non négociable en e-commerce.
Cinq règles strictes
Pas de « remplacement garanti » sans dossier validé agent
Hypothesis only : « éligibilité probable » + confirmation
Exclusions citées : liste policy si question choc/eau
Pas décision refus : bot explique exclusion, agent tranche litige
Fallback : handoff si données insuffisantes
Prompt system warranty
« Tu n'approuves jamais un claim. Tu expliques couverture depuis policy. Tu collectes preuves pour handoff. Tu escalades si exclusion ambiguë ou client mécontent. » Voir system instructions (#310).
Formulations autorisées
« Sous garantie légale 2 ans, un défaut de conformité peut être couvert. Voici la procédure et preuves requises. » Interdit : « On vous remplace sans problème ».
Double validation claim
Bot collecte preuves puis propose « déposer claim portail ». Validation humaine ou système claim avant engagement remplacement. Séparation claire information bot vs décision SAV.
Tests régression
30 scénarios : eligible legal, exclusion choc, ext active, retour vs warranty, denied appeal, third party. warranty_surpromise_incidents cible 0.
Audit formulations bot
Revue hebdo 20 conversations warranty bot : aucune phrase « garanti », « remplacement assuré », « on va accepter ». Remplacer par « éligibilité à vérifier », « procédure claim ».
Alignement #209
Mêmes guardrails que fausses promesses délais : bot warranty = information policy, pas engagement commercial.
Quels flows bot pour warranty pré et post-achat ?
Le bot warranty intervient avant et après panne.
Flow PDP pré-achat
« Quelle garantie sur ce produit ? » → warranty_coverage_legal + commercial + lien extension option.
Flow post-panne
« Mon produit ne marche plus » → gate régime → collecte photos → warranty_procedure ou handoff (#62 portail).
Flow statut claim
warranty_status lit claim API ou demande numéro dossier → statut + prochaine étape. Réduit tickets « où en est ma garantie ? ».
Flow extension #348
order.ext_warranty détecté → warranty_coverage_ext + exclusions extension + route tiers si applicable.
Handoff payload warranty
order_id, sku, purchase_date, warranty_regime, failure_type, photos[], eligibility_hypothesis, tests_done (#342).
Exemple réponse bot
« Votre commande #4521 (achat 14/03/2025) est sous garantie légale jusqu'au 14/03/2027. Une panne mécanique sans choc peut être éligible. Exclusions : eau, chute, modification. Procédure claim : [lien]. Preuves : photo panne + numéro série. »
Flow WhatsApp / Instagram
Client envoie photo panne : bot collecte order email ou numéro, identifie SKU, lance warranty_eligibility. Limiter promesse si photo seule sans contexte choc/eau.
Messages proactifs J+400
Rappel « garantie légale encore 335 j » avec lien procédure si produit électroménager. Réduit tickets « je savais pas que j'avais encore garantie ».
Comment brancher le bot warranty sur Shopify ?
Le setup bot warranty Shopify aligne order data et policy.
Checklist technique
Créer metafield product.warranty_policy JSON
Synchroniser order.ext_warranty (#348)
Indexer page /garantie RAG
Configurer intents warranty_* arbre section 4
Rédiger prompt anti-surpromesse section 6
Connecter claim status API si portail #62
Tester 30 scénarios régression
Widget compte client
« Problème produit / garantie » avec order_id pré-rempli.
Intégration diagnostic #342
Payload failure_diagnosis → intent warranty_eligibility automatique.
Lancement progressif
Phase 1 : warranty_coverage + procedure top SKU. Phase 2 : eligibility + status. Phase 3 : ext + third party.
Shopify Flow sync
Order tag warranty_claim_opened quand client démarre claim portail #62. Bot warranty_status lit tag + API pour réponse statut cohérente agents et client.
Quels KPI mesurer sur le bot warranty ?
Sans KPI bot warranty, impossible de détecter surpromesses et mauvais routage.
Sept métriques clés
warranty_bot_resolution : résolu sans agent / tickets warranty bot
warranty_escalation_rate : handoffs / sessions warranty
warranty_surpromise_incidents : promesses bot contestées
warranty_regime_confusion : tickets régimes mélangés
warranty_claim_start_rate : claims initiés post-bot
time_to_warranty_handoff : collecte preuves → agent
CSAT intent warranty_bot : satisfaction post-réponse
Benchmark DTC
Objectif warranty_bot_resolution > 55 %, warranty_surpromise_incidents 0, warranty_regime_confusion < 15 %, CSAT warranty bot > 4,4/5.
Revue mensuelle
Top escalation_reason : enrichir policy ou flows. Corréler warranty_denied_appeal avec formulations bot.
Corrélation NPS warranty
Segment clients ticket warranty post-bot : NPS +12 pts si procédure claire même en refus exclusion documenté. NPS -25 pts si surpromesse bot contestée.
Quels cas limites et escalades prévoir ?
Cinq edge cases warranty bot exigent escalade immédiate.
Panne + choc avoué
Exclusion standard. Bot cite policy, pas eligibility favorable. Escalade si client conteste.
Hors garantie légale sans extension
Bot explique options : repair payant (#341), spare (#343), pas fausse promesse warranty.
Extension tiers (#348)
warranty_third_party : URL portail assureur, bot ne tranche pas couverture extension.
Claim refusé contesté
warranty_denied_appeal : handoff warranty manager, pas réouverture bot loop.
B2B compte pro
Garantie contractuelle distincte. Handoff compte B2B, pas policy B2C bot.
Client menace chargeback
Escalade prioritaire avec payload complet. Bot reste factuel, empathique, sans promesse.
Produit acheté marketplace
Bot vérifie canal achat : warranty boutique seulement si order Shopify directe. Marketplace tiers : handoff policy marketplace, pas warranty_policy DTC.
Comment Qstomy gère les questions garantie ?
Qstomy traite les intents warranty_* depuis order Shopify, warranty_policy et ext_warranty.
Capacités
warranty_coverage : matrice 3 régimes expliquée
warranty_eligibility : hypothesis + preuves
warranty_procedure : lien portail claim #62
warranty_status : statut dossier si API
Handoff payload : dossier warranty structuré
Scénario DTC chiffré
Marque électronique, 120 tickets warranty/mois, confusion régimes.
Après Qstomy warranty bot : 61 % auto-résolus, warranty_regime_confusion 11 %, warranty_surpromise 0, CSAT warranty bot 4,6/5, temps agent warranty -52 %.
Le bot informe et collecte ; l'agent tranche litiges eligibility et denied appeal avec dossier photos et hypothesis pré-remplis.
Explorez support IA, Shopify, demander une démo.
Quelle checklist pour lancer le bot warranty ?
Checklist bot warranty (10 étapes)
Auditer tickets warranty 90 j (#62, #348)
Documenter matrice 3 régimes policy
Renseigner product.warranty_policy metafields
Configurer intents warranty_* arbre section 4
Rédiger prompt anti-surpromesse section 6
Brancher order.ext_warranty et claim API
Tester 30 scénarios régression
Intégrer payload diagnostic #342
Dashboard warranty_bot_resolution hebdo
Revue mensuelle surpromesse et escalation
En bref
#349 = bot warranty IA, pas workflow SAV (#62)
Informer, pas approuver : hypothesis + handoff
12 intents warranty_* : coverage, eligibility, procedure
Anti-surpromesse : 0 remplacement garanti bot
KPI warranty_bot_resolution : cible > 55 %
FAQ
Différence avec garantie #62 ?
#62 = portail et workflow SAV. #349 = bot explique couverture et route sans approuver claim.
Bot peut-il refuser un claim ?
Bot explique exclusion policy. Décision refus = agent ou système claim, pas bot seul.
Lien extension #348 ?
Bot lit order.ext_warranty et cite conditions extension + route tiers.
Diagnostic #342 obligatoire ?
Recommandé : payload failure accélère warranty_eligibility et handoff.
Que faire si policy absente ?
Escalade agent. Pas réponse LLM générique sur couverture.
Formation agents post-bot
Agents reçoivent dossiers warranty pré-qualifiés : régime identifié, photos jointes, hypothesis bot. Focus agent = trancher litige, pas reposer questions initiales.
Aller plus loin
Testez dix scénarios warranty staging : legal eligible, exclusion choc, ext active, retour vs warranty, policy absente.
Partagez ce guide #349 avec legal et SAV : un bot warranty sans policy grounded = risque surpromesse maximal.
Synchronisez product.warranty_policy à chaque changement extension ou fournisseur : policy stale = escalades massives et warranty_regime_confusion en hausse.
Intégrez le lien procédure warranty dans l'email post-achat pour les SKU électroménager et électronique à garantie longue durée.
Enzo
17 juillet 2026
