E-commerce
June 28, 2026
"It doesn't work." Three words, ten possible causes: dead battery, wrong mode, poorly assembled part, unrealistic expectation, or actual defect. The customer wants an answer now; your product expert is not available at 11 PM on a Sunday.
VSight quotes Accenture: about 68% of electronics returns are No Trouble Found, often after a diagnosis failure (VSight, visual support 2026). A generic chatbot spit out the PDF manual does not help: what is needed is a conversational diagnosis that gathers clues turn after turn.
This guide #229 covers the post-purchase AI product diagnosis chatbot: intents, trees, expert handoff. Distinct from installation support (#228) (human workflow + INS macros), onboarding bot (#179) (proactive setup), and bot limits (#124): here, it is guided troubleshooting that knows when to stop before replacing technical judgment.
Summary
Why is conversational diagnostics changing product support?
The product diagnostic chatbot does not answer a question: it conducts a structured investigation leading to a probable cause or an escalation.
Limit of Naive Multi-Turn RAG
The DQA framework (ACL Industry 2026) shows that a standard RAG without a diagnostic state achieves a 41.3% resolution rate on IT support scenarios, compared to 78.7% with a persistent state and competing hypotheses (ACL Anthology, DQA 2026). The same logic applies to e-commerce: "it doesn't work" requires targeted questions, not an instruction manual paragraph.
Three Measurable Gains
Prevented NTF (No Trouble Found) Returns: reset, pairing, adjustment before refund request
Filtered Expert Tickets: the human receives a pre-diagnosed case file
24/7 Availability: level 1 diagnostics without waiting queues
DTC Small Household Appliance Example
Food processor, 34% of post-delivery tickets are "does not work." 5-branch diagnostic bot (power, safety, mode, blockage, fault). After 8 weeks: bot autonomy 62%, NTF returns −31%, expert time per ticket −40%.
How does it differ from installation, onboarding, and bot limits?
Five related pieces of content, one angle: post-purchase AI diagnostic with expert handoff.
Installation Support (#228)
Installation Support (#228): INS-* macros, human escalation, tutorials. #229 covers how the bot drives the diagnostic tree before handoff.
Bot Onboarding (#179)
Bot Onboarding: proactive setup flows Day+0. #229: reactive when the customer reports a malfunction, including weeks after delivery.
Static Usage Guide
Usage Guide: PDF/video assets. The bot orchestrates and adapts based on customer responses.
Limits and Handoff (#124, #12)
Bot Limits (#124): restricted areas. Handoff (#12): general rules. #229 specifies diagnostic thresholds: when the bot stops and hands over to an expert.
Promise #229
Troubleshoot intents, diagnostic state, TRB-* branches, corpus, escalation, tests, KPIs, playbooks.
Which diagnostic intents should be mapped for the chatbot?
Map the chatbot troubleshoot intents before linking the trees.
Twelve post-purchase intents (top volume)
ts_power_on: does not start, indicator light off
ts_power_cycle: turns off by itself, overheating
ts_connectivity: Wi-Fi, Bluetooth, app pairing
ts_assembly_incomplete: unstable structure, abnormal noise
ts_missing_part: part missing from package
ts_usage_wrong: wrong mode, wrong dosage
ts_expectation_gap: "not the promised effect" without defect
ts_error_code: code displayed on screen
ts_noise_leak: leak, odor, suspicious noise (rapid escalation)
ts_damage_transit: visible breakage upon receipt
ts_warranty_defect: defect confirmed post-diagnosis
ts_compare_working: "it works for my neighbor" (usage/comparison)
90-day ticket mining
Export verbatims containing "does not work", "defective", "code", "pairing", "noise". Cross-reference SKU: top 5 intents per category = order of tree construction.
Prioritizing bot vs. human
Autonomous Bot: ts_power_on, ts_connectivity, ts_usage_wrong, ts_error_code (if code table exists). Immediate handoff: ts_noise_leak, ts_damage_transit, customer threatening chargeback.
How to build a TRB-* conversational diagnostic tree?
The TRB-* bot diagnostic tree follows deterministic branches; the LLM reformulates, it does not invent steps.
4-Layer Structure
Triage: Confirmed SKU, delivery date, symptom in one sentence
Hypotheses: 2-4 classified probable causes (usage > config > defect)
Sequential tests: one action, Yes/No/Photo confirmation
Conclusion: resolved, part to send, or expert escalation
Persistent Diagnostic State
Store in session: hypotheses[], tests_done[], confidence_score. Zoom Contact Center recommends guided flows that escalate when confidence falls below a threshold, with full context transferred (Zoom, agents service 2026). Viewpoint Analysis cites Stonly and Zingtree for interactive adaptive guides in complex troubleshooting (Viewpoint Analysis, AI support 2026).
TRB-POWER Example (extract)
1) Cable plugged into mains? 2) Charging indicator? 3) 10 s power button reset. 4) Other socket tested? If 4x No → confidence_defect 0.75 → support handoff with test log.
Minimal JSON Schema (Shopify metafield)
{"sku":"HUM-200","intent":"ts_power_on","steps":[{"id":1,"action":"Brancher câble secteur","next_yes":2,"next_no":"photo_cable"}, {"id":2,"action":"Voyant charge visible ?","next_yes":3,"next_no":"charge_2h"}], "escalate_after_steps":4}. Version on each product revision.
Error codes
Table error_codes[SKU]: E77 → reset procedure + coil check (Onsite AI pattern (Onsite AI, troubleshooting 2026)). No lookup = TRB-UNKNOWN, no invention.
Which data sources should be connected to the diagnostic bot?
The troubleshoot bot data stack combines order, technical corpus, and escalation rules.
Mandatory sources
Shopify Order: SKU, variant, delivery date, warranty
TRB Trees: JSON per SKU or product family
Error codes: structured table, not PDF only
Chunked tutorials: setup/troubleshoot steps (#228)
After-Sales Policy: replacement, return, spare part
Corpus chunking
One chunk = one diagnostic step: action, image, next condition if Yes/No. SharkNinja restructured image-heavy manuals before unboxing agents (PYMNTS, SharkNinja 2026).
Weekly sync
New SKU → minimum tree before release. BOM revision → TRB update. See catalog knowledge base and train Shopify bot.
Which bot branches for power supply, pairing, and incorrect usage?
Three troubleshoot bot branches cover ~60% of the post-delivery volume for electronics and connected devices.
Power branch (ts_power_on)
Sequence: plugging → indicator light → initial charge 2 hours → reset → other cable/outlets. Buttons: "Done / Not done / I don't know". "I don't know" → photo requested or handoff.
Pairing branch (ts_connectivity)
OS version → app installed → Bluetooth/Wi-Fi ON → pairing mode (duration 30 s) → distance < 2 m. 45-second video link if step 3 fails. See electronic advice for pre-purchase compatibility.
Usage branch (ts_usage_wrong)
Cosmetics: dosage, frequency, associated SPF. Fitness: belt tension, flat surface. Kitchen: mode vs recipe. Key message: "This behavior is normal for the first 3 days" if documented.
Six TRB-* macros for the bot
TRB-TRIAGE-01: "I see your [SKU] delivered on [date]. Describe in one sentence what is wrong. I will guide you step by step."
TRB-STEP-01: "Step [N]/[total]: [documented action]. Press Done when finished."
TRB-CODE-01: "Code [X] on [SKU]: [error_codes table procedure]. If the code persists after these steps, I will connect you with our expert."
TRB-NTF-01: "Good news: the product is responding normally. Here is how to achieve [expected result]. No return needed for now."
TRB-ESCALATE-01: "I have noted: [symptom], tests [list], photos received. Our product expert will take over within [delay]. You don't need to repeat anything."
TRB-UNKNOWN-01: "I don't have a validated procedure for this case on [SKU]. I am transferring you to an expert without making you wait for an invented answer."
Bot response templates
Step: "Let's try this: [action]. Tell me when it's done."
Confirmation: "Perfect, is the light green? Next step: ..."
Blocker: "Thank you for the photo. I see [grounded observation]. Let's try ..."
When should the bot escalate to an expert without improvising?
Principle #229: help without replacing the expert. Escalation is a feature, not a failure.
Immediate escalation triggers
Safety: burning smell, leak, spark, abnormal overheating
Confidence < 0.55 after 3 tests without resolution
Explicit request: "I want a technician"
Regulated product: skin reaction, ingestion (regulated products)
Warranty dispute: customer demands replacement without diagnosis (after-sales warranty)
Structured handoff
Transmit: SKU, initial symptom, ruled-out hypotheses, tests performed, photos, confidence score. Gorgias recommends handoff with full context to prevent the customer from repeating themselves (Gorgias, AI handover 2026).
What the bot never decides on its own
Refund, shipping a new product without inspection, opening a legal warranty claim, food safety diagnosis. See bot limits (#124).
How do you avoid hallucinations and overpromising in troubleshooting?
The grounded troubleshoot bot never guesses a procedure that is absent from the corpus.
Strict rules
Whitelist steps: only documented TRB actions
No disassembly if not in the tree (safety risk)
TRB-UNKNOWN if error code or SKU is without a tree
No "it's normal" without product claim substantiation
Technical safeguards
Low temperature on step generation. JSON schema validation before sending to the client. Log every step for quality audit. See anti-hallucination (#123) and bot governance (#142).
"Attack the bot" program
Inspired by SharkNinja: customer service agents attempt to break the bot 30 mins/day (rare codes, blurry photos, contradictions). Weekly feedback to the conversational design team.
How to test and iterate the diagnostic bot before going live?
The QA bot troubleshoot combines replay scenarios and trajectory metrics, not just a single response.
Test protocol (20 scenarios / priority SKU)
5 cases resolvable by the bot alone (power, pairing, usage)
5 real NTF cases (wrong mode, cable)
5 mandatory escalation cases (safety, defect)
5 edge cases (missing photo, similar SKU, multilingual)
Trajectory success criteria
Inspired by DQA: resolution = customer confirms OK OR expert handoff with a complete file in < 6 turns. Pilot target: ≥ 55% autonomy, ≥ 85% handoffs with test log.
2-week Shadow mode
Bot proposes a response, agent validates before sending. Measure discrepancies between agent vs bot → enrich the tree.
Which KPIs should be used to manage the chatbot diagnosis?
Measure the bot diagnosis by journey, not by isolated message.
Resolution KPIs
Bot troubleshoot resolution rate: OK customer without human
Average turns: target 3-5 (DQA baseline 3.9)
Post-chat NTF feedback by SKU
TRB-UNKNOWN rate: corpus gap signal
Escalation KPIs
Handoff quality score: expert confirms case is actionable
7-day repeat contact same SKU
Troubleshoot segment CSAT
Monthly loop
Top unresolved intents → new TRB branch. SKU TRB-UNKNOWN > 10% → priority tree. Cross-reference TPU tickets and chatbot KPI (#11).
How does Qstomy conduct conversational product diagnostics?
Qstomy combines lookup command, grounded TRB trees, and structured expert handoff.
Diagnostic features
Session diagnostic state: persistent hypotheses and tests
SKU lookup + error_codes: whitelisted procedures
ts_* intents: automatic post-delivery routing
Guided photo request: documented angles per tree
Case handoff: complete log for expert
TRB-UNKNOWN + security blocking: no improvisation
Quantified DTC scenario
Air purifier + humidifier brand, 29% of tickets "not working", CSAT troubleshoot 68%. Deployment: 12 TRB trees, 18 error codes table, enriched Gorgias handoff. After 10 weeks: bot resolution 58%, NTF returns −27%, average turns 4.1, expert handoff satisfaction 91% (complete case file).
Explore Shopify integration, AI customer support, request a demo.
Which operational playbooks should be launched this week?
Playbook 1: intent mapping (½ day)
Export tickets 90 days, classify 12 intents in section 3 by top revenue SKU.
Playbook 2: pilot TRB tree (2 days / SKU)
Triage + 3 branches + conclusion. Product expert validation before production.
Playbook 3: corpus + error codes (1 day)
Chunk manuals, JSON error_codes table, sync Shopify metafields.
Playbook 4: QA + shadow mode (2 weeks)
20 scenarios in section 9, attack the bot, shadow then switch 25% traffic.
Playbook 5: monthly KPI review (1 hour)
Resolution, NTF, TRB-UNKNOWN, enrich trees or handoff.
Useful links
A good diagnostic bot does not pretend to be an engineer: it asks the right questions, runs the safe documented tests, and hands over with a file that the expert can use in thirty seconds. This is how you reduce unjustified returns without sacrificing customer trust.
Enzo
June 28, 2026
