E-commerce
August 2, 2026
"Can I still return my order?" "Your site says 30 days but the portal refuses." "It's a hygiene product, do you accept it anyway?" Three messages where a generic bot promises a return without checking the date, SKU, or exclusion policy.
Narvar observes that 67% of consumers consult the return policy before buying, and that the gap between site promise and portal refusal generates disputes and chargebacks (Narvar, returns 2025). Loop Returns estimates that a well-calibrated self-service eligibility check can deflect 40% to 55% of simple return tickets before reaching an agent (Loop Returns, policy 2026).
This guide #365 formalizes the e-commerce return eligibility AI chatbot: checking deadlines, exclusions, and rules before RMA. It complements return pre-qualification (#138) (upstream reason collection) from the perspective of deterministic order lookup + RET-ELIG policy + late handoff (#364). Distinct from returns bot (#10) (complete auxiliary exchange/refund journey).
Summary
Why automate return eligibility with a bot?
A return eligibility bot answers: am I still eligible, why is the portal blocking, what alternative if refused. It does not create the RMA on its own without rules: it applies RET-ELIG-GATE before the portal link or handoff.
Three generic bot failures
Return promise: bot guarantees refund without looking up delivery_date
Invented deadline: "30 days" when SKU is final sale 0 d
Hygiene ignored: bot opens RMA on worn underwear
Shopify points out that return eligibility must be consistent between TDP, portal, and CS to avoid disputes (Shopify, return policy 2026).
Angle #365
The #138 collects reason and handoff form. The #10 guides exchange/refund post-eligibility. The #365 implements the bot layer ret_elig_*: date check, SKU exclusions, holiday extension, late_ret handoff (#364).
ROI ret elig bot
For a fashion brand with 720 returns/month, targeted eligibility bot 65 to 75% auto-resolved vs 25% generic return bot which systematically hands off.
DTC Example
Accessories brand, 48 elig tickets/month, 31% of which are out-of-time and poorly routed. After RET-ELIG-GATE bot: ret_elig_bot_resolution 78%, ret_elig_false_promise 2%, response time 28 s, CSAT elig 4.5/5.
Journey moment
Pre-RMA: customer hesitates, portal error, chat "can I return". Trigger: return, exchange, deadline, eligible, expired.
Ops prerequisites
Published return policy + LATE-RET (#364) for out-of-time. Metafields return_window, final_sale, product_hygiene. Bot quotes RAG policy, does not invent rules.
Why a dedicated eligibility bot
Coupling with the full return bot (#10) dilutes precision: customer asking to "return" receives exchange procedure without date check. Routing ret_elig_* upstream avoids invalid RMAs and warehouse workload.
Volume and seasonality
Eligibility tickets peak in January (holiday returns #253) and end of month (30 d deadline). Bot ret_elig_holiday_extend handles temporary extension without agent.
Cost of bot false promise
Bot promising out-of-time return creates RMA rejected at warehouse + chargeback. RET-ELIG-GUARD prohibits RMA link if days_over > 0 without LATE-RET grid.
Deterministic vs LLM
The decision eligible yes/no is calculated (dates, tags, metafields). The LLM reformulates the answer and proposes alternatives, it does not decide on its own.
How does it differ from prequalification #138 and feedback bot #10?
Seven return contents, seven distinct bot roles.
Prequalification (#138)
Prequalification (#138): reason collection, handoff sheet. #365 = deterministic eligibility check before reason collection.
Return bot (#10)
Return bot (#10): exchange/refund journey. #365 intervenes as an upstream gate, handoff #10 if eligible=true.
Late return (#364)
Late return (#364): LATE-RET policy human ops. #365 handoff ret_elig_late via bot or agent exception grid.
Return policy
Return policy: contract drafting. #365 = automated execution of policy rules.
Holiday returns (#253)
Holiday returns (#253): January extension. #365: intent ret_elig_holiday_extend lookup flag shop.
Bundle returns
Partial bundle returns: SKU kit. #365 checks return_bundle_partial_allowed metafield.
Damaged parcel (#363)
Damaged parcel (#363): transit damage. If ret_elig_motif=damage: route dmg workflow, not standard return.
Promise #365
Intents ret_elig_*, flow RET-ELIG-GATE, safeguards RET-ELIG-GUARD, handoff #364/#10, KPI ret_elig_bot.
Which ret_elig intents should the bot classify?
Map the ret_elig intents before flows. Scope: verify and explain, do not approve exception without grid.
Twelve bot eligibility intents
ret_elig_check: am I eligible? date lookup
ret_elig_deadline_info: when does my deadline expire?
ret_elig_portal_blocked: portal refuses, why?
ret_elig_final_sale: final sale, no return
ret_elig_hygiene: opened hygiene product
ret_elig_late: out of deadline, handoff #364
ret_elig_holiday_extend: holiday extension active
ret_elig_gift_order: gift order, recipient rule
ret_elig_bundle_partial: partial kit return authorized?
ret_elig_preorder: preorder, deadline from delivery
ret_elig_marketplace: external channel order, redirect
ret_elig_denied_handoff: disputes bot refusal, escalation
Required session fields
order_id, delivery_date, return_deadline, days_remaining, days_over, sku_tags, final_sale, hygiene_flag, holiday_extend_active, eligible (bool). See taxonomy (#135).
Parent router
"eligible", "return deadline", "portal refuses", "more than 30 days" → ret_elig_*. "How to return step by step" without check → #10 returns.
90-day ticket mining
Export return tags + "expired", "out of deadline", "final sale". Prioritize top verbatim flows before Loop API integration.
MVP Prioritization
Week 1: ret_elig_check + ret_elig_deadline_info. Week 2: ret_elig_final_sale + ret_elig_hygiene. Week 3: ret_elig_late + handoff #364.
How to build the RET-ELIG-GATE flow?
The RET-ELIG-GATE flow routes each message via lookup order and policy before returning eligibility.
Seven sequential gates
Auth gate: email + order_id
Channel gate: marketplace → ret_elig_marketplace redirect
SKU gate: final_sale, hygiene, digital → exclusions
Date gate: delivery_date + window → days_remaining or days_over
Holiday gate: holiday_extend_active recalculates deadline
Late gate: days_over > 0 → ret_elig_late or LATE-RET grid (#364)
Exit gate: eligible + RMA link, or refusal + alternative, or handoff
Eligible ret_elig_check branch
If days_remaining > 0 and exclusions OK: "You have [N] days remaining (deadline [date]). Return link: [portal]." No refund promise, self-service link.
Blocked ret_elig_portal_blocked branch
Recalculate same logic as portal. If mismatch merchant_error (PDP said 45 days, policy 30 days): handoff ret_elig_denied with error flag.
Late ret_elig_late branch
Cite past deadline. If days_over 1-3 and LTV OK: offer exception form #364. Otherwise empathetic refusal + credit template LATE-RET-DENY.
Max clarification rounds
2 clarifications max (which SKU multi-line). Then agent handoff eligibility payload complete.
Output eligible=true
Bot sends deep link to Loop/ReturnGO portal pre-filled with order_id + line_item. Session flag rma_link_sent=true.
Which data sources does the eligibility bot read?
An eligibility bot without live Shopify data will hallucinate deadlines and exclusions.
Mandatory Shopify sources
Order fulfillment: delivery_date by line or fulfillment
Product tags: final-sale, hygiene, no-return, bundle
Product Metafields: return_window_override, return_excluded
Shop Metafields: default_return_window_days, holiday_extend_end
Customer LTV: segment for late exception grid
Return portal sources
Loop / ReturnGO API: eligible boolean mirror, RMA URL
Policy RAG: indexed /returns text, listed exclusions
LATE-RET doc #364: exception grid for ret_elig_late
Sync delivery_date
Webhook fulfillment delivered or carrier API. If delivery_date is null: bot ret_elig_preorder or WISMO handoff in_transit.
Portal vs. bot consistency
Bot must call the same eligible API as the portal. CI Test: 20 sample orders, bot result = portal result 100%.
Gift order flag
Metafield gift_order or checkout note. ret_elig_gift_order applies +14 days rule for recipient if policy LATE-RET section 5.
What RET-ELIG-GUARD safeguards should be imposed?
The RET-ELIG-GUARD guardrails prevent invalid RMAs and refund bot promises.
Six strict rules
No RMA if eligible=false: refusal + alternative, no bypass portal link
Auth before elig: order_id + email mandatory
LLM does not decide: eligible = function dates + tags, LLM reformulates
Hygiene never override bot: supervisor handoff only, no auto exception
Limited late exception: grid #364, no bot agent invention
Quote exact deadline: calculated date, not "about 30 days"
Prompt system ret elig
"You verify return eligibility according to RET-ELIG-GATE. You never promise a refund. If eligible, you send the portal link. If overdue, you apply LATE-RET or handoff. If final_sale or hygiene, you decline with policy citation." See anti-hallucination.
Audit false promise
Sample 50 conversations/month: ret_elig_false_promise_rate = bot says yes when eligible=false. Target < 3%.
Refusal templates
Three fixed templates: final_sale, hygiene, late_denied. LLM customizes empathy, not the rule.
On which customer journeys should the eligibility bot be deployed?
The eligibility bot operates on pre-RMA touchpoints.
"Can I return" chat flow
Auth → RET-ELIG-GATE → eligible RMA link or ret_elig_late handoff.
Portal error redirect flow
Portal error page: "Why refused?" button → chat ret_elig_portal_blocked explanation.
Post-delivery D+25 email flow
Reminder of deadline with 5 days remaining + chat link ret_elig_check. Reduces late_ret volume.
PDP FAQ widget flow
"Return period for this product?" pre-purchase: lookup return_window_override metafield without order.
Customer account flow
Orders section: "Returns available until [date]" badge calculated by bot rule engine.
ret_elig_denied_handoff flow
Customer disputes: supervisor payload order, calc eligible, screenshot of PDP if merchant_error claim.
Handoff #10 post-eligible
If eligible=true and customer wants size exchange: route to returns bot (#10) with elig OK context.
How to configure the eligibility bot on Shopify?
The Shopify eligibility bot setup connects the order API, return portal, and RAG policy.
Technical Checklist
Document return_window shop + overrides SKU metafields
Sync delivery_date webhook fulfillment
Integrate Loop/ReturnGO eligible API (Shopify App Store)
Index policy /returns + LATE-RET #364 RAG
Configure router ret_elig_* keywords
Implement RET-ELIG-GATE section 4
Write prompt RET-ELIG-GUARD section 6
Test 25 CI regression scenarios
Weekly ret_elig_bot_resolution dashboard
Helpdesk Integration
Handoff sidebar: eligible yes/no, deadline, days_over, sku_exclusions, rma_link_sent.
Progressive Rollout
Phase 1: ret_elig_check + deadline_info. Phase 2: exclusions final_sale/hygiene. Phase 3: ret_elig_late + #364 handoff.
Monthly Regression Testing
20 fixture orders: eligible true/false, holiday extend, bundle, late 2d. Bot vs portal parity check.
Which ret_elig_bot KPIs should be measured?
Without the ret_elig_bot KPI, it is impossible to prove ROI vs macros #364 alone.
Seven key metrics
ret_elig_bot_resolution: resolved without agent / ret elig sessions
ret_elig_deflection: elig tickets prevented / sessions
ret_elig_rma_link_sent_rate: eligible + link / ret_elig_check
ret_elig_late_handoff_rate: late / elig sessions
ret_elig_false_promise_rate: yes bot while eligible=false
ret_elig_portal_parity_rate: bot = portal / audit sample
CSAT intent ret_elig: eligibility check satisfaction
DTC Benchmark
Target ret_elig_bot_resolution > 75 %, ret_elig_false_promise < 3 %, ret_elig_portal_parity 100 % on sample, CSAT > 4.4/5.
Impact on late_ret volume
Measure late_return_volume (#364) before/after bot reminder D+25. Target -20% late_ret_few_days_over tickets.
Cost of invalid RMAs avoided
Track rejected return packages in the warehouse without a valid RMA. Bot elig must reduce this volume by 30 to 50 %.
What edge cases and handoffs should be planned for?
Seven edge cases ret elig bot require handoff or special procedure.
Split shipment delivery dates
Parcel 1 D+5, parcel 2 D+28: elig by line_item delivery_date. Link split (#356).
Multi-SKU partial order
Line 1 eligible, line 2 final_sale: bot explains mix, link to partial RMA portal.
Holiday extension + late overlap
Holiday extend until Jan 31. Customer Feb 5: standard ret_elig_late, not extend.
Preorder delivered late
Deadline from actual delivery, not order date. Bot quotes tracking delivered_at.
B2B or wholesale order
return_excluded tag B2B: handoff account manager, not DTC RMA.
Customer without account, gift
Auth email recipient + gift order_id. ret_elig_gift_order rule +14 days if policy.
Parcel damage vs satisfaction return
Reason "broken package": route dmg (#363), not standard ret_elig_check.
Contest merchant_error PDP
Customer screenshot PDP 45 days vs policy 30 days: handoff ret_elig_denied supervisor, flag merchant_error.
How does Qstomy verify return eligibility?
Qstomy connects ret_elig intents to Shopify orders, Loop portals, and LATE-RET grid #364.
Return eligibility capabilities
ret_elig_lookup: delivery_date + window + live exclusions
ret_elig_gate: RET-ELIG-GATE 7 deterministic gates
ret_elig_rma_deep_link: pre-filled order portal
ret_elig_late_grille: LTV + days_over → exception or rejection
ret_elig_handoff: payload #364 or #10 depending on exit
Encrypted DTC Scenario
Fashion brand, 620 returns/month, 18% "am I eligible" tickets before RMA.
After Qstomy ret_elig flows: 71% self-resolved, ret_elig_bot_resolution 79%, ret_elig_false_promise 1.8%, late_ret volume -22%, CSAT 4.6/5.
Explore AI support, Shopify, request a demo.
What is the checklist for launching the RET-ELIG bot?
Eligibility Bot Checklist (10 steps)
Audit elig tickets last 90 days and tag ret_elig_*
Document return_window + metafields exclusions
Sync delivery_date fulfillment webhook
Integrate Loop/ReturnGO eligible API
Index RAG policy /returns + LATE-RET #364
Implement RET-ELIG-GATE section 4
Configure router ret_elig_* intents
Write prompt RET-ELIG-GUARD section 6
Test 25 CI regression scenarios
Weekly ret_elig_bot_resolution dashboard
In brief
#365 = return eligibility bot, not full journey (#10) nor reason collection (#138)
RET-ELIG-GATE: auth → SKU → date → holiday → late → exit
12 intents ret_elig_*: check, late, final_sale, hygiene
Deterministic: LLM reformulates, does not decide eligibility
KPI ret_elig_bot_resolution: target > 75%
FAQ
Eligibility bot = full return bot?
No. #365 checks rules before RMA. #10 guides exchange/refund post-eligibility.
Difference with pre-qualification #138?
#138 collects reason and handoff form. #365 calculates eligibility yes/no with dates and exclusions.
Can the bot grant late exceptions?
Only if LATE-RET grid #364 is OK (LTV, days_over 1-3). Otherwise handoff to agent.
Final sale product at the portal?
Bot ret_elig_final_sale rejects with policy quotation, no RMA link.
How to test portal parity?
20 orders monthly fixture: bot eligible = portal eligible 100%.
Going further
Test mystery shop: order D+28, verify bot ret_elig_check quotes exact deadline + RMA link. Order final_sale: rejection without link.
Share this guide #365 with product and support: a well-calibrated eligibility bot prevents invalid RMAs and transforms customer doubt into a clear next step.
Enzo
August 2, 2026
