E-commerce
July 17, 2026
"My product is broken, is it under warranty?" "Does the extension I paid for cover accidental damage?" "What proof do I need to send for the warranty?" These questions arise when the customer confuses instore returns, the 2-year legal warranty, and checkout extensions.
US Tech Automations estimates that automating eligibility verification and warranty status communication reduces processing time by about 70% (US Tech Automations, warranty 2026).
This guide #349 formalizes the AI warranty chatbot: explaining coverage, exclusions, and procedures without making risky promises. It complements warranty (#62) (after-sales automation) and extension (#348) with the angle of AI usecase clarifying warranty without overpromising.
Summary
Why automate warranty questions with a bot?
An unfounded warranty bot promise costs an unjustified replacement or a dispute when the claim is refused. The bot informs and routes; it does not decide complex cases on its own.
Warranty tickets volume
In electronics, household appliances, and sports equipment, warranty is in the top 4 post-delivery queries. Each poorly qualified ticket costs 15-25 minutes of agent time. A bot that explains terms and collects evidence filters out 50 to 65% of simple tickets.
Three risks without a structured warranty bot
Overpromising: "yes, it is under warranty" without checking eligibility
Terms confusion: returns, legal warranty, and extensions mixed up
Empty handoff: the agent asks the exact same questions again
Service-Public reminds us that the legal warranty of conformity covers defects for 2 years (Service-Public, legal warranty).
Angle #349
#62 automates the post-sales warranty workflow. #348 handles checkout extension ops. #349 defines the AI coverage, exclusions, and claim procedure bot with safeguards against overpromising.
Stage of the journey
Pre-purchase: PDP coverage question. Post-purchase: breakdown, eligibility, submitting a claim, file status.
DTC Example
Appliance brand: 120 warranty tickets/month, 45% terms confusion. After bot warranty_* + grounded policy: 62% self-resolved, warranty_overpromise_incidents 0, warranty bot CSAT 4.5/5.
Responsible AI
The warranty bot says "probable eligibility, agent confirmation" or "policy exclusion, here is why", never "replacement guaranteed" without a review.
Cost of bot overpromising
A bot that promises a replacement before validation costs the product, refunded extension, and chargeback. Warranty guardrails protect the margin as much as legal compliance.
How does it differ from the warranty and extension guides?
Seven neighboring contents, seven roles.
Guaranteed automation (#62)
Guide #62: portal, proof collection, after-sales service workflow. The #349 implements the AI explanation and triage layer.
Extension (#348)
Extension (#348): EXT-WAR policy, claims extension checkout. The #349 integrates ext_warranty into the bot matrix.
Failure diagnosis (#342)
Diagnosis (#342): qualifies failure. The #349 routes warranty after qualified failure.
Repair (#341)
Repair (#341): workshop flow. The #349 distinguishes warranty repair vs paid.
False promises (#209)
False promises (#209): deadlines and refunds. The #349: warranty bot promises.
AI Governance (#124)
Governance (#124): global framework. The #349 applies specific warranty guardrails.
Promise #349
Intents warranty_*, 3-regime bot matrix, anti-overpromising, claim procedure, handoff payload, KPI warranty_bot_resolution.
Which warranty intents should the bot classify?
Map the warranty bot intents before flows.
Twelve warranty intents
warranty_coverage_legal: 2-year legal warranty
warranty_coverage_commercial: manufacturer warranty
warranty_coverage_ext: checkout extension
warranty_eligibility: am I covered for this breakdown?
warranty_exclusion: shock, water, wear and tear covered?
warranty_procedure: how to file a claim
warranty_proofs: what documents to attach
warranty_status: what is the status of my claim
warranty_vs_return: return or warranty
warranty_denied_appeal: claim denied, appeal
warranty_third_party: third-party insurer redirect
warranty_register: product warranty registration
Required session fields
order_id, purchase_date, sku, warranty_regime (legal/commercial/ext/none), failure_type, photos_received, eligibility_hypothesis, escalation_reason. See taxonomy (#135).
90-day ticket mining
Export "garantie", "warranty", "panne", "defectueux", "extension". Prioritize flows on 80% volume by SKU.
Priority verbatims
"Is it still under warranty?", "shock but it worked before", "paid extension why denied", "what difference return 30 days". Four formulations cover 60% of DTC equipment warranty tickets.
Distinction warranty vs troubleshooting
Breakdown intent (#229) can be resolved without a claim. Bot routes to troubleshooting if usage/defect is uncertain, warranty_eligibility if defect is confirmed post-testing (#342).
How do you build the warranty bot tree?
The warranty bot tree leads from "broken" to explanation, procedure, or escalation.
Six sequential gates
Product gate: order found, SKU identified
Scheme gate: return vs legal vs extension
Date gate: purchase < 2 years, extension active?
Failure gate: defect vs wear and tear vs exclusion
Proof gate: photos, serial number, invoice collected
Exit gate: coverage info, claim procedure, handoff
Branch warranty_vs_return
Purchases < 30 days + change of mind → return policy route. Product defect → warranty_eligibility. The bot does not mix the two.
Branch warranty_eligibility
Purchase date + failure_type + exclusion policy → eligible/excluded/uncertain hypothesis. Uncertain = agent handoff, no bot promise.
Sequence #342 → #349
Failure diagnostic payload → warranty_eligibility with known failure_type. Saves agent time and ensures case consistency.
Max turns rule
6-8 questions maximum before handoff. Customer asks for a human: handoff with partial payload accepted.
WAR-BOT tree documentation
Each Notion branch: intent, gates, bot exit, equivalent macro #62/#348, handoff payload. Quarterly review if new extension or EU policy change.
Branch warranty_exclusion
Customer asks "accidental damage covered?": bot reads JSON exclusions, replies no + quotes policy. If customer describes accidental damage + failure: exclusion + paid repair options.
What data sources does the warranty bot read?
The warranty bot responds from verifiable policy sources.
Five Shopify sources
Order date + line items: time-based eligibility
Metafield order.ext_warranty: active extension (#348)
Metafield product.warranty_policy: coverage/exclusions JSON
Page /garantie: official policy RAG chunks
Claim status API: claim status if portal is used
3-regime JSON Matrix
product.warranty_policy: {legal: true, commercial_years: 2, ext_sku: EXT-2Y, exclusions: [shock, water, theft]}. Bot reads table, LLM reformulates.
Extension policy #348
If order.ext_warranty: bot cites extension terms, routes to ext_warranty_third if third-party insurer.
No standalone free RAG
Coverage = metafield + indexed warranty page. No LLM generation of "probably covered". See anti-hallucination.
Customer claim history
If portal #62: bot reads open/closed claim_id status. Prevents duplicate claim submissions and repetitive status tickets.
Serial number and registration
Metafield product.serial_required: bot requests serial number before warranty_procedure if manufacturer commercial warranty requires it.
How do I prevent the bot from overpromising on the warranty?
The anti-overpromise warranty is non-negotiable in e-commerce.
Five strict rules
No "guaranteed replacement" without agent-validated file
Hypothesis only: "probable eligibility" + confirmation
Exclusions mentioned: policy list if shock/water issue
No rejection decision: bot explains exclusion, agent settles dispute
Fallback: handoff if data is insufficient
System prompt warranty
"You never approve a claim. You explain coverage from the policy. You collect evidence for handoff. You escalate if the exclusion is ambiguous or the customer is dissatisfied." See system instructions (#310).
Approved wording
"Under the legal 2-year warranty, a lack of conformity may be covered. Here is the procedure and required proof." Forbidden: "We will replace it for you with no problem."
Dual claim validation
Bot collects evidence then proposes "submit claim on portal". Human or claim system validation before replacement commitment. Clear separation of bot information vs. customer service decision.
Regression tests
30 scenarios: eligible legal, shock exclusion, active ext, return vs warranty, denied appeal, third party. warranty_surpromise_incidents target 0.
Audit of bot wording
Weekly review of 20 bot warranty conversations: no sentences with "guaranteed", "assured replacement", "we will accept". Replace with "eligibility to be verified", "claim procedure".
Alignment #209
Same guardrails as false delivery promises: warranty bot = policy information, not commercial commitment.
Which bot flows for pre- and post-purchase warranty?
The warranty bot intervenes before and after a breakdown.
Pre-purchase PDP flow
"What is the warranty on this product?" → warranty_coverage_legal + commercial + optional extension link.
Post-breakdown flow
"My product no longer works" → regime gate → photo collection → warranty_procedure or handoff (#62 portal).
Claim status flow
warranty_status reads claim API or asks for case number → status + next step. Reduces "where is my warranty status?" tickets.
Extension flow #348
order.ext_warranty detected → warranty_coverage_ext + extension exclusions + third-party routing if applicable.
Handoff payload warranty
order_id, sku, purchase_date, warranty_regime, failure_type, photos[], eligibility_hypothesis, tests_done (#342).
Example bot response
"Your order #4521 (purchased on 14/03/2025) is under legal warranty until 14/03/2027. A mechanical failure without impact may be eligible. Exclusions: water, drops, modification. Claim procedure: [link]. Proofs: photo of failure + serial number."
WhatsApp / Instagram flow
Customer sends photo of failure: bot collects order email or number, identifies SKU, launches warranty_eligibility. Limit promises if only a photo is provided without impact/water context.
Proactive messages D+400
Reminder "legal warranty still valid for 335 days" with procedure link if home appliance product. Reduces "I didn't know I still had a warranty" tickets.
How do I connect the warranty bot on Shopify?
The Shopify warranty bot setup aligns order data and policy.
Technical Checklist
Create product.warranty_policy JSON metafield
Synchronize order.ext_warranty (#348)
Index /warranty page RAG
Configure warranty_* intents tree section 4
Write anti-overpromising prompt section 6
Connect claim status API if portal #62
Test 30 regression scenarios
Customer Account Widget
"Product issues / warranty" with pre-filled order_id.
Diagnosis Integration #342
Payload failure_diagnosis → automatic warranty_eligibility intent.
Progressive Launch
Phase 1: warranty_coverage + procedure top SKU. Phase 2: eligibility + status. Phase 3: ext + third party.
Shopify Flow Sync
Order tag warranty_claim_opened when customer starts portal claim #62. The warranty_status bot reads tag + API for a consistent status response for agents and the customer.
Which KPIs should be measured on the warranty bot?
Without KPI bot warranty, it's impossible to detect overpromising and incorrect routing.
Seven key metrics
warranty_bot_resolution: resolved without agent / warranty bot tickets
warranty_escalation_rate: handoffs / warranty sessions
warranty_surpromise_incidents: disputed bot promises
warranty_regime_confusion: mixed regimes tickets
warranty_claim_start_rate: claims initiated post-bot
time_to_warranty_handoff: evidence collection → agent
CSAT intent warranty_bot: post-response satisfaction
DTC Benchmark
Target warranty_bot_resolution > 55 %, warranty_surpromise_incidents 0, warranty_regime_confusion < 15 %, CSAT warranty bot > 4.4/5.
Monthly review
Top escalation_reason: enrich policy or flows. Correlate warranty_denied_appeal with bot formulations.
NPS warranty correlation
Warranty ticket client segment post-bot: NPS +12 pts if procedure is clear even in documented exclusion denial. NPS -25 pts if disputed bot overpromise.
What edge cases and escalations should be anticipated?
Five edge cases warranty bot require immediate escalation.
Breakdown + admitted impact
Standard exclusion. Bot cites policy, no favorable eligibility. Escalate if customer disputes.
Out of legal warranty without extension
Bot explains options: paid repair (#341), spare (#343), no false warranty promises.
Third-party extension (#348)
warranty_third_party: insurer portal URL, bot does not decide extension coverage.
Disputed denied claim
warranty_denied_appeal: handoff to warranty manager, no reopening of bot loop.
B2B professional account
Distinct contractual warranty. Handoff to B2B account, do not use B2C bot policy.
Customer threatens chargeback
Priority escalation with full payload. Bot remains factual, empathetic, without promises.
Product purchased on marketplace
Bot verifies purchase channel: shop warranty only if direct Shopify order. Third-party marketplace: handoff marketplace policy, do not use DTC warranty_policy.
How does Qstomy handle warranty questions?
Qstomy processes warranty_* intents from Shopify order, warranty_policy, and ext_warranty.
Capabilities
warranty_coverage: 3-scheme matrix explained
warranty_eligibility: hypothesis + evidence
warranty_procedure: claim portal link #62
warranty_status: case status if API
Handoff payload: structured warranty case
Encrypted DTC Scenario
Electronics brand, 120 warranty tickets/month, confusion over schemes.
After Qstomy warranty bot: 61% self-resolved, warranty_regime_confusion 11%, warranty_surpromise 0, warranty bot CSAT 4.6/5, warranty agent time -52%.
The bot informs and collects; the agent decides eligibility disputes and denied appeals with pre-filled photo cases and hypotheses.
Explore AI support, Shopify, request a demo.
What checklist is needed to launch the warranty bot?
Checklist bot warranty (10 steps)
Audit tickets warranty 90 d (#62, #348)
Document matrix 3 regimes policy
Fill in product.warranty_policy metafields
Configure intents warranty_* tree section 4
Write prompt anti-overpromise section 6
Connect order.ext_warranty and claim API
Test 30 regression scenarios
Integrate payload diagnostic #342
Dashboard warranty_bot_resolution weekly
Monthly review overpromise and escalation
In short
#349 = bot warranty AI, not customer service workflow (#62)
Inform, not approve: hypothesis + handoff
12 intents warranty_*: coverage, eligibility, procedure
Anti-overpromise: 0 guaranteed bot replacement
KPI warranty_bot_resolution: target > 55 %
FAQ
Difference with warranty #62?
#62 = portal and customer service workflow. #349 = bot explains coverage and routes without approving claim.
Can the bot reject a claim?
Bot explains exclusion policy. Rejection decision = agent or claim system, not bot alone.
Extension link #348?
Bot reads order.ext_warranty and cites extension conditions + routes to third party.
Is diagnostic #342 mandatory?
Recommended: payload failure accelerates warranty_eligibility and handoff.
What to do if policy is missing?
Escalate to agent. No generic LLM answer on coverage.
Agent training post-bot
Agents receive pre-qualified warranty cases: identified regime, attached photos, bot hypothesis. Agent focus = resolve dispute, not ask initial questions again.
Go further
Test ten warranty staging scenarios: legal eligible, impact exclusion, active ext, return vs warranty, missing policy.
Share this guide #349 with legal and customer service: a warranty bot without grounded policy = maximum risk of overpromising.
Synchronize product.warranty_policy decoration with each extension or supplier change: stale policy = massive escalations and rising warranty_regime_confusion.
Integrate the warranty procedure link in the post-purchase email for appliance and electronics SKUs with long-term warranty.
Enzo
July 17, 2026
