Where Is My Order enquiries, often called WISMO, reveal a gap between the store’s promise and its information after purchase. Clear dates, understandable stages and proactive messages can prevent some questions. First establish which stage customers are asking about: preparing the goods, carrier collection or delivery. Each needs a different message.
Start with the promise before purchase
Open the product page, basket and purchase confirmation as a new customer would. Check whether “ships in two days” means parcel preparation or delivery. If different places give different conditions, customers will ask for individual clarification even when the warehouse is working exactly as planned. Correct the conflicting promise before adding another support channel.
Separate preparation time from estimated transport time and say which event starts each clock. Give a distinct condition for made-to-order items, separately assembled products or orders dispatched from several warehouses. Do not put a significant exception only in lengthy terms that the customer may not connect with the item they have selected. Before Christmas, the same rules have to become order cut-off dates; our guide to Christmas delivery order deadlines shows how to set them without promising a date you do not control.
Adapt this wording: “We prepare goods for dispatch within [time] after payment confirmation. Once the carrier receives the parcel, we send a tracking link. Estimated transit takes [carrier estimate].”
Fill those fields with your own confirmed information and avoid presenting a carrier forecast as a guaranteed delivery date. Any guarantee needs its own verified conditions.
Keep a visible way to ask about an existing purchase. Our separate guide to live chat for online stores explains where chat helps before and after the transaction. Fewer messages are a useful outcome only if customers genuinely receive the information they need rather than losing access to help.
Name the event behind the status
An internal warehouse status rarely answers the customer’s question by itself. “In progress” may include picking, packing or waiting for a missing item. Translate it into a confirmed event and a next step, distinguishing facts from estimates. That lets the team explain the situation without inventing a date from a label or confusing preparation with transport.
Scroll the table sideways to see all columns.
| Stage | What is confirmed | What the customer needs |
|---|---|---|
| Order accepted | The store recorded the order | Whether payment needs another action |
| Preparation | The warehouse is assembling the goods | Which preparation timeframe applies |
| Label created | A tracking reference exists | Whether the carrier has collected the parcel |
| Carrier collected | Transport has started | Where to view current tracking scans |
| Transport exception | A specific issue has appeared | Who is checking it and when an update will follow |
One example of this distinction: WooCommerce documents Processing as a paid order awaiting fulfilment, rather than proof of delivery. Check the meanings used by your own store: WooCommerce order statuses.
If you use WooCommerce, our guide to handling order enquiries sets out the operator’s workflow. This article focuses on information that prevents the question in the first place. Do not replace carrier evidence with a store state, or treat label creation alone as proof that the parcel has begun moving.
Prepare messages for actual stage changes
The purchase message should confirm the reference, goods, basic timeframe and access to further information. After dispatch, include the real tracking link and explain any gap before the first scan according to the carrier’s process. Test the link as a customer: a page that requires warehouse staff credentials is not useful to the recipient.
Adapt this dispatch template: “We handed order [reference] to [carrier] at [confirmed time]. Track the parcel at [link]. If transport information has not appeared by [time set by our process], reply to this message.” The check date should reflect your actual operating capacity rather than a promise copied automatically into every order regardless of carrier or route.
For a pre-dispatch delay: “We have not dispatched order [reference] yet because [confirmed reason]. Our current estimate is [new date]. We will update you by [update time], even if the plan changes.” This gives customers information before they need to chase it, while the team retains control of its next communication commitment. If the delay is caused by an item being out of stock, a new date alone is not enough; our guide to telling customers about a backorder shows which options to offer.
Conditional sentences and fields to verify help prevent an inappropriate assurance. Our guide to customer support response templates explains the approach. Before enabling messages, test partial orders, replacement shipments and address changes separately: a new event does not always mean the same stage, and a template should not conceal that distinction.
Before confirming a delivery address change, use the guide: Shipping address change: handle requests after an order is placed.
Give exceptions an owner and a next action
When tracking stops, do not send the customer back to the same link repeatedly. Check the last confirmed scan, its time and any known carrier message. Assign someone to contact the relevant party and set a customer update date. “Your parcel is on the way” does not answer a specific report that transport has stopped.
If tracking says delivered and the customer disagrees, record the discrepancy without guessing the cause. For a split shipment, identify which parcel contains the expected item. For a wrong address, establish whether a change is still possible. Further decisions should follow the store’s actual process and carrier evidence instead of an all-purpose reply that fits none of these situations well. If the customer wants to cancel an order that has not shipped yet, follow the guide on cancelling an order before dispatch.
Keep one main ticket for the particular problem and connect later messages to its history. If the customer returns after a reply, check whether they received only a status or also a way through the next obstacle. Our guide to repeat support tickets covers that analysis; do not count every contact as a new logistics problem.
Make contact easy when self-service is insufficient
Place a clear route for existing-order questions beside delivery information. Ask for a minimal case identifier and a short description of the discrepancy, then verify access using your own procedure. Do not require customers to paste addresses, documents or complete payment confirmations into a public chat just to locate the case. Collect only what the next step actually needs.
In Meetlead, conversations, assignments and notes can preserve agreements between operators. After checking status in the store system, record the confirmed fact and next update time in the case history. The team needs an account and suitable permissions; the inbox does not automatically read orders or carrier tracking scans.
When an operator is unavailable, show real response hours and an appropriate way to leave a message. A form should acknowledge receipt so the customer does not send the same enquiry repeatedly. If you state an expected response time, base it on actual coverage and a clearly explained calendar rather than an ideal day with an empty queue.
Check whether fewer questions mean less uncertainty
Tag preparation, transit and exception questions separately. Compare their rate against orders in similar periods so lower store traffic is not mistaken for better communication. Keep the definition stable: are you counting cases, customers or individual messages? This matters when one customer returns several times and several messages concern the same unresolved delivery. To convert every contact reason into a rate per 100 orders and pick two to fix, see the guide to contacts per 100 orders.
Review a small sample of replies after changing the messages and check whether the customer could take the next step without clarification. Your own worksheet can record stage, missing information, confirmation source and the reason for a later contact. This reveals useful message changes rather than encouraging the removal of a contact button to improve the counter.
Questions about communication after purchase
Is a tracking number enough? Only if it works, points to the correct parcel and makes the stage understandable. If a label exists but transport has not started, explain the difference. For several parcels, show which one contains the product the customer is asking about.
Can a chatbot answer about a specific order? Only if the solution has verified access and an appropriate identification process. A knowledge base on its own describes general conditions, not the current state of a private transaction. Do not present its answer as a check of store data.
Where can we start without a new integration? Align the delivery promise, test messages and links, and prepare one exception message with an update commitment. Then compare real conversation questions and improve the missing information in the place customers most frequently visit.
