E-commerce
July 1, 2026
"My tracking has been frozen for 4 days, is this normal?" "The website says delivered but I haven't received anything." "The tracking number doesn't work." Three messages where the customer is not asking for a simple ETA, but an explanation of a carrier status anomaly.
An e-commerce carrier tracking AI chatbot does not replace the TRACK-ERR policy or CARR-FLOW agents. It reads fulfillment + carrier API, calculates days_since_last_scan, explains stale, DNR or invalid number grounded data, and escalates without prematurely promising reship or "lost package".
This guide #398 covers intents bot_track_*, flow CARR-BOT, AI safeguards and track_bot KPIs. It differs from TRACK-ERR agents (#397) (policy, carrier claims, reship) and the WISMO bot (#184) (standard ETA): here, the focus is AI use case for post-shipping tracking anomalies, blocked statuses and next customer steps.
Summary
Why deploy an AI chatbot for tracking anomalies?
Anomaly tracking questions via chat arrive post-shipment, often after consulting the tracking page. Without a calibrated bot, four failures recur.
Four dysfunctions without a track_err bot
Premature lost package: bot says "lost" on J+3 stale
Reship promised: LLM promises redelivery without reaching the TRACK-ERR threshold
Shopify-only status: no carrier API lookup
Incomplete ticket: agent handoff without last_scan or days_stale
AfterShip estimates that 11 to 15% of packages present an anomaly or transit status delay (AfterShip, carrier updates 2026). Claro places WISMO tickets at 30-50% of support volume (Claro, WISMO 2026), of which 12-22% are track_err according to #397.
Angle #398 vs related content
#397 TRACK-ERR agents: CARR-FLOW, claims, reship. This #398 automates bot explanation 24/7.
#184 WISMO bot: standard ETA, tracking link. This #398 zooms in on stale, DNR, invalid, mismatch.
#396 prep bot: unfulfilled prep. This #398 = fulfilled post-shipment.
#357 split bot: multi-package manifest. This #398 = anomaly on consulted tracking.
#361 insurance: claim after procedure. This #398 = bot investigation before claim.
DTC Example
Fashion brand, AfterShip connected, 94 track_err tickets/month with 64% outside office hours. After CARR-BOT: track_bot_resolution 76%, track_false_lost_promise 0, track_bot_handoff_complete 92%, overall track_err_fcr +14 pts.
Responsible AI Principle
The bot reads the carrier API, cites grounded last_scan, and explains the next step. It does not reship, design lost confirmations, or open claims without a #397 handoff.
How does CARR-BOT differ from CARR-FLOW #397 and WISMO #184?
The anomaly tracking bot and the CARR-FLOW agents process complement each other, just like PREP-BOT (#396) and PREP-FLOW (#395).
#398 bot: upstream (minutes 0-5)
Detect intent bot_track_* vs wismo_eta #184
Dual lookup: Shopify fulfillment + carrier API
Calculate days_since_last_scan, stale flag
Classify: stale | no_scan | DNR | invalid | mismatch | exception
Explain TRACK templates grounded on CB-5 data
Handoff pre-filled CR-5+ ticket if TRACK-ERR threshold is exceeded
#397 agents: execution (claims, reship)
CR-7 carrier escalation: carrier form, case_id
Reship/refund: 10 days stale threshold or confirmed lost
DNR 48h investigation: neighbor, Locker, evidence
Insurance #361: Route claim post-investigation
#184 WISMO: normal status
Bot #184 responds with ETA if scans are progressing. If stale for 72h+ or carrier exception occurs, reroute bot_track_* to CARR-BOT. If unfulfilled, reroute to #396 PREP-BOT.
Structured Handoff
Ticket: order_id, tracking_number, carrier, last_scan_at, last_scan_location, days_stale, carrier_api_status, bot_track_type, exception_code, transcript, dnr_flag Y/N.
What the bot does not do
No reship API, no carrier claim, no refund, no "lost package" status before the rule 8 TRACK-ERR threshold is reached.
Which bot_track_* intents should the chatbot detect?
Twelve anomaly tracking bot intents aligned with types #397.
Twelve bot_track intents
bot_track_stale_scan: no scan for 72h+ (48h express)
bot_track_no_initial_scan: label created, zero scans on D+2+
bot_track_mismatch: Shopify ≠ carrier status
bot_track_invalid_number: tracking 404, wrong carrier
bot_track_dnr: delivered not received, 48h procedure
bot_track_rts: return to sender
bot_track_address_exception: incomplete address hub
bot_track_customs_hold: customs hold, reroute #65
bot_track_damaged_transit: damage exception, reroute #363
bot_track_split_wrong: wrong package consulted, reroute #357
bot_track_lost_inquiry: customer asks if lost, no confirmation
bot_track_relay_awaiting: pick-up point awaiting collection
Trigger signals
stuck, frozen, has not moved, no update, stuck, lost, not received
carrier API: days_stale >= threshold or exception flag
wismo #184 reroute if stale detected post-lookup
Conversation tags
track_bot_detected, track_bot_stale_ok, track_bot_handoff, track_bot_reroute_prep, track_bot_reroute_split, track_bot_reroute_customs, track_bot_dnr_started.
Intent priority
bot_track_dnr + delivered status > bot_track_lost_inquiry > bot_track_stale_scan. Chargeback threat: live agent handoff if business day.
Distinction wismo_eta #184
If last_scan < 72h and status in_transit is normal: reroute to wismo_eta #184, not CARR-BOT.
Which CARR-BOT conversational flow should be configured?
The CARR-BOT flow guides the tracking anomaly explanation in 8 steps, CB-1 to CB-8.
bot_track_stale_scan Sequence
CB-1 Greeting: "AI Assistant. I am checking the carrier status of your package."
CB-2 Collect order_id: or email + OTP if logged-out
CB-3 Dual Lookup: Shopify fulfillment + carrier API last_scan
CB-4 Classify: stale | no_scan | DNR | invalid | normal → reroute
CB-5 Calculate: days_stale, stale_threshold (72 hrs std / 48 hrs express)
CB-6 Explain: TRACK-STALE template grounded last_scan + next step
CB-7 Handoff if needed: stale > claim threshold, DNR insistence, invalid ops
CB-8 Close: branded tracking link + "we are monitoring" if stale < claim threshold
bot_track_dnr Branch
Carrier status delivered + customer DID NOT RECEIVE: 48-hour neighbor/locker/mailbox procedure. Collect absence confirmation. Handoff to CR-7 if 48 hours have passed or customer insists.
bot_track_no_initial_scan Branch
Label created Day+0, zero scans Day+2: explain hub delay of 24-48 hours. If Day+3+: handoff to warehouse ping + carrier claim CR-7.
bot_track_invalid_number Branch
Tracking 404: handoff to ops label verification. Message: "We will verify the label within 24 hours."
Flow Prohibitions
Never say "your package is lost" without carrier-confirmed lost. Never say "we are resending a package" without a CR-7 agent. Never invent an ETA if status is stale.
What can and cannot the bot do regarding anomaly tracking?
The authorized vs prohibited bot track matrix protects brand and reship cost.
Authorized bot actions
Dual lookup Shopify + carrier API
Cite last_scan_at, location, days_stale grounded
Explain normal stale 2-4 days between hubs if < 72 h
Guide DNR 48 h neighbor/locker procedure
Reroute prep #396, wismo #184, split #357, customs #65, dmg #363
Create pre-filled CR-5+ handoff ticket #397
Send branded tracking page link #181
Open carrier flag investigation for agent (do not submit claim)
Prohibited bot actions
Reship or refund API
Confirm lost parcel without carrier lost status or 10-day stale policy
Submit Route/carrier claim without agent
Invent next scan date or hub location
Modify shipping address
Promise next-day delivery on stale parcel without carrier ETA
Gray zone: stale 72-96 h
Bot explains + opens carrier investigation flag. Handoff to CR-7 if customer insists on reship or D+5 stale. No bot reship.
System prompt
"Source of truth = carrier API last_scan. Never say lost before TRACK-ERR threshold. Escalate bot_track_dnr after 48 h procedure." Quarterly review with #397 owner.
How do I connect Shopify and the carrier API to the bot?
The carrier tracking bot integration requires real-time dual lookup.
Shopify Read-only Fields
fulfillment_status: reroute prep if unfulfilled
tracking_number, tracking_company
fulfillment created_at: ship_date reference
fulfillments count: split detect → #357
shipping_method: express vs standard threshold
Shopify Fulfillment API (Shopify Dev, Fulfillment).
Carrier API Fields
last_scan_at, last_scan_location, last_scan_status
days_since_last_scan: bot calculation CB-5
exception_code: address, customs, damaged, RTS
estimated_delivery: if carrier provides, cite source
delivered_at: for bot_track_dnr
Aggregators
AfterShip, ShippyPro, Malomo: unified API for 1000+ carriers. Heeya cites 80% WISMO automation with carrier API vs 40% Shopify alone (Heeya, tracking bot 2026).
CB-2 Identity Verification
Logged-in order match. Guest order_id + email. Do not expose third-party tracking.
Cache and Freshness
Carrier lookup cache 15 min max. Stale calculation based on API timestamp, not Shopify lag.
Webhook Exceptions
Carrier exception webhook → proactive bot message if client opted-in to notifications.
How to route to an agent without promising a reship?
The handoff bot track agent transmits the CARR-FLOW context without over-promising.
CB-7 Handoff Criteria
Stale > 96 h + customer insists on reship
bot_track_dnr: 48 h procedure elapsed, still missing
bot_track_invalid_number: ops verification label required
bot_track_mismatch: confirmed discrepancy via dual lookup
3+ insistence messages post-CB-6
Threat of chargeback or lawyer
Minimum Ticket
order_id, tracking, carrier, last_scan, days_stale, bot_track_type, exception_code, ship_date, transcript, dnr_procedure_complete Y/N, reship_request Y/N.
CB-7 Waiting Message
“Your file TRK-[ID] has been forwarded to our logistics team. Carrier investigation opened. Update within 24-48 business hours. We cannot reship a package directly from the chat without full verification.”
Bot vs Agent SLA
Bot CB-1 to CB-6: < 3 min, < 10 messages
Agent CR-7+: 4 h first response track_err
DNR Bot Timer
bot_track_dnr_started tag + timestamp. Bot follow-up at D+2 if customer returns. Auto-handoff if 48 h + NOT RECEIVED confirmed.
Post-handoff Bot Silence
No "did you receive the reship?" before the agent. Carrier status lookup OK.
Which WISMO triggers and router for CARR-BOT?
The bot tracking anomaly deployment is activated on stale signals and exceptions.
Five CARR-BOT triggers
T1 Incoming message: blocked, frozen, lost, not received, invalid tracking
T2 Order status exception badge: AfterShip stale flag on tracking page
T3 WISMO #184 reroute: post-lookup stale 72 hrs+ → CARR-BOT
T4 Email "tracking not moving": deep-link chat CB-2
T5 Proactive webhook: carrier exception → opt-in customer message
Router upstream WISMO #184
Flow #184: lookup carrier → if days_stale < 72 hrs AND in_transit → wismo_eta branch. If stale OR exception OR delivered+DNR → CARR-BOT. If unfulfilled → PREP-BOT #396.
Priority pages
Order status / tracking page with chat widget
Email shipping confirmation reply-to
/pages/suivi-commande FAQ anomalies
Split multi-tracking
CB-3 loop fulfillments if count > 1. Ask which package is concerned. Reroute #357 if manifest confusion.
24/7 value
64% track_err outside #398 hours example. Bot CB-6 stale immediate reduces overnight tickets.
A/B test
T2 exception badge vs passive. Measure track_bot_resolution and track_false_lost 60 d.
Which track_bot KPIs should be measured?
The KPI bot tracking anomaly links automation, FCR #397, and premature reship.
Eight key metrics
track_bot_resolution_rate: resolved without handoff / bot track sessions
track_bot_intake_complete: dual lookup OK / sessions
track_false_lost_promise: bot "lost" incidents (target 0)
track_bot_handoff_rate: agent escalations / sessions
track_bot_handoff_complete: 10-field complete ticket
track_bot_reroute_accuracy: prep/wismo/split/customs correct
track_err_fcr_delta: increase FCR #397 with bot
track_bot_csat: satisfaction post CB-6
DTC Benchmark
track_bot_resolution 72-80%, false_lost_promise 0, intake_complete 90-95%, handoff_rate 20-28%, track_err_fcr +12-16 pts at 90 d.
Weekly support + ops dashboard
Top intents bot_track_*, handoff reasons, correlation days_stale vs resolution, premature_reship post-bot (must remain 0).
20/month transcript audits
Score: last_scan cited? not prematurely lost? reship not promised? dual lookup? reroute prep OK?
Incident alert
track_false_lost_promise > 0: pause LLM free CB-6, prompt review 24 h.
Which edge cases and anti-patterns should be avoided?
Ten bot track edge cases and playbook responses.
1. Bot confirms package lost stale D+3
Critical incident. Hard block "lost" before 10 days or carrier confirmation. Immediate audit.
2. WISMO #184 and CARR-BOT both reply
Single upstream router. No double contradictory messages.
3. Shopify in_transit, carrier stale 5 days
Carrier API takes precedence. Explain possible Shopify lag. Cite carrier last_scan.
4. DNR without 48 h timer
bot_track_dnr_started mandatory. Handoff only post-procedure.
5. Split: stale package 2, customer looks at package 1 delivered
Manifest fulfillments CB-3. Reroute #357 if confused.
6. Relay awaiting pickup read as lost
bot_track_relay_awaiting: pickup deadline, relay address.
7. Customs hold = reship bot
Reroute #65. Waiting for customer documents.
8. LLM invents "Lyon" hub without API
Guardrail: only last_scan_location from carrier in CB-6.
9. Express stale 48 h processed at 72 h
Read shipping_method order. Dynamic threshold CB-5.
10. Prep unfulfilled → stale message
Reroute PREP-BOT #396. No track_err on unshipped items.
Anti-patterns
WISMO bot #184 without stale branch → CARR-BOT
TRACK-ERR #397 without threshold metafields for CB-5 bot
No dual lookup before CB-6
How does Qstomy explain blocked tracking statuses?
Qstomy on Shopify: CARR-BOT with dual lookup, days_stale calculation, CB-6 grounded last_scan templates, DNR procedure, prep/wismo/split reroute, CARR-FLOW handoff without auto reship.
CARR-BOT Qstomy Capabilities
track_intent_detect: 12 intents section 3
track_dual_lookup: Shopify + AfterShip/carrier
track_stale_calc: threshold express/standard CB-5
track_explain_template: last_scan plain language
track_no_lost_promise: hard block before threshold
track_dnr_procedure: guided 48 h timer
track_handoff_ticket: CR-5+ brief agents #397
track_wismo_router: reroute #184 if normal transit
Addendum #397 and #184
CARR-FLOW agents claims and reship. WISMO bot #184 standard ETA. Qstomy CARR-BOT bridges anomaly gap 24/7. track_err_fcr +14 pts combined.
Quantified DTC Scenario
Fashion brand, AfterShip, 94 track_err/month, 64% off-hours.
After Qstomy CARR-BOT: track_bot_resolution 78%, track_false_lost_promise 0, track_bot_intake_complete 94%, premature_reship -39%, track_bot_csat 4.3/5.
Explore customer support and request a demo.
What is the checklist for deploying CARR-BOT?
CARR-BOT Checklist (12 steps)
Document policy TRACK-ERR #397 + stale thresholds
Connect carrier API or AfterShip to the bot
Configure 12 intents bot_track_* section 3
Draft templates CB-1 to CB-8 + TRACK-STALE/DNR
Implement dual lookup CB-3 + days_stale CB-5
Activate guardrails no_lost_promise + no_reship_promise
Integrer router WISMO #184, prep #396, split #357, customs #65
Configure triggers T1-T5 + exception badge T2
Staging tests for 12 scenarios: stale, DNR, invalid, mismatch, relay
Handoff ticket 10 fields to CARR-FLOW agents
Weekly track_bot KPI dashboard
Audit 20 transcripts/month + correlate false_lost
In short
#398 = tracking anomalies bot, #397 = claims/reship agents
CARR-BOT: dual lookup → stale calc → explain → handoff
Grounded last_scan: never lost nor reship promised by bot
Router: normal WISMO #184, prep #396, split #357
track_bot_resolution KPI: target 72-80%
FAQ
Difference with #397?
#397 policy TRACK-ERR + CARR-FLOW agents + carrier claims + reship. #398 bot automation CB-1 to CB-7.
Difference with #184 WISMO?
#184 ETA and normal tracking status link. #398 stale, DNR, invalid, carrier exceptions.
Can the bot resend a package?
No. Agent CR-7 handoff after TRACK-ERR threshold. Zero bot reships.
Relationship to prep #396?
Unfulfilled → PREP-BOT. CARR-BOT only for fulfilled with tracking.
Relationship to insurance #361?
Bot investigates first. SHIP-INS claim after agent-confirmed loss.
Going further
Staging test: "tracking stuck for 5 days" + fulfilled order_id, verify CB-6 last_scan is cited, zero "lost", handoff if reship is insisted upon.
Share this guide #398 with support and logistics: the right tracking bot explains the carrier anomaly, it does not replace the ops investigation.
Enzo
July 1, 2026
