Order notifications on WhatsApp, without writing an integration

The three order events worth a WhatsApp message are confirmed, on its way, and arrived or ready. Sending more than that is how a useful channel turns into the one people mute - and each message should be answerable, because a reply is worth more than a delivery receipt.

Why these three and not the eleven your shop emits

An e-commerce platform emits status changes for its own benefit: payment authorised, payment captured, on hold, processing, completed, note added. Most describe internal bookkeeping. The customer's mental model has three states - did it work, where is it, is it here - and messages that do not answer one of those spend attention without buying anything.

What each message should say

Confirmed

Sent immediately, because the anxious moment is right after paying. It must contain the order reference and what happens next, with a time.

Hi Wanjiku, we have your order #10432 - two tyres,
195/65 R15. We will pack it today and message you when it
leaves the shop. Reply here if you need to change anything.

On its way

The one people actually want. Include a tracking reference if you have one, and the courier's name, which is what they need when somebody knocks.

Arrived, or ready for collection

For collection, say the hours and the address. For delivery, this is the message that closes the loop and is the natural place to ask for one thing - a review, a photo, a reorder reminder. One thing, once.

The mistakes

• Sending from a number nobody can reply to. A notification you cannot answer is an email with worse manners. If the customer replies "can you leave it with the neighbour", somebody has to see it.
• Including a marketing line in a transactional message. It changes the legal basis, the WhatsApp template category, and the customer's opinion of you.
• Sending at 03:00. Order events fire whenever the warehouse system runs. Quiet hours are worth implementing before the first night shift, not after.
• Re-sending on every status write. Plugins that hook a generic status-changed event will send four messages when a colleague edits an order four times. Send on transitions into a state, once, with a deduplication key.
• Assuming the phone number is valid. Checkout fields collect all sorts of things. Normalise to E.164 and check before sending, or your failure rate becomes a deliverability signal.

Which rail

Order updates to somebody who just bought from you are the friendliest traffic there is: expected, relevant, and usually answered. Either rail handles them. On the Cloud API they are utility templates and carry a per conversation fee. On the Web protocol they are ordinary messages from your own number, with no fee, and the constraint is behavioural rather than billed.

Njiwa's shop integrations are listed on the integrations page, and every event in every one of them is off until somebody switches it on - which is the setting that stops the eleven event problem at the source.