E-commerce
July 10, 2026
"My product is out of order." "It hasn't been working since yesterday." "I want to talk to someone now." The customer arrives frustrated. The agent receives an empty ticket: no SKU, no symptom, no test already performed.
VSight quotes Accenture: around 68% of electronics returns are No Trouble Found, often due to a lack of structured diagnostics before escalation (VSight, visual support 2026).
This #342 guide formalizes the AI troubleshooting chatbot: qualifying the failure, testing common causes, then transferring to customer service with a complete file. It complements troubleshooting (#229) (autonomous resolution) through the lens of breakdown, qualification, and structured agent handoff.
Summary
Why troubleshoot the breakdown before transferring to after-sales service?
Immediately transferring "out of order" to an agent is expensive and frustrates both parties. The agent asks the same questions the bot could have asked.
Three costs of raw handoff
Agent time: 8-15 min of qualification before action
NTF returns: product returned without actual defect
CSAT: customer repeats their story three times
The DQA framework (ACL 2026) shows that a diagnosis with persistent state achieves 78.7% resolution vs. 41.3% without structured state (ACL Anthology, DQA 2026).
Angle #342
#229 leads the troubleshooting tree to resolution. #342 optimizes the breakdown qualification phase and the handoff payload when the agent takes over.
Path stage
Post-purchase Day 1 to Day 730. Customer reports malfunction. Bot qualifies before after-sales queue, repair (#341), or warranty (#62).
DTC Example
Portable audio brand: 220 "out of order" tickets/month, 85% direct handoff. After bot failure_diagnosis + payload: 100% qualified handoff, agent time -42%, NTF returns -28%.
Value loop
Bot qualifies → agent acts fast → satisfied customer → less repeat contact. Without qualification, the agent becomes an information gatherer, not a resolver.
How does it differ from troubleshooting and after-sales triage?
Six neighboring pieces of content, six roles.
Troubleshooting (#229)
Guide #229: TRB-* trees, autonomous resolution. #342 focuses on outage qualification + handoff when bot resolution is impossible or the client requests a human.
After-Sales Triage (#236)
Triage (#236): urgency, global intent, channel. #342 delves deeper into failure_type and symptoms for defective product cases.
Repair (#341)
Repair (#341): ops workshop workflow. #342 qualifies before opening a repair case.
Warranty (#62)
Warranty (#62): warranty eligibility. #342 distinguishes usage vs defect before warranty routing.
Handoff (#12, #155)
Handoff (#12) and context (#155): general rules. #342 defines the specific failure_diagnosis payload.
Promise #342
failure_* intents, qualification tree, handoff payload, repair/warranty/return routing, NTF KPIs.
Complementarity #229
#229 and #342 share symptom trees. #229 aims for autonomous bot resolution. #342 aims for the agent case when resolution is impossible or the client demands a human after structured qualification.
Which failure intents should the bot classify?
Map the troubleshooting diagnosis intents before building the FAIL trees.
Ten post-purchase failure intents
fail_power: does not turn on, no light indicator
fail_intermittent: works sometimes, random shutdown
fail_performance: less efficient, abnormal noise
fail_connectivity: app, Wi-Fi, Bluetooth
fail_error_code: code displayed on screen
fail_physical_damage: shock, visible breakage
fail_leak_smell: leak, smell, overheating (rapid escalation)
fail_usage: incorrect setting, unrealistic expectation
fail_missing_part: item missing from package
fail_warranty_defect: defect confirmed post-tests
Mandatory qualification fields
SKU, purchase date, verbatim symptom, tests performed, bot hypothesis (usage/defect/unknown), photos requested or received. See taxonomy (#135).
Ticket mining (90 days)
Export "breakdown", "broken", "defective", "no longer works". Group by top 20 SKU. Prioritize FAIL trees on 80% of volume.
Priority verbatims
"Doesn't start anymore", "error code E03", "Bluetooth no longer connects", "weird smell", "missing part in the package". Five formulations cover 65% of DTC electronics and appliance breakdown tickets.
How do you build the failure qualification tree?
The qualification failure tree leads from "broken" to a routed exit.
Five sequential gates
Product gate: SKU identified, order found
Safety gate: leak, odor, overheating → immediate escalation
Usage gate: basic tests (power, mode, reset)
Symptom gate: fail_* branch depending on answers
Exit gate: resolved, handoff_agent, repair, warranty, return
Persistent diagnostic state
JSON session: {sku, symptom, tests_done[], hypothesis, confidence, photos[]}. LLM reformulates, tree decides. See anti-hallucination.
Max turns rule
6-8 questions max before handoff if unresolved. Customer asks for a human at any time: handoff with partial payload accepted.
fail_power branch (example)
Cable plugged in? Indicator light? Other outlet tested? Battery charged for 2 hours? Reset 10 seconds button? If all OK → likely fail_warranty_defect → warranty handoff.
fail_connectivity branch
App installed? Bluetooth enabled? Device in pairing mode? Distance < 3 m? Device reset + app reinit? If failure → fail_warranty_defect or expert handoff depending on product age.
Tree documentation
Each FAIL branch documented in Notion: questions, expected answers, exit, user guide link. Updated when new firmware or SKU recall occurs.
Error codes table
Metafield SKU error_codes JSON: E01=battery, E03=stuck motor. Bot reads table if fail_error_code, not LLM inventing the meaning of the code.
What payload should be sent to the customer service agent?
The payload handoff failure prevents the agent from starting from scratch.
Twelve minimum fields
order_id and sku
purchase_date and warranty_status
symptom_verbatim: customer quote
failure_intent: fail_power, fail_connectivity, etc.
tests_completed: list of bot checks
hypothesis: usage_error, likely_defect, unknown
confidence: 0-1
photos_urls: if uploaded
recommended_route: repair, warranty, return, expert
bot_resolution_attempted: yes/no
customer_sentiment: neutral, frustrated, angry
transcript_summary: 5 lines max
Agent display
Helpdesk sidebar: "Bot Diagnostic" block readable in 10 s. Agent validates or corrects hypothesis before taking action. Align with context transfer (#155).
Automatic routing
recommended_route=repair → workshop queue. warranty → warranty queue. return → return bot (#returns). expert → tier 2 product queue.
Real payload example
order_id #4521, SKU robot-mix-200, fail_power, tests: cable OK, reset done, hypothesis likely_defect, confidence 0.82, recommended_route warranty, 2 photos attached. Agent opens warranty ticket without asking 8 questions again.
Helpdesk integration
Gorgias, Zendesk or Recharge: custom fields mapped from JSON payload. Bot webhook → ticket created with pre-filled fields before agent assignment.
Which bot flows depending on the type of breakdown?
Adapt the breakdown diagnostic flow to the product vertical.
Electronics flow (fail_power, fail_connectivity)
Reset, firmware, pairing, cable, charging. Error codes table if fail_error_code. Link to electronics (#148).
Small household appliances flow
Blockage safety, calibration, mode, filter cleaning. Immediate fail_leak_smell escalation. Photos mandatory before handoff.
Fashion / textile flow
Often fail_usage or fail_physical_damage. Distinction between wear and tear vs sewing defect. Return routing if mind change.
Cosmetics / food flow
fail_performance (texture, taste) vs fail_leak_smell. Quality escalation if batch is suspicious. Link to product recall if pattern identified.
Customer requests human
"I want an agent": immediate handoff with partial payload + tag customer_requested_human.
Multilingual
FAIL tree is identical for all languages. Payload in agent language (FR) + original customer verbatim. See multilingual bot.
How do I route to repair, warranty, or return?
The routing failure matrix decides the output after qualification.
Four main outputs
resolved_bot: usage corrected, product OK
route_warranty: probable defect, under warranty
route_repair: repairable, out of warranty or policy repair
route_return: RMA return, exchange, or refund
Decision matrix
hypothesis=usage_error → resolved_bot or usage guide. likely_defect + warranty_active → route_warranty (#62). likely_defect + repair_eligible → route_repair (#341). physical_damage transit → route_return priority.
Macro bot output
“Based on our tests, your [SKU] presents [symptom]. We are directing you to [warranty/repair/return]. An agent will take over with your pre-filled file.”
Return pre-qualification
If route_return: bot collects RMA reason before label. See return pre-qualification.
Case fail_usage resolved
Customer thought product was broken, wrong mode selected. Bot resolves, tag fail_usage_resolved. No handoff. CSAT micro-survey "Problem solved?" after 2 min.
What are the rules for immediate escalation?
Certain P0 failure signals bypass the complete tree.
Six immediate escalation triggers
fail_leak_smell: leak, burning smell, smoke
Threatened chargeback or lawyer mentioned
VIP or cart > threshold according to policy
Repeat contact 3+ same breakdown within 7 days
Angry sentiment score > threshold
Dangerous product: swollen battery, electrocution
P0 handoff SLA
Live agent < 2 min chat, < 15 min email. Minimal payload: symptom + sku + urgency. Complete diagnosis in parallel if agent is available.
Dispute post-mortem
If customer is dissatisfied post-handoff: payload review. Missing fields? Wrong hypothesis? FAIL tree improvement loop every month.
Escalation matrix alignment
Cross-reference escalation matrix (#193) and triage (#236) urgency P0-P3.
Agent training
Agents trained to read the bot diagnostic block in 15 seconds. Never ask "have you tried restarting" if tests_completed lists a reset.
Which KPIs should be measured for bot failure diagnosis?
Measure the qualification failure quality, not only the handoff rate.
Six key metrics
failure_bot_resolution_rate: resolved without agent / total fail_*
handoff_payload_complete_rate: payload 10+ fields / handoffs
agent_time_saved: agent mins with vs without payload
ntf_return_rate: No Trouble Found returns / failure returns
misroute_rate: incorrect repair/warranty/return queue
CSAT post-handoff: satisfaction after qualified transfer
DTC Benchmark
Objective: handoff_payload_complete > 85%, ntf_return_rate < 25%, agent_time_saved > 8 min/failure ticket.
Weekly SKU Review
Top 5 SKU fail_*: adjust decision trees, add error codes, enrich guide if fail_usage is recurring.
A/B handoff
Group A: handoff without payload. Group B: complete payload. Measure agent_handle_time and 30-day CSAT. Expected gap of 8-12 mins saved for group B.
What mistakes should you avoid with a breakdown diagnostics bot?
Five failure bot anti-patterns to banish.
Error 1: handoff without payload
"Agent transfer" without context = double frustration. Fix: payload section 5 mandatory.
Error 2: promising replacement
Bot does not promise refund or exchange. It qualifies and routes. Human decides on warranty.
Error 3: ignoring security
fail_leak_smell = immediate P0. Not 6 questions about the user manual.
Error 4: identical tree for all SKUs
Headphones and food processor ≠ same tests. Trees by product family.
Error 5: blocking humans
Customer insists on an agent: handoff in 1 click with partial payload. See bot limits (#124).
Product feedback loop
Top 3 recurring fail_* for same SKU → product/quality alert. Bot diagnosis becomes a source of factory defect insights, not just after-sales service.
Bot CI tests
30 fail_* scenarios: assert hypothesis, recommended_route and payload_complete. Regression test with every firmware doc update or new SKU launch.
How does Qstomy qualify the breakdown before transferring to after-sales service?
Qstomy executes the failure_diagnosis tree, builds the handoff payload and routes to repair, warranty or return.
Capabilities
Intent fail_*: symptom classification
Multi-turn tree: persistent state, max 8 questions
Photo collection: upload before defect handoff
Handoff payload: 12 agent sidebar fields
Routing: warranty, repair (#341), return
DTC Business Case
Small domestic appliances brand, 180 fail_*/month tickets, gross handoff 90%.
After Qstomy failure_diagnosis: 38% solved by bot, handoff_payload_complete 91%, agent_time_saved 11 min, ntf_return_rate -26%, post-handoff CSAT 4.4/5.
The bot does not replace the product expert: it filters usage, qualifies defects and completes the file so that the human can decide on warranty or repair in minutes, not hours.
Explore AI support, Shopify, request a demo.
What is the checklist for launching the breakdown diagnostic bot?
Checklist failure bot (10 steps)
Mine breakdown tickets 90 days, top intents by SKU
Map 10 intents fail_* section 3
Build FAIL trees top 5 SKUs (section 4)
Define payload handoff 12 fields section 5
Configure routing warranty/repair/return section 7
Triggers P0 section 8 live
Helpdesk agent sidebar with diagnostic block
Test 20 scenarios fail_power, fail_connectivity, fail_leak
Enable KPI ntf_return_rate and payload_complete
Weekly review of trees vs wrongly routed tickets
In brief
#342 = breakdown qualification + handoff, not troubleshooting alone (#229)
Payload 12 fields: agent does not start from scratch
FAIL tree: 5 gates, persistent state
Routing: warranty, repair, return based on hypothesis
KPI NTF: fewer returns without actual confirmed defect
FAQ
Difference with troubleshooting #229?
#229 resolves autonomously via TRB trees. #342 qualifies the breakdown and prepares the structured agent handoff.
Can the bot open a repair case (#341)?
Yes if route_repair: collects intake photos, generates form link, tag repair_open.
Is one tree needed per SKU?
By product family is enough. Specific SKU if volume fail_* > 5% of category tickets.
Customer refuses bot questions?
Immediate handoff with partial payload. 3 fields are better than 0.
Are photos mandatory?
Yes before route_warranty or route_repair on fail_physical_damage and likely_defect. Minimum 2 photos: overall product view + close-up of defective area or error code.
How to link bot diagnostics and repair #341?
route_repair triggers intake collection (photos, serial no.) and form link /reparation. REP-ID created by agent or ops, not by bot alone.
Going further
Simulate 10 failure handoffs with real agents: verify that the sidebar payload is sufficient to act without re-reading the whole chat.
Share this #342 guide with product and after-sales: a well-qualified bot diagnosis reduces unnecessary returns and accelerates real breakdown files.
Integrate the failure_diagnosis module to the existing bot: same intents fail_*, agent sidebar, routing to #341 and #62 based on hypothesis.
Review FAIL trees after each seasonal peak: new Christmas gift SKUs often generate fail_usage concentrated over 3 weeks.
Measure agent_handle_time before/after payload: this is the most convincing ROI evidence to convince the after-sales team to adopt the module.
Goal: qualified handoff on 100% of breakdown tickets, even when the customer demands a human from the very first sentence.
Enzo
July 10, 2026
