E-commerce

AI chatbot for carrier tracking: explaining blocked statuses and the next steps

AI chatbot for carrier tracking: explaining blocked statuses and the next steps

July 1, 2026

A blocked carrier tracking is one of the most stressful post-purchase situations. The customer sees the same status for several days, doesn't know if the package is still moving, and contacts support to understand what is happening.

The chatbot can reassure them if it explains the statuses, normal delays between two scans, and the next steps. It must also know when to open an investigation or escalate to support.

This guide shows how to manage carrier tracking with an AI chatbot, without promising a date that the brand does not control.

Summary

Why does a blocked tracking status worry the customer?

For the customer, tracking is the only proof that their order is moving forward. If the status remains frozen, they quickly imagine a lost, stolen, or forgotten package.

However, tracking can remain motionless without being abnormal: lack of intermediate scan, transfer between hubs, weekend, customs, carrier overload, or update delay.

The chatbot must explain what the status means and what should happen next.

Convert over 2,000 customers on average per month with Qstomy.

The world’s 1st Shopify AI dedicated to customer conversion

Empowering 200+ e-commerce merchants

Which statuses should be recognized?

The bot must recognize statuses such as shipped, in transit, picked up, arrived at hub, out for delivery, delivered, failed delivery, exception, return to sender, and awaiting customs.

It must also take into account the carrier, the country, the delivery type, and the date of the last scan. The same status can be normal after 12 hours and worrying after 6 days.

How can an absent scan be explained?

The bot can explain that a package is not scanned at every stage. Some routes have few updates, especially during long-distance transfers or peak activity periods.

A good response provides a reference point: "The last scan was on [date]. At this stage, it could still be a normal delay. If no new scan appears by [timeframe], we can initiate a check."

What to do in case of a delay?

The chatbot must compare the estimated delivery date with the actual tracking. If the package is still within the expected window, it reassures the user. If the deadline has passed, it proposes an action.

The action can be a carrier check, an investigation, a redelivery, a pickup point, or a transfer to support, depending on the brand's policy.

How to handle a package marked as delivered but not received?

This case must be handled with caution. The bot can suggest simple verifications: mailbox, neighbor, reception desk, drop-off point, or proof of delivery if available.

If the customer confirms that they have received nothing, the bot must transfer or launch the planned procedure. It must not accuse the customer or the carrier without proof.

Which flow to follow?

The flow must start from the actual status.

  1. Identify the order and the carrier.

  2. Read the last status, the scan date, and the estimated date.

  3. Explain the status in simple language.

  4. Determine if the delay is normal, monitored, or exceeded.

  5. Suggest the next step: wait, verify, investigate, or escalate.

Which messages should be used?

For a frozen status: "The last scan was on [date]. Some carriers only update the tracking at certain stages."

For a delay: "The estimated date seems to have passed. I can send a verification request to the carrier."

For a package marked delivered but not received: "Let's first check possible drop-off locations. If you still cannot find the package, I will forward your request along with the tracking."

When to transfer?

Transfer is necessary if the deadline has passed, if the status indicates an anomaly, if the package is marked as delivered but not received, if customs is blocking delivery, or if the customer has already contacted the carrier without a response.

The bot must transmit the order, the carrier, the tracking number, the latest status, the scan date, and the customer's exact request.

Which KPIs should be monitored?

Track blocked statuses, carrier delays, delivered but not received packages, opened inquiries, and conversations resolved without an agent.

These KPIs help identify the carriers or areas that generate the most uncertainty for customers.

Which mistakes should be avoided?

Avoid promising delivery on an exact date if the carrier does not guarantee it. Also, avoid replying with "contact the carrier" without explaining what the brand can do.

The customer bought from you. Even if the carrier is the one delivering, the brand must help them understand the situation.

How can Qstomy help?

Qstomy can read carrier statuses, explain blocked tracking, and transfer sensitive packages with all the necessary information.

The chatbot reduces customer anxiety and prevents agents from manually copying the same tracking information.

Explore AI support or request a demo.

CARR-BOT Checklist (12 steps)

  1. Document policy TRACK-ERR #397 + stale thresholds

  2. Connect carrier API or AfterShip to the bot

  3. Configure 12 intents bot_track_* section 3

  4. Draft templates CB-1 to CB-8 + TRACK-STALE/DNR

  5. Implement dual lookup CB-3 + days_stale CB-5

  6. Activate guardrails no_lost_promise + no_reship_promise

  7. Integrer router WISMO #184, prep #396, split #357, customs #65

  8. Configure triggers T1-T5 + exception badge T2

  9. Staging tests for 12 scenarios: stale, DNR, invalid, mismatch, relay

  10. Handoff ticket 10 fields to CARR-FLOW agents

  11. Weekly track_bot KPI dashboard

  12. 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

Convert over 2,000 customers on average per month with Qstomy.

The world’s 1st Shopify AI dedicated to customer conversion

Empowering 200+ e-commerce merchants

Subscribe to the newsletter and get a personalized e-book!

No-code solution, no technical knowledge required. AI trained on your e-shop and non-intrusive.

*Unsubscribe at any time. We do not send spam.

Subscribe to the newsletter and get a personalized e-book!

No-code solution, no technical knowledge required. AI trained on your e-shop and non-intrusive.

*Unsubscribe at any time. We do not send spam.