E-commerce
July 12, 2026
"I need the right hinge for my 2021 model." "What part number is item 14 on the diagram?" "I can't find my serial number, can you still confirm?" These questions arrive months or years after the purchase, when the spare parts catalog contains hundreds of SKUs and incompatible revisions.
iFixit notes that checking the model before ordering parts prevents errors on smartphones, consoles, and household appliances (iFixit, compatibility checker).
This guide #344 formalizes the spare parts AI chatbot: identifying the model, cross-referencing compatible_models, and proposing the exact spare SKU without hallucinating a part number. It complements support spare ops (#343) (policy, human macros) from the perspective of AI use cases for technical catalogs and complex part numbers.
Summary
Why automate spare parts lookup using a bot?
An incorrectly ordered part costs a return, an extra customer support ticket, and sometimes a lost customer. With a spare parts catalog of 400 SKUs, a human agent cannot memorize every compatibility matrix.
Three risks without a structured spare parts bot
Reference hallucination: LLM invents a compatible part
Agent time: 10-18 min of manual lookup per ticket
Wrong part rate: incompatible spare parts return, dispute
The EU ecodesign regulation reinforces the right to repair and the availability of parts for certain products (EU, ESPR ecodesign).
Angle #344
The #343 documents the spare parts policy, SPARE macros, and agent workflows. The #344 defines the dedicated spare parts reference lookup bot with Shopify data, spare_* trees, and error-prevention guardrails.
Journey stage
Post-purchase Day 30 to Day 1825. Customer knows which part to replace or cites a number on an exploded diagram. Bot confirms compatibility before providing the checkout link.
DTC Example
Home appliance brand: 95 spare parts tickets/month, average agent lookup 14 min, wrong_part_rate 19%. After spare_compat_check bot + metafields: 74% auto-resolved, wrong_part_rate 5%, spare parts agent time -58%.
Technical catalogs
Modular furniture, outdoor gear, bicycles, eyewear, small electronics: same marketing name, incompatible v1/v2/v3 revisions. The bot reads the data; it does not guess.
How does it differ from spare support and other bots?
Seven neighboring contents, seven roles.
Support spare ops (#343)
Guide #343: policy, SPARE macros, team-side wrong_part_rate KPI. #344 implements the reference lookup AI layer.
Failure diagnosis (#342)
Diagnosis (#342): qualifies the failure. #344 intervenes when the part to be replaced is identified or when the customer directly requests a spare ref.
Product compatibility (cross-functional)
Product compatibility: general pre-purchase matrix. #344 goes deeper into post-purchase spare catalog and part_number.
Pre-purchase electronics (#148)
Electronics (#148): guides selection of new products. #344 = spare part, not a complete product.
Manuals bot (#230)
Manuals bot (#230): instruction PDF. #344 links manual + exploded diagram + orderable spare SKU.
Large catalog (#87)
Large catalog assistant (#87): broad product search. #344 filters on spare-parts collection and strict compatible_models.
Promise #344
spare_* intents, model lookup tree, metafields data, ref anti-hallucination, spare PDP link, handoff if in doubt, wrong_part bot KPI.
Sequence #342 → #344
Failure diagnosis identifies probable part_number → spare bot confirms compatible_models + stock → ordering link. Handoff payload includes model + validated ref.
Which fallback intents should the bot classify?
Map out the spare parts bot intents before building the flows.
Ten post-purchase spare intents
spare_catalog: do you sell spare parts?
spare_compat_check: is this part number compatible with my model?
spare_model_lookup: where can I find my model number?
spare_part_number: part N on diagram → SKU?
spare_available: stock and lead time for part X
spare_oos: out of stock, restocking date
spare_obsolete: discontinued part, alternative
spare_install: part installation guide
spare_wrong_part: received part is incompatible
spare_warranty: free part under warranty
Mandatory session fields
model_id, revision, spare_sku_candidate, compatible_confirmed (bool), part_number_schema, stock_status, order_id if post-purchase. See taxonomy (#135).
Mining 90-day tickets
Export "spare part", "compatible", "reference", "diagram", "model". Group by top 20 parent SKUs. Prioritize spare flows on 80% of volume.
Priority verbatims
"Replacement hinge model X", "part 14 exploded view", "illegible serial number", "same product 2020 vs 2022 compatible?". Five wordings cover 70% of DTC equipment and furniture spare tickets.
Distinction between spare vs repair
spare_order intent = customer orders a DIY part. repair_request (#341) = workshop repairs. Bot routes to repair if the customer does not want to assemble it themselves.
How do you build the spare lookup tree?
The spare lookup tree leads from "which part?" to a validated part number or escalation.
Six sequential gates
Intent gate: spare_catalog, compat, part_number, OOS
Parent product gate: identified SKU or product name
Model gate: model_id + revision (photo of label if in doubt)
Part gate: customer customer ref, diagram part_number or breakdown symptom
Compat gate: compatible_models metafield cross-reference
Output gate: spare PDP link, OOS, obsolete, handoff_agent
Persistent session state
JSON: {model_id, revision, spare_sku, compat_ok, stock, source}. LLM reformulates, tree decides. See anti-hallucination.
Max turns rule
5-7 questions max before output. Customer asks for human: handoff with model and candidate ref already collected.
spare_model_lookup branch
Bot sends visual "where to find the number" by product category. Waits for label photo or model_id entry. No compatibility without confirmed model.
spare_part_number branch
Customer mentions "part 14" → bot reads part_number table → spare_sku. Then compat gate with model_id. If incompatible: clear message, no purchase link.
spare_compat_check branch
Customer mentions ref SP-4421 + model KitchenPro X200 rev B → bot reads compatible_models → yes/non + PDP link if yes and stock OK.
Tree documentation
Each SPARE branch documented: questions, data source, output, macro equivalent (#343). Updated at each product revision v2 launch.
Which data sources should the bot read?
The spare bot only responds using verifiable sources, never from the LLM memory alone.
Five Shopify sources
Metafield spare.compatible_models: JSON array model_id
Metafield spare.part_number: factory ref and diagram number
Metafield spare.parent_product: parent product link
Inventory API: live stock per spare location
Collection spare-parts: strict bot perimeter
Shopify documents product metafields to enrich the catalog (Shopify, metafields 2025).
Table part_number → SKU
CSV or JSON metafield: exploded item 14 = SP-HINGE-R-v2. Bot lookup table, not LLM generation.
PDF exploded diagrams
Manual link if spare_install. Bot cites PDF page, does not describe a part missing from the official diagram.
Order history
If customer is logged in: parent order line SKU → pre-fills model_id from purchased variant. Reduces "I have the wrong model" errors.
Weekly catalog sync
Supplier import: new refs, obsolescence, updated compatible_models. Bot stale data = wrong part. See Shopify data training.
RAG on manuals
Manual chunks indexed for spare_install only. Compatibility = metafield, not RAG. Separating the two avoids bot confusion.
How do I prevent the bot from inventing a reference?
The spare anti-hallucination is non-negotiable: an invented ref = guaranteed incorrect order.
Five strict rules
SKU Whitelist: bot only cites SKUs present in spare-parts collection
Compat gate: no purchase link if model_id is missing from compatible_models
No "I think": yes confirmed by data or escalate
Live stock: do not promise availability without inventory API
Fallback: "I cannot find this combination" + handoff
Spare system prompt
Instruction: "You never confirm compatibility without reading compatible_models. You never generate a SKU. You escalate if model_id is not found." See system instructions (#310).
Regression tests
20 scenarios: known model OK, unknown model, v1 vs v2 revision, non-existent ref, OOS, obsolete. Target ref hallucination rate 0%.
Customer double confirmation
Before checkout link: "Confirm: model [X] rev [Y], part [REF]." Yes/no button. Reduces wrong part issues on the customer side.
Audit logging
Each spare_compat_check logs model_id, spare_sku, source metafield, decision. Weekly review of compatibility refusals to enrich compatible_models.
Rare and custom models
If model_id is missing from catalog: product expert handoff, no LLM attempt. SPARE-ESCALATE macro with 24h SLA.
Which bot flows for spare parts on PDP and chat?
The spare bot intervenes on multiple touchpoints, not just the general chat widget.
Parent product PDP flow
"Need a part?" block: purchased or entered model dropdown → filtered spare compatible_models list → add to cart.
/pieces-detachees page flow
Central model lookup. Bot widget answers the same intents as the self-service page (#343).
Post-diagnostic flow #342
Failure payload includes probable part_number → spare bot validates compat + stock → order link or SPARE-OOS.
Instagram / WhatsApp flow
Customer sends label photo → OCR or async agent validates model_id → bot resumes spare_compat_check. Limit promise if OCR is uncertain.
Proactive messages
On spare-parts collection: "Enter your model to see compatible parts." See proactive messages.
Spare payload handoff
model_id, revision, spare_sku_tried, compat_result, photos[], order_id. Agent does not ask the bot's questions again.
Example of a validated bot response
"Your Outdoor Tent Pro 3 model (2022 revision) is compatible with the SP-HINGE-R-v2 hinge. Stock: 12 units, 48-hour shipping. Order here: [link]. Part 14 assembly guide: [PDF]."
How to connect the spare bot on Shopify?
The Shopify spare parts bot setup is based on configured metafields, collections, and intents.
Technical Checklist
Create spare.* namespace metafields on spare products
Fill in compatible_models JSON for top 50 spare SKUs
Tag spare_part + collection spare-parts
Connect inventory API to the bot
Index part_number table if exploded schemas are used
Configure spare_* intents in Qstomy or equivalent
Test 20 scenarios from section 6
Parent PDP Widget
App block or snippet: pre-filled chat button with spare_compat_check intent and parent product_id.
Shopify Flow Alerts
If spare_oos > 30 days on top 10 SKUs: ops alert + updated SPARE-OOS bot message.
Storefront API
Bot queries products from spare-parts collection filtered by metafield compatible_models contains model_id. No full catalog LLM search.
Multi-location spare
Separate spare warehouse: inventory by location. Bot reads spare location stock, not new product stock.
Gradual Launch
Phase 1: top 20 spare SKUs representing 80% of volume. Phase 2: complete catalog. Phase 3: photo label OCR if model_lookup handoff rate > 40%.
Which KPIs should be measured on the spare bot?
Without spare bot KPIs, it is impossible to prove ROI or detect residual hallucinations.
Seven key metrics
spare_bot_resolution: resolved without agent / spare bot tickets
spare_compat_bot_rate: confirmed bot compat / lookups
bot_wrong_part_rate: wrong part returns after bot usage
spare_handoff_rate: escalatons / spare sessions
time_to_spare_link: chat open → PDP link sent
spare_conversion_bot: spare orders post-bot link
CSAT intent spare_bot: satisfaction post-lookup
DTC Benchmark
Goal: spare_bot_resolution > 65%, bot_wrong_part_rate < 3%, spare_handoff_rate < 35%, time_to_spare_link < 90 s.
Wrong_part correlation
Compare bot_wrong_part_rate vs overall wrong_part_rate (#343). If bot is lower: proof of AI value. If equal: review compat gates.
Monthly review
Top 10 handoff reasons: model_id missing, obsolete, custom. Enrich metafields or schemas based on dominant cause.
Double confirmation A/B test
Measure the impact of model+ref confirmation button on conversion and wrong_part. Often +5 pt conversion, -2 pt wrong_part.
What edge cases and escalations should be anticipated?
Five spare bot edge cases require explicit rules, not LLM improvisation.
Model not found
Label photo requested. If still missing: expert handoff, no part suggested. Tag spare_model_unknown.
Ambiguous revision v1 vs v2
Bot lists visual differences (clip color, connector shape). Customer decides. If doubt persists: handoff.
Obsolete part
Bot reads obsolete flag + alternative_sku metafield. Do not sell discontinued part. Bot macro SPARE-OBSOLETE.
Free warranty part
spare_warranty intent: bot checks order date + warranty policy (#62). Do not send paid link if covered.
B2B part volume
Quantity > 10 or wholesale account: route to wholesale bot (#334).
Dangerous DIY part
Battery, gas: bot refuses DIY sale, suggests repair workshop (#341). Policy #343 aligned.
Post-bot wrong part claim
If customer ordered via bot link: audit compatibility log. Data error → free return. Customer model_id error → return policy #343.
How does Qstomy manage the spare parts lookup?
Qstomy processes spare_* intents from compatible_models, Shopify inventory, and spare-parts collection.
Spare bot capabilities
spare_compat_check: model_id → validated ref or refusal
spare_part_number: schema → SKU via table
Live stock: OOS with date if restock metafield exists
Spare PDP link: direct checkout
Handoff payload: model, ref, photos, decision log
Quantified DTC Scenario
Modular furniture brand, 110 spare tickets/month, manual agent lookup.
After Qstomy spare bot + metafields: 76% spare tickets auto-resolved, bot_wrong_part_rate 4%, spare_handoff_rate 24%, spare bot CSAT 4.7/5, spare agent time -61%.
The bot filters standard lookups; the catalog expert steps in for rare models and wrong part disputes with a pre-filled file.
Explore AI support, Shopify, request a demo.
What is the checklist for launching the spare parts bot?
Checklist bot spare (10 steps)
Audit spare tickets for 90 days and prioritize top SKUs
Create metafields spare.compatible_models and part_number
Populate compatible_models for top 50 spare refs
Configure spare_* intents and 6-gate tree
Write anti-hallucination prompt spare section 6
Connect inventory API and spare-parts collection
Test 20 regression scenarios
Enable double confirmation before checkout link
Weekly spare_bot_resolution dashboard
Monthly review of handoff reasons and metafields enrichment
In brief
#344 = bot lookup spare, not policy ops (#343)
Data first : compatible_models, never LLM alone
10 intents spare_* : compat, part_number, OOS
Anti-hallucination : whitelist SKU, compat gate
KPI bot_wrong_part_rate : target < 3 %
FAQ
Difference with spare support #343 ?
#343 = team, macros, policy. #344 = AI bot error-free reference lookup.
Can the bot confirm compatibility without a metafield?
No. Escalation or refusal. Never "probably compatible".
How to link breakdown diagnosis #342?
Payload failure → part_number → spare bot validates compat + stock → order link.
Is a separate spare catalog needed?
Yes, spare-parts collection + metafields. Bot does not search the entire shop.
What to do if label photo OCR fails?
Request manual model_id entry or handoff to agent with photo attached.
Going further
Test five spare lookups yourself on your staging store: known model, unknown, OOS, obsolete, wrong revision.
Share this guide #344 with the product and catalog ops team: up-to-date compatible_models metafields are worth more than a long LLM prompt.
Synchronize compatible_models with each revision launch: a spare bot on stale data multiplies wrong_part_rate in 30 days.
Enzo
July 12, 2026
