“Where is my order?” is the most common message an online store receives, and order status automation is the one piece most worth building, because unlike most questions the answer already exists in a system you own. Nobody has to decide anything. Somebody just has to look it up.
That makes it the right first automation in almost every store: highest volume, zero judgement required, and a result the customer can verify. It is also the flow that convinces whoever is sceptical about automation, because the reply contains a real date rather than a promise to check.
This is the build, including the parts that go wrong. For the rules about when you may send any of it, see e-commerce DM automation.
Key takeaways
- A webhook turns the order number into a real answer mid-conversation instead of a promise to get back to them.
- This flow runs inside the messaging window by definition – the customer started it – so it needs no templates and no opt-in.
- It draws on the free monthly service message allowance, so for most stores it costs nothing.
- The hard part is not the lookup. It is what the flow does when the order number is wrong, missing or ambiguous.
- Ask for the order number before you need it, not after a round trip.
- Anything the lookup cannot answer should reach a person with the conversation attached.
Why This One First
Three reasons, and the third is the one that gets the project approved.
The Answer Already Exists
Most questions worth automating require you to decide something – whether to offer a refund, whether a product suits someone. This one does not. The delivery date is a fact sitting in your store or your carrier’s system, and the only work is retrieval.
That makes it safe to automate completely. There is no judgement for an automation to get wrong.
It Is Pure Volume
In most stores it is the single largest category of inbound message, and it clusters exactly when nobody is working – evenings, weekends, and the three days after a promotion.
It Is Verifiable
The customer can check the answer. That matters internally: a flow whose output is a real tracking date is one your team will trust, which is not true of a flow that sends a cheerful acknowledgement.
How the Lookup Works
Four steps, one of which is somebody else’s code.
Trigger and Capture
The flow triggers on a keyword – ORDER, TRACK, WISMO, whatever your customers actually type, including the misspellings. It then asks for the order number and waits for the reply.
Ask for the number in the first message rather than after a greeting. Every extra round trip loses people, and the customer already knows why they are here.
Call the Webhook
The flow calls your endpoint with the order number and the customer’s details. Your endpoint does whatever it needs to – query Shopify, query the carrier, join the two – and returns a result.
What comes back is then delivered in the conversation. This is the whole trick, and it is why the flow can give a real date instead of a generic reassurance.
Keep the endpoint fast
The customer is waiting in a chat. A lookup that takes eight seconds reads as broken even when it works.
Return something sendable
Shape the response into the sentence you want sent, rather than returning raw JSON and trying to format it in the flow.
Branch on the Result
Shipped, not yet shipped, delivered, not found. Each gets its own reply, and each reply should say what happens next rather than only stating a status.
“Delivered on Tuesday” invites a reply from someone holding nothing. “Delivered Tuesday – if it is not with you, reply HELP and we will sort it” closes the loop.
What Each Result Should Do
The branches people skip are the bottom two, and they generate the angry messages.
| Lookup result | What the reply should contain | Then |
|---|---|---|
| In transit | Carrier, tracking link, expected date | Offer the tracking page |
| Not yet shipped | Honest dispatch estimate | Offer to notify on dispatch |
| Delivered | Date and where it was left | Explicit route to a human |
| Not found | Ask them to re-check the format, once | Then a person, not a loop |
| No reply with a number | Nothing | Hand to a person after one nudge |
Anything that ends in a complaint should carry the whole conversation to whoever picks it up – see AI to human handoff.
Building It
Half a day including the endpoint, less if you already have an API.
- Collect the real keywords first. Read a month of your inbox and write down exactly how people ask. It is rarely the word you would have chosen, and it is often three words.
- Ask for the order number immediately. One message, one ask. Include an example of the format so you get fewer malformed replies.
- Build the endpoint and shape the response. Return a ready-to-send sentence, not raw data. Handle the not-found case explicitly rather than returning an error.
- Wire the webhook into the flow and branch on the result. Four branches minimum: in transit, not shipped, delivered, not found.
- Add one retry, then a person. If the number does not resolve, ask once more and then escalate. Never loop.
- Test with a real order and a deliberately wrong number. The wrong number is the test that matters, because that is the path that produces complaints when it is missing.
Doing It With DMpro
Specifically what the product provides here.
Webhooks and Waits
DMpro can call a webhook mid-flow and deliver the response back into the conversation, and flows can wait for a reply, branch on it, pause between steps and cap how often somebody is contacted.
That combination is all an order-status flow needs. It works on WhatsApp, Instagram, Messenger, Telegram and TikTok, with the usual channel differences – none of it depends on an AI step.
Where It Stops
It cannot message somebody who has not contacted you, so a proactive dispatch notification is a template, not this flow. And AI replies are not available on the WhatsApp channel, so on WhatsApp this runs on keywords – which for a lookup flow is the right shape anyway.
What This Flow Teaches You About Everything Else
The first automation is also a diagnostic, and most stores never read the result.
The Volume It Removes Is a Number You Can Use
Once the flow is running, you know exactly how many order-status messages arrive each week, when they peak, and what fraction your team was answering by hand. That is the clearest cost case anyone in this category ever gets, because it is work removed rather than revenue attributed – the distinction explored in DM ticket deflection.
Write the number down before you launch anything else. It is the baseline every later flow gets compared against.
The Escalations Are Your Next Roadmap
Every message that falls through to a person is a flow you have not built yet. Read a month of them and the list writes itself – usually returns, usually delivery exceptions, occasionally something about sizing nobody anticipated.
This is also where you find out whether the handoff itself works. A person picking up a conversation should see everything the automation already said, which is the whole argument in the handoff to a human.
It Exposes Your Response-Time Reality
Before automation, median response time is invisible because nobody measures the messages nobody answered. Afterwards you have a clean split: instant for the automated category, and whatever your team actually manages for the rest. The second number is usually worse than anyone believed, and it is the one that predicts reviews – the subject of social media response time.
Answer “Where Is My Order” Before Anyone Reads It
It is the most common message your store receives, it arrives at the worst hours, and the answer is already sitting in your system. Nobody should be copying tracking numbers by hand.
DMpro takes the order number, looks it up through your own webhook, and sends back a real date – then hands anything unusual to a person with the conversation attached.
Conclusion
Order status is the first thing to automate in almost any store. The volume is highest, the answer requires no judgement, and the result is something the customer can verify – which is what makes the rest of the programme credible internally.
The lookup itself is the easy half. The half that decides whether customers like it is the branching: an honest estimate when it has not shipped, a clear route to a human when it says delivered and they are holding nothing, and exactly one retry on a bad order number before a person takes over.
Build the wrong-number path first. It is the one that generates complaints when it is missing, and the one most flows never had.
Frequently asked questions
Can a DM automation look up a real order status?
Yes. The flow asks for the order number, calls a webhook you control, and delivers the response back into the conversation – so the customer gets a real date rather than a promise to check.
Do I need templates or opt-in for this?
No. The customer started the conversation, so you are inside the messaging window. Templates and opt-in are only needed to message someone who has not written to you.
What does it cost?
These are service messages, and every business phone number gets 1,000 of them free each month. For most stores an order-status flow costs nothing.
What should happen if the order number is wrong?
Ask once more with an example of the correct format, then hand the conversation to a person. Never loop – a flow that keeps asking is worse than no flow.
Can it notify customers when an order ships?
Not as part of this flow. A message to someone who has not written to you is outbound, which needs an approved utility template with opt-in.
Does this work on WhatsApp?
Yes. Webhooks, waits and branching all work there. AI replies are the thing that does not – WhatsApp flows are keyword-driven, which suits a lookup flow fine.
