“Where is my order?” looks like a small support request. Someone opens the shop backend, checks the shipment, copies the tracking link and replies. Then another customer asks the same thing.
By the end of a busy afternoon, your team has spent a lot of attention translating information that already exists. Customers have spent their time waiting for it.
Order-status automation is a useful first project because the job is specific: identify an authorized customer's order, read the latest available facts, explain them and route exceptions. The tricky cases are the ones worth planning for.
What WISMO means, and why a tracking link may not answer it
WISMO stands for “Where is my order?” In practice, it covers several questions. Has the order been dispatched? Why does tracking only show a label? Is one item arriving separately? The carrier says delivered, but where is the parcel?
A tracking link can answer some of these. Others require the shop's fulfillment state, information about a split shipment or a delivery exception. Start by reviewing your actual inquiries and separating those categories.
Also check the ordinary customer journey. Make the tracking link easy to find, explain expected dispatch times and keep your account page useful. A chatbot cannot compensate for missing shipment data or consistently confusing delivery messages.
An external case worth looking at: Skullcandy
In its published Skullcandy case study, DigitalGenius reports handling 80% of WISMO queries and shortening responses across WISMO, troubleshooting and warranty inquiries. These are vendor-reported results from that implementation. They are not a forecast for another store or results achieved with my plugin. The useful takeaway is the deliberately bounded set of support jobs.
For your pilot, begin with an order lookup and clear exceptions. You can evaluate that against real inquiries before adding order changes or other actions.
Build an answer from shipment facts
Your internal status names may be useful to warehouse software and confusing to a customer. Map them to statements that accurately describe what happened.
| Available fact | Useful explanation | What remains uncertain |
|---|---|---|
| Order accepted; no dispatch event | The order is being prepared | A dispatch date unless the shop provides one |
| Shipping label created | A label has been prepared | Whether the carrier has collected the parcel |
| Carrier acceptance scan | The carrier has received the parcel | A delivery date unless the carrier supplies an estimate |
| Some items dispatched | The order is arriving in separate shipments | The remaining items' status unless it is available |
| Delivered scan; customer disputes receipt | The carrier reports delivery | What happened at the address; send this for review |
An estimated arrival should stay an estimate. Include the source and update time where useful. A missing carrier event is not evidence that the parcel is lost, and a generated label is not evidence of collection.
For a Laravel-backed store, I would expose only the fields needed for this answer: a customer-facing order reference, shipment state, affected items, approved tracking link and available timestamps. Delivery details and internal warehouse notes need their own disclosure policy.
Keep customer identity out of the guessing game
An order number selects a record. It does not prove who may read it. The host application must bind the lookup to a trusted customer identity or another deliberately implemented verification process.
Inside a signed-in account, the application can scope the lookup to the current customer's orders. For a separate storefront widget, use trusted server-issued context. A customer typing “my account is 42” should never grant access to account 42.
If identity cannot be established, offer the normal account login or a human support route. Avoid revealing whether an unrelated person's order exists. This is part of the lookup design, not something to leave to wording in the system prompt.
A conversation that leaves the customer with a next step
Here is an illustrative conversation, using invented order data:
Customer: My order still says processing. Has it shipped?
Assistant: One shipment has been handed to the carrier. The second is still being prepared. I can show you which items are in each shipment.
The answer is useful because it reads both shipment records. If the customer then reports an address problem, the workflow changes. A status lookup is complete; a potential order modification needs a separate authorized process.
For a “delivered but missing” inquiry, collect the relevant details and hand the case over with the order reference, shipment event and customer's description. The next support agent should not have to start discovery again.
Use the language the customer understands. “Awaiting carrier acceptance” can be explained as “A label has been created, but there is no collection scan yet.” That translation does not need an invented dispatch promise.
Where a chatbot fits alongside a tracking page
A status page works well for routine checks. Conversation becomes useful when the customer needs an explanation, has several shipments or wants to report an exception.
Gorgias documents an order-management portal whose available options depend on the particular order. The transferable idea is to show relevant next steps from actual order attributes. Your own implementation should use its business rules to decide which actions are available.
Place the assistant where these questions arise: the account area, order page or help center. Starting with those entry points gives the pilot a clear audience.
A practical setup for Laravel teams
With Filament Agentic Chatbot, I would use an Agent with approved shipping-policy knowledge and a customer-scoped Data Resource for application-owned order information. An API Connector can read a separate order or carrier service once that integration has been configured.
The host still owns identity, access rules and business data. Carrier integrations need to be implemented or configured; the plugin does not automatically supply a connection to every shipping provider.
Keep the first release read-only apart from a deliberate support handoff. If you later add a modification request, show the exact proposed change and require confirmation before execution. An optional Playbook can provide a defined escalation or exception process.
The general tool boundary is covered in my Laravel API-calling guide. This article's narrower job is turning shipment data into an accurate customer answer.
Test the awkward orders before the busy season
Use fixtures for an ordinary shipment, a split order, a canceled order, a label with no collection scan and an outdated carrier response. Add an unrelated customer's order to verify that it remains inaccessible.
Make the carrier API fail. The assistant should explain that the current status could not be checked and offer a suitable next step. Reusing yesterday's response without saying so can be worse than a short failure message.
Check a mismatch between the shop and carrier states. Define which system owns each fact instead of letting the model settle the disagreement. Finally, verify that human handoff includes the useful context and that any added write action is not duplicated after a timeout or repeated click.
Count resolved inquiries, including repeat contacts
Start with the WISMO share of your support inquiries and the time needed for a manual lookup. After launch, review the proportion answered accurately, the handoff reasons and customers who contact you again about the same order.
A closed conversation is not automatically a resolution. A customer may leave because the bot was unhelpful. Review a sample of answers and repeat contacts alongside your automation figures.
Segment ordinary status checks from lost parcels and other exceptions. Expecting both groups to have the same resolution rate will hide where the process actually needs attention. Compare similar periods and inquiry categories.
One reliable lookup, honest status wording and a prepared human handoff make a solid first release. Add more responsibility when those pieces work with your real orders.
Questions about order-status automation
Do I need AI for every tracking request?
No. A status page or a fixed lookup can handle straightforward checks. AI is useful for interpreting the question, explaining the available facts and collecting context for an exception.
Can a customer give an order number in a public chat?
They can provide a reference, but access still requires a trusted identity or your implemented verification process. The reference itself is not authorization.
Should the assistant cancel orders or issue refunds?
Start with status information. Each additional action needs its own eligibility rules, permission checks, confirmation behavior and recovery handling.