E-commerce
10 juillet 2026
« Mon produit est en panne. » « Ça ne marche plus depuis hier. » « Je veux parler à quelqu'un maintenant. » Le client arrive frustré. L'agent reçoit un ticket vide : pas de SKU, pas de symptôme, pas de test déjà fait.
VSight cite Accenture : environ 68 % des retours électronique sont No Trouble Found, souvent faute de diagnostic structuré avant escalade (VSight, visual support 2026).
Ce guide #342 formalise le chatbot IA diagnostic de panne : qualifier la failure, tester les causes courantes, puis transférer au SAV avec un dossier complet. Il complète troubleshooting (#229) (résolution autonome) avec l'angle panne, qualification et handoff agent structuré.
Sommaire
Pourquoi qualifier la panne avant transfert SAV ?
Transférer immédiatement « en panne » à un agent coûte cher et frustre les deux parties. L'agent repose les mêmes questions que le bot aurait pu poser.
Trois coûts du handoff brut
Temps agent : 8-15 min de qualification avant action
Retours NTF : produit renvoyé sans défaut réel
CSAT : client répète son histoire trois fois
Le framework DQA (ACL 2026) montre qu'un diagnostic avec état persistant atteint 78,7 % de résolution vs 41,3 % sans état structuré (ACL Anthology, DQA 2026).
Angle #342
Le #229 mène l'arbre troubleshooting jusqu'à résolution. Le #342 optimise la phase qualification panne et le payload handoff quand l'agent prend le relais.
Moment du parcours
Post-achat J+1 à J+730. Client signale dysfonctionnement. Bot qualifie avant file SAV, repair (#341) ou garantie (#62).
Exemple DTC
Marque audio portable : 220 tickets « panne »/mois, handoff direct 85 %. Après bot failure_diagnosis + payload : handoff qualifié 100 %, temps agent -42 %, retours NTF -28 %.
Boucle valeur
Bot qualifie → agent agit vite → client satisfait → moins de repeat contact. Sans qualification, l'agent devient collecteur d'infos, pas résolveur.
En quoi diffère-t-il du troubleshooting et du triage SAV ?
Six contenus voisins, six rôles.
Troubleshooting (#229)
Guide #229 : arbres TRB-*, résolution autonome. Le #342 focus qualification panne + handoff quand résolution bot impossible ou client demande humain.
Triage SAV (#236)
Triage (#236) : urgence, intent global, canal. Le #342 approfondit failure_type et symptômes pour dossiers produit défectueux.
Réparation (#341)
Réparation (#341) : flux atelier ops. Le #342 qualifie avant d'ouvrir dossier repair.
Garantie (#62)
Garantie (#62) : éligibilité warranty. Le #342 distingue usage vs défaut avant routing garantie.
Handoff (#12, #155)
Handoff (#12) et contexte (#155) : règles générales. Le #342 définit le payload failure_diagnosis spécifique.
Promesse #342
Intents failure_*, arbre qualification, payload handoff, routing repair/warranty/return, KPI NTF.
Complémentarité #229
#229 et #342 partagent les arbres symptômes. #229 vise la résolution bot autonome. #342 vise le dossier agent quand résolution impossible ou client exige humain après qualification structurée.
Quels intents failure le bot doit-il classifier ?
Cartographier les intents diagnostic panne avant construction des arbres FAIL.
Dix intents failure post-achat
fail_power : ne s'allume plus, voyant absent
fail_intermittent : fonctionne parfois, coupe aléatoire
fail_performance : moins efficace, bruit anormal
fail_connectivity : app, Wi-Fi, Bluetooth
fail_error_code : code affiché écran
fail_physical_damage : choc, casse visible
fail_leak_smell : fuite, odeur, surchauffe (escalade rapide)
fail_usage : mauvais réglage, attente irréaliste
fail_missing_part : pièce absente colis
fail_warranty_defect : défaut confirmé post-tests
Champs qualification obligatoires
SKU, date achat, symptôme verbatim, tests effectués, hypothèse bot (usage/defect/unknown), photos demandées ou reçues. Voir taxonomie (#135).
Mining tickets 90 j
Export « panne », « cassé », « defectueux », « ne marche plus ». Regrouper par SKU top 20. Prioriser arbres FAIL sur 80 % volume.
Verbatims prioritaires
« Ne démarre plus », « code erreur E03 », « Bluetooth ne se connecte plus », « odeur bizarre », « pièce manquante dans le colis ». Cinq formulations couvrent 65 % des tickets panne DTC électronique et électroménager.
Comment construire l'arbre de qualification panne ?
L'arbre qualification failure mène de « en panne » à une sortie routée.
Cinq gates séquentielles
Gate produit : SKU identifié, commande trouvée
Gate sécurité : fuite, odeur, surchauffe → escalade immédiate
Gate usage : tests basiques (alimentation, mode, reset)
Gate symptôme : branche fail_* selon réponses
Gate sortie : resolved, handoff_agent, repair, warranty, return
État diagnostic persistant
JSON session : {sku, symptom, tests_done[], hypothesis, confidence, photos[]}. LLM reformule, arbre décide. Voir anti-hallucination.
Règle max tours
6-8 questions max avant handoff si non résolu. Client demande humain à tout moment : handoff avec payload partiel accepté.
Branche fail_power (exemple)
Câble branché ? Voyant ? Autre prise testée ? Batterie chargée 2 h ? Reset 10 s bouton ? Si tout OK → fail_warranty_defect probable → handoff garantie.
Branche fail_connectivity
App installée ? Bluetooth activé ? Appareil en mode pairing ? Distance < 3 m ? Reset appareil + réinit app ? Si échec → fail_warranty_defect ou handoff expert selon âge produit.
Documentation arbre
Chaque branche FAIL documentée en Notion : questions, réponses attendues, sortie, lien guide usage. Mise à jour quand nouveau firmware ou recall SKU.
Table codes erreur
Metafield SKU error_codes JSON : E01=batterie, E03=moteur bloqué. Bot lit table si fail_error_code, pas LLM qui invente la signification du code.
Quel payload transmettre à l'agent SAV ?
Le payload handoff failure évite que l'agent reparte de zéro.
Douze champs minimum
order_id et sku
purchase_date et warranty_status
symptom_verbatim : citation client
failure_intent : fail_power, fail_connectivity, etc.
tests_completed : liste checks bot
hypothesis : usage_error, likely_defect, unknown
confidence : 0-1
photos_urls : si uploadées
recommended_route : repair, warranty, return, expert
bot_resolution_attempted : oui/non
customer_sentiment : neutral, frustrated, angry
transcript_summary : 5 lignes max
Affichage agent
Sidebar helpdesk : bloc « Diagnostic bot » lisible en 10 s. Agent valide ou corrige hypothesis avant action. Aligner transfert contexte (#155).
Routing automatique
recommended_route=repair → file atelier. warranty → file garantie. return → bot retour (#returns). expert → file tier 2 produit.
Exemple payload réel
order_id #4521, SKU robot-mix-200, fail_power, tests : câble OK, reset fait, hypothesis likely_defect, confidence 0,82, recommended_route warranty, 2 photos jointes. Agent ouvre ticket garantie sans reposer 8 questions.
Intégration helpdesk
Gorgias, Zendesk ou Recharge : custom fields mappés depuis payload JSON. Webhook bot → ticket créé avec champs pré-remplis avant assignation agent.
Quels flows bot selon le type de panne ?
Adapter le flow diagnostic panne au vertical produit.
Flow électronique (fail_power, fail_connectivity)
Reset, firmware, pairing, câble, charge. Table codes erreur si fail_error_code. Lien électronique (#148).
Flow petit électroménager
Sécurité blocage, calage, mode, nettoyage filtre. Escalade fail_leak_smell immédiate. Photos obligatoires avant handoff.
Flow mode / textile
Souvent fail_usage ou fail_physical_damage. Distinction usure vs défaut couture. Routing return si changement d'avis.
Flow cosmétique / alimentaire
fail_performance (texture, goût) vs fail_leak_smell. Escalade qualité si lot suspect. Lien rappel produit si pattern.
Client demande humain
« Je veux un agent » : handoff immédiat avec payload partiel + tag customer_requested_human.
Multilingue
Arbre FAIL identique toutes langues. Payload en langue agent (FR) + verbatim client original. Voir bot multilingue.
Comment router vers réparation, garantie ou retour ?
La matrice routing failure décide la sortie après qualification.
Quatre sorties principales
resolved_bot : usage corrigé, produit OK
route_warranty : défaut probable, sous garantie
route_repair : réparable, hors garantie ou policy repair
route_return : retour RMA, échange ou remboursement
Matrice décision
hypothesis=usage_error → resolved_bot ou guide usage. likely_defect + warranty_active → route_warranty (#62). likely_defect + repair_eligible → route_repair (#341). physical_damage transit → route_return prioritaire.
Macro bot sortie
« D'après nos tests, votre [SKU] présente [symptôme]. Nous vous orientons vers [garantie/réparation/retour]. Un agent va reprendre avec votre dossier pré-rempli. »
Pré-qualification retour
Si route_return : bot collecte raison RMA avant étiquette. Voir pré-qualification retour.
Cas fail_usage résolu
Client pensait produit en panne, mauvais mode sélectionné. Bot résout, tag fail_usage_resolved. Pas de handoff. CSAT micro-survey « Problème résolu ? » après 2 min.
Quelles règles d'escalade immédiate ?
Certains signaux failure P0 bypassent l'arbre complet.
Six triggers escalade immédiate
fail_leak_smell : fuite, odeur brûlé, fumée
Chargeback menacé ou avocat cité
VIP ou panier > seuil selon policy
Repeat contact 3+ même panne 7 j
Sentiment angry score > seuil
Produit dangereux : batterie gonflée, électrocution
SLA handoff P0
Agent live < 2 min chat, < 15 min email. Payload minimal : symptom + sku + urgence. Compléter diagnostic en parallèle si agent disponible.
Post-mortem litige
Si client insatisfait post-handoff : revue payload. Champs manquants ? Mauvaise hypothesis ? Boucle amélioration arbre FAIL chaque mois.
Alignement matrice escalade
Croiser matrice escalade (#193) et triage (#236) urgency P0-P3.
Formation agents
Agents formés à lire bloc diagnostic bot en 15 s. Ne jamais demander « avez-vous essayé de redémarrer » si tests_completed liste reset.
Quels KPI mesurer pour le diagnostic panne bot ?
Mesurer la qualité qualification failure, pas seulement le taux de handoff.
Six métriques clés
failure_bot_resolution_rate : résolu sans agent / total fail_*
handoff_payload_complete_rate : payload 10+ champs / handoffs
agent_time_saved : min agent avec vs sans payload
ntf_return_rate : retours No Trouble Found / retours panne
misroute_rate : mauvaise file repair/warranty/return
CSAT post-handoff : satisfaction après transfert qualifié
Benchmark DTC
Objectif handoff_payload_complete > 85 %, ntf_return_rate < 25 %, agent_time_saved > 8 min/ticket panne.
Revue hebdo SKU
Top 5 SKU fail_* : ajuster arbres, ajouter codes erreur, enrichir guide si fail_usage récurrent.
A/B handoff
Groupe A : handoff sans payload. Groupe B : payload complet. Mesurer agent_handle_time et CSAT 30 j. Écart attendu 8-12 min gagnés groupe B.
Quelles erreurs éviter avec un bot diagnostic panne ?
Cinq anti-patterns failure bot à bannir.
Erreur 1 : handoff sans payload
« Transfert agent » sans contexte = double frustration. Fix : payload section 5 obligatoire.
Erreur 2 : promettre remplacement
Bot ne promet pas refund ou échange. Il qualifie et route. Humain tranche garantie.
Erreur 3 : ignorer sécurité
fail_leak_smell = P0 immédiat. Pas 6 questions sur le mode d'emploi.
Erreur 4 : arbre identique tous SKU
Casque audio et robot cuisine ≠ mêmes tests. Arbres par famille produit.
Erreur 5 : bloquer humain
Client insiste pour agent : handoff en 1 clic avec payload partiel. Voir limites bot (#124).
Boucle feedback produit
Top 3 fail_* récurrents même SKU → alerte produit/qualité. Diagnostic bot devient source insights défauts usine, pas seulement SAV.
Tests CI bot
30 scénarios fail_* : assert hypothesis, recommended_route et payload_complete. Regression test à chaque mise à jour doc firmware ou lancement nouveau SKU.
Comment Qstomy qualifie la panne avant transfert SAV ?
Qstomy exécute l'arbre failure_diagnosis, construit le payload handoff et route vers repair, warranty ou return.
Capacités
Intent fail_* : classification symptôme
Arbre multi-tours : état persistant, max 8 questions
Collecte photos : upload avant handoff defect
Payload handoff : 12 champs sidebar agent
Routing : warranty, repair (#341), return
Scénario DTC chiffré
Marque petit électroménager, 180 tickets fail_*/mois, handoff brut 90 %.
Après Qstomy failure_diagnosis : 38 % résolus bot, handoff_payload_complete 91 %, agent_time_saved 11 min, ntf_return_rate -26 %, CSAT post-handoff 4,4/5.
Le bot ne remplace pas l'expert produit : il filtre usage, qualifie defect et remplit le dossier pour que l'humain tranche garantie ou repair en minutes, pas en heures.
Explorez support IA, Shopify, demander une démo.
Quelle checklist pour lancer le bot diagnostic panne ?
Checklist failure bot (10 étapes)
Miner tickets panne 90 j, top intents par SKU
Cartographier 10 intents fail_* section 3
Construire arbres FAIL top 5 SKU (section 4)
Définir payload handoff 12 champs section 5
Configurer routing warranty/repair/return section 7
Triggers P0 section 8 en live
Sidebar agent helpdesk avec bloc diagnostic
Tester 20 scénarios fail_power, fail_connectivity, fail_leak
Activer KPI ntf_return_rate et payload_complete
Revue hebdo arbres vs tickets mal routés
En bref
#342 = qualification panne + handoff, pas troubleshooting seul (#229)
Payload 12 champs : agent ne repart pas de zéro
Arbre FAIL : 5 gates, état persistant
Routing : warranty, repair, return selon hypothesis
KPI NTF : moins de retours sans défaut réel confirmé
FAQ
Différence avec troubleshooting #229 ?
#229 résout en autonomie via arbres TRB. #342 qualifie la panne et prépare le handoff agent structuré.
Bot peut-il ouvrir dossier repair (#341) ?
Oui si route_repair : collecte intake photos, génère lien formulaire, tag repair_open.
Faut-il un arbre par SKU ?
Par famille produit suffit. SKU spécifique si volume fail_* > 5 % tickets catégorie.
Client refuse les questions bot ?
Handoff immédiat avec payload partiel. Mieux vaut 3 champs que 0.
Photos obligatoires ?
Oui avant route_warranty ou route_repair sur fail_physical_damage et likely_defect. Minimum 2 photos : vue globale produit + gros plan zone défectueuse ou code erreur.
Comment lier diagnostic bot et repair #341 ?
route_repair déclenche collecte intake (photos, n° série) et lien formulaire /reparation. REP-ID créé par agent ou ops, pas par bot seul.
Aller plus loin
Simulez 10 handoffs failure avec agents réels : vérifiez que le payload sidebar suffit pour agir sans relire tout le chat.
Partagez ce guide #342 avec produit et SAV : un diagnostic bot bien qualifié réduit les retours inutiles et accélère les vrais dossiers panne.
Intégrez le module failure_diagnosis au bot existant : mêmes intents fail_*, sidebar agent, routing vers #341 et #62 selon hypothesis.
Revoyez les arbres FAIL après chaque pic saisonnier : nouveaux SKU cadeaux Noël génèrent souvent des fail_usage concentrés sur 3 semaines.
Mesurez agent_handle_time avant/après payload : c'est la preuve ROI la plus convaincante pour convaincre l'équipe SAV d'adopter le module.
Objectif : handoff qualifié sur 100 % des tickets panne, même quand le client exige un humain dès la première phrase.
Enzo
10 juillet 2026
