Implementation
Automate WISMO on Shopify Without a Fake Chatbot Win
Classify where-is-my-order tickets, fix Shopify tracking emails, look up live status, and escalate exceptions without inventing ETAs.
A customer who asks “where is my order?” is not asking for a shipping-policy paragraph. They want the status of *this* parcel, in language that matches what the carrier last scanned. Most stores already have the data. The ticket exists because the shopper cannot see it, does not trust it, or hit an exception the bot was never allowed to name.
This playbook is the decision system. The order-tracking tools article stays the vendor shortlist. The repetitive-ticket guide stays the wider automation map. Here the job is one intent: WISMO.
WISMO means “where is my order?” It covers post-purchase questions about whether the order shipped, where the parcel is, when it will arrive, and why tracking looks stuck. The WISMO glossary entry is the definition. This page is the operating procedure.
Do not start with a chatbot script. Start with classification, live lookup, a status-to-answer map, and a hard stop for exceptions.
Classify the ticket before you automate the reply
One WISMO tag hides several jobs. A single macro fails half of them.
| Subtype | What the customer is really asking | Data you must have | Default move |
|---|---|---|---|
| Paid, not shipped | “Did you forget me?” | Order paid date, fulfill-by promise, warehouse cutoff | Honest processing status, not a fake tracking number |
| Label created, not scanned | “Why hasn’t it moved?” | Fulfillment date vs first carrier scan | Explain label-vs-pickup. Do not say it is on a truck if it is still in the warehouse |
| In transit | “When does it arrive?” | Last scan, estimated delivery if the carrier provides one | Status plus tracking link plus next expected scan window |
| Stuck / no scan | “Is this lost?” | Hours since last event, carrier exception codes | Exception notice. Escalate if your silence window is exceeded |
| Out for delivery | “Will it come today?” | Out-for-delivery event | Confirm the event. Do not invent a time window the carrier did not give |
| Delivered, package missing | “The app says delivered.” | Delivery scan, photo if the carrier has one, address | Human path. Investigation window. No cheerful “it should be there” |
| Split shipment | “Why is only one item moving?” | Line-level fulfillments | Name each parcel. Never average two tracking numbers into one story |
| Address or cancel request | “Can you stop or redirect it?” | Fulfillment state, carrier intercept rules | Tool only if the order is still stoppable. Otherwise escalate |
| Customs / international hold | “Why is it in another country?” | Broker events, duties policy | Policy plus documents. Human if documents are missing |
If your helpdesk cannot tag these subtypes, automation will report a heroic containment rate while delivered-not-received cases rot.
Build the prevention layer Shopify already ships
The cheapest WISMO ticket is the one that never opens. Shopify already sends the bones of that system.
Shopify's order tracking help says that after you fulfill an order and add a tracking number, customers can follow the shipment on the order status page, in shipping emails, and in the Shop app.
Shopify's customer notifications list the events that matter for WISMO:
- Order confirmation
- Shipping confirmation when you fulfill
- Shipping update when tracking information changes
- Out for delivery when the carrier or fulfillment app reports that event
- Delivered when the carrier or fulfillment app reports delivery
Shopify also warns that tracking-event sources, accuracy, and timing vary by carrier. Out-for-delivery and delivered mail is only as honest as the scan.
Custom templates are a silent failure. Shopify's order status email setup says a customized confirmation or shipping template can drop the order status link unless you add {{ order_status_url }}. Audit that before you buy another tracking app.
Week-1 prevention checklist
- [ ] Shipping confirmation still includes the order status URL.
- [ ] Tracking numbers are added at pickup or first scan, not when the label PDF prints if the bag is still on the bench.
- [ ] Customers can reach the order status page from email, account login, or order number plus email or phone.
- [ ] Guest checkout orders still have a lookup path.
- [ ] Split fulfillments create separate tracking stories.
- [ ] Out-for-delivery and delivered notifications are on only if you accept carrier-scan quality.
- [ ] Marketing delivery promises match warehouse cutoffs, not the brochure's best case.
If those boxes fail, a chatbot will answer from a broken source.
The label-created lie
Many 3PLs mark an order fulfilled when the label PDF is created. The bag can sit on a bench until the evening pickup. The shopper receives a shipping email, opens tracking, and sees nothing. That ticket is not a chatbot problem. It is a definition of “shipped.”
Agree with the warehouse on the event that is allowed to trigger shipping confirmation: first carrier scan, or the moment the bag is in the outgoing cage. Until that contract exists, every automated “it’s on the way” answer trains customers to distrust you.
Gift orders add a second lie. The purchaser has the confirmation. The recipient has a box and no email. Authenticate the purchaser for cancel and address changes. Give the recipient a limited lookup that does not expose payment details. Do not make the bot treat those two people as one identity.
Authenticate, then look up. Never guess.
A WISMO agent that recites “5–7 business days” is an FAQ. A useful agent calls a tool.
The minimum tool is read-only: identify the shopper, fetch the order, fetch fulfillment and carrier events, return structured status. Shopify's FulfillmentEvent API is one way to read those events. Your helpdesk or AI vendor may wrap the same data. The rule does not change.
Authenticate first. Shopify already supports account login, the emailed tracking link, or order number plus email or phone on the order status page. Your bot should not be looser than that. Gift orders and guest checkout need an extra beat, not a skipped check.
On lookup failure, stop. “I cannot find that order” plus a human path is correct. A fabricated tracking number is a trust incident.
Filter the payload. The model does not need payment instruments, internal notes, or cost prices.
Write tools stay behind a gate. Address changes, cancels, and refunds are not WISMO containment. They are money moves. Confirm, log, and often escalate.
Run the order-context test on staging: split shipment, partial fulfill, cancelled line, exchange, and a delivered-not-received case. If those fail, the bot is not ready for production.
Use a status-to-answer wall
Give every carrier-ish state a sentence the brand will stand behind. The bot does not improvise.
| State you can prove | Customer sentence | What you must not say |
|---|---|---|
| Paid, unfulfilled, inside promise | “We have your order. It is in the warehouse and has not shipped yet.” | “It's on the way.” |
| Fulfilled, no first scan | “A label was created on [date]. The carrier has not scanned it yet.” | “The driver has it.” |
| In transit, fresh scan | “It is in transit. Last scan: [place], [time]. Track it here: [link].” | A clock time you do not have |
| In transit, stale scan | “Tracking has not updated since [time]. We are treating this as an exception.” | “It should arrive tomorrow” |
| Out for delivery | “The carrier marked it out for delivery.” | A one-hour window unless the carrier published one |
| Delivered, customer agrees | “The carrier marked it delivered. If something is wrong, reply and we will open a claim.” | Nothing extra |
| Delivered, customer has no parcel | Escalate. Send the scan, address, and investigation steps to a human. | “Check with a neighbour” as the only answer |
| Exception / failed attempt | Name the exception. Offer pickup point or reattempt if that is real. | A new ETA you invented |
Print this wall. Put it next to the helpdesk. If a vendor demo cannot follow it, the vendor is selling tone, not resolution.
Measure tickets per 100 orders, not chatbot handles
Containment means the customer received a correct next step and did not come back about the same order inside your repeat window. Deflection that is really abandonment is a quality failure. The glossary already separates those words. Your dashboard should too.
Track this set:
| Metric | Definition | Why it exists |
|---|---|---|
| WISMO contacts per 100 fulfilled orders | Contacts tagged as a WISMO subtype, divided by fulfillments × 100 | Normalizes for growth and peak |
| Repeat contact on same order ID | Second contact within 7 days | Catches wrong answers |
| Prevention coverage | Share of fulfillments with a tracking email and a working status link | Predicts volume better than CSAT |
| Exception rate | Share of parcels with stale or failed scans | Tells ops where to spend |
| Escalation quality | Share of handoffs that include tool output | Stops agents from re-asking the order number |
| Delivered-not-received cycle time | Hours from report to claim or reship decision | This is the trust metric |
Do not publish a vendor's “X% of tickets automated” unless you sampled those conversations against live carrier truth. Automation that scales a wrong “out for delivery” scales refunds.
The ticket deflection estimator can size the workload. It cannot certify accuracy. Pair it with a weekly 25-ticket audit.
Phone and WhatsApp follow the same wall. A voice agent that cannot authenticate and look up is a hold message with extra steps. If you add those channels, reuse the subtype tags and the same tool. Do not write a second personality with a second set of promises.
Escalate on purpose
Automate the lookups. Keep humans for money, loss, and anger.
Escalate when:
- Delivery scan says delivered and the customer does not have the parcel past your investigation window
- High-value loss or suspected theft
- Customs documents are incomplete
- The customer threatens a chargeback and the data is incomplete
- The tool cannot find the order after a clean authentication attempt
- The shopper asks to cancel or change an address on a parcel that has already moved
The handoff packet is mandatory: transcript, authenticated identity, order ID, tool results, last carrier event, and the subtype. A human who has to ask “what's your order number?” is proof the automation failed the last mile of its own job.
A 30-day build
Week 1. Truth
Audit notifications and order_status_url. Measure current WISMO contacts per 100 orders by subtype. List the three carriers that create the most stale scans.
Week 2. Prevention
Fix label-created-as-shipped behaviour. Turn on the notifications you can defend. Publish a guest lookup path. Align marketing EDDs with warehouse cutoffs.
Week 3. Read-only automation
Ship authenticated lookup for paid-not-shipped and clean in-transit only. Log every tool call. Keep delivered-not-received on humans.
Week 4. Exceptions and audit
Add the stale-scan and exception sentences. Sample 25 automated conversations against carrier truth. Expand only if repeat contact on those orders did not rise.
WISMO is not a personality problem. It is a promise-tracking problem. Shopify already gives you a status page and a notification spine. Live lookup and an honest answer wall do the rest. A chatbot that cannot pass the order-context test is not automation. It is a second queue.
