WhatsApp Order Notifications: Stop WISMO Before It Starts

Because the information exists and the customer cannot reach it. The order was confirmed in an email that went to the promotions tab, the tracking link sits three scrolls down inside that email, and the carrier page says "in transit" without a date. None of that is a service failure. It is an information design failure, and it produces a message.

The instinct is to build a better self-service page. The German numbers say that is the wrong move. Asked what they would like to use when there is a problem with an order, 62% of online shoppers named a quickly reachable human contact and 52% an email service — while only 28% would use an FAQ page on the website and 36% a chatbot (Bitkom, representative survey of 1,006 internet users aged 16 and over in Germany, fielded in weeks 1–3 of 2025, published 22 May 2025, retrieved 2026-09-30).

Satisfaction follows the same shape: 86% were satisfied after contact with a human, against 50% for a chatbot. So the self-service page you were about to build is the least wanted option on the list, and the bot is the second least.

Meanwhile "where is my order" — WISMO in the trade — is one of the most common post-purchase enquiries in e-commerce (Shopify, "WISMO Ecommerce: Meaning + 5 Strategies", 18 February 2025, retrieved 2026-09-30). Put the two together and you have the whole argument of this post: the most frequent question is also the one nobody wants to look up. So stop asking them to look it up. Send it.

Where the line between a rule and a person sits more generally is the subject of what to automate in customer service and what to leave alone. Order status is the clearest case on that list, because the answer is already sitting in a database.

Four things. A status message missing one of them generates the reply it was meant to prevent.

• The order, named. An order number on its own is a reference the customer has to go and look up. Add one product name and they recognise it in a second.
• Where it is, in plain words. "Handed to the carrier this morning" beats "fulfilment event registered". Carrier jargon is a large part of why people write to a human in the first place.
• When it should arrive. A date, or an honest "we will confirm the delivery date by Friday". A missing date is the single most reliable way to produce a follow-up message.
• One way to reply. The thread is the reply channel — that is the advantage over email. It only counts as an advantage if somebody is watching it.

Then send three messages across an order rather than one: confirmed, shipped, and — only when it is true — delayed. The delay message is the one most stores skip, and it is the one that buys the most goodwill, because it arrives before the customer has started worrying. A delay you announce is logistics. A delay they discover is a broken promise.

None of it is permitted without consent. An order event proves something happened; it does not establish that you may message that person about it. The platform rules Meta sets around opt-in, replies and templates are collected on our WhatsApp facts page. Treat a documented opt-in as a precondition of the flow, not as paperwork to tidy up afterwards.

Six steps. Two are plumbing and four are judgement, and the judgement ones are where this succeeds or quietly does nothing.

1. Make sure phone numbers reach Keaz. Without a number captured at checkout there is nothing to match an order to, and the flow simply does not start for that order. Capturing the phone number at checkout is the lever that decides how much of this ever runs.
2. Create the flow and pick the trigger. For "order placed", use the Contact Purchase trigger: Keaz starts the flow as soon as the order is registered in your connected shop and matched to a contact.
3. Write the confirmation message. Order named, expected delivery window, one sentence on what happens next. Send it straight away — this is the message that replaces the email nobody opened.
4. Fire the shipped message from the system that knows. Contact Purchase knows the order; it has no view of when the parcel left. Use the Webhook trigger so your fulfilment tool, warehouse system or backend sends the shipping event to Keaz. The payload is content as well as a signal, so the message can name the order that shipped instead of announcing that something shipped.
5. Set the delays deliberately. Conditions and delays live inside the flow, so a "still on its way" message can wait until day four rather than landing while the customer is still reading the confirmation.
6. Decide what happens on a reply — before you switch it on. Every one of these messages invites an answer. Name who sees it and how fast. This step is skipped more often than any other, and it is the one that decides whether the flow helps or backfires.

The two triggers are not interchangeable, and it is worth being exact about why. Contact Purchase is Shopify-based: it depends on your shop being connected, and it fires on the order. Webhook is tied to no particular system — anything that can send an HTTP request can start a flow with it. Choose by asking which system holds the fact you want to send. What Keaz actually does is deliberately narrow here: it automates the conversation layer, not your fulfilment. Keaz will not discover that a parcel shipped — something has to tell it.

Automation earns its place by clearing the repetitive traffic, so the people you already have arrive sooner at the conversations that need them. It does not earn its place by absorbing those conversations.

Four cases should never end at a machine.

• The parcel is genuinely lost. There is no status left to send, and sending one anyway reads as a brush-off.
• Money is moving the wrong way. Refunds, double charges, a failed payment. The customer is already out of pocket, and an automated reply looks like stalling.
• The conversation opens angry. Someone who is already annoyed does not read an automatic response as neutral. They read it as an escalation.
• Anything discretionary. A goodwill gesture, an exception to a returns deadline, a replacement outside the rules. Those are decisions, and decisions need someone accountable for them.

The satisfaction gap in the Bitkom data — 86% after contact with a human, 50% after a chatbot (Bitkom, May 2025) — is not an argument against automation. It is an argument for spending automation on the traffic with no judgement in it, and defending everything else. Order status is the purest example of traffic with no judgement in it: there is exactly one correct answer, and your systems already hold it.

Three measures, each taken before and after. None of them is "messages sent".

1. The share of incoming conversations that open with a status question. Read the last hundred threads and count them, then count again four weeks later. This is the number the whole exercise is aimed at, and it is the only one worth reporting first.
2. Time to first human reply, on the conversations that needed one. If the status messages have pushed this up, you have added traffic rather than removed it — whatever the first number says.
3. Repeat contacts on the same order. The same customer writing twice about one order means a message closed the thread without answering the question. Usually the missing piece is the date.

Read together, the three tell you whether you removed work or moved it. A flow that halves the status questions and doubles the reply time has helped nobody. Give it four weeks before you judge it — one purchase-and-delivery cycle is the shortest window in which any of these numbers means anything.

Six failures account for most status flows that end up reducing nothing.

• Sending a tracking link instead of a status. A link is another place the customer has to go. The point was to stop sending people places. Put the status in the message and the link underneath it.
• Announcing the delay only after being asked. At that point it is no longer information, it is a defence. Send it the day you know.
• One message for the whole order. Confirmed, shipped and delayed are three different moments with three different questions behind them. Collapsing them into one saves you nothing and answers none of them well.
• Treating opt-in as a checkbox. A weak opt-in survives until the first complaint and then it does not. Collect it properly at checkout, where the customer is already giving you the number.
• Automating the apology. An automatic response to a complaint reliably makes the complaint worse. Route it to a person; do not answer it with a rule.
• Counting sends. A rising send count next to a rising repeat-contact rate means the automation is producing work rather than absorbing it. Sends are an input, not a result.