Shipping notifications: what to send, when, and what to say when it breaks

Shipping notifications are the automated messages that track an order's journey to the customer: confirmed, shipped, out for delivery, delivered, and the ones in between. "Where is my order", exchange, and return queries statistically account for around half of all support tickets, and a decent notification cadence deflects the share of those where nothing is actually wrong. The rule I run every brand on, and the standard this whole page applies: tell the customer before they ask. Every time. Every order is a promise. Keeyu keeps it, and a notification is the promise talking to the customer while it is being kept. This page is the playbook: the milestones, the channels, and the messages that matter when things break, which is where proactive e-commerce operations, the system of action for e-commerce, earns its name.

The milestone set worth sending

• Order confirmed. Instant, with the delivery promise restated exactly as checkout showed it. This message sets the standard you will be held to.
• Shipped, with tracking. The workhorse. Send it on a real carrier scan, not on label creation, or you are teaching customers that your messages lie.
• Out for delivery. The one customers act on: someone checks the porch, moves the meeting. SMS earns its keep here.
• Delivered. Confirmation plus the next-step path if something is wrong, which quietly deflects the "it says delivered but" ticket.
• The delay notice. The milestone most stores never send, and the only one that builds real trust. If a promise is drifting, say so first, with a new date and what you are doing about it.

Channel split: email carries the record, SMS carries urgency, and the wider automation picture is on the customer service automation page. Send SMS for out-for-delivery and delays, email for everything, and never SMS a milestone the customer cannot act on.

The delay message: the template that matters

Three ready-to-use versions, by scenario, are on the delivery delay templates page.

Three sentences, in this order: we know. Here is the new date. Here is what we are doing about it. That is the whole template, and every word of padding weakens it. What makes it hard is not the copy, it is the trigger: sending this message requires knowing about the delay before the customer does, which is an operations capability, not an email one. This is the line between notification tooling and the layer underneath it, and it is why the delay notice is the milestone that separates brands that narrate from brands that keep promises. The software landscape for the sending side is on the delivery notification software page. The detection side, knowing which orders are drifting off promise, is the on-time delivery discipline.

Notifications matter just as much on the reverse leg: a customer waiting on a refund is a customer waiting on a promise, which the returns management page covers.

Bulk outreach: one message beats fifty tickets

The scale version of tell-them-first: when operations wobble across many orders at once, notify the affected cohort in one move. One of our customers came out of a sale event and accepted and refunded 700 orders in a single action, partially fulfilled orders and shipping thresholds included, with the customer messaging handled as part of the flow. Compare that to the alternative: 700 shoppers discovering the problem one by one and writing in. The same pattern works at every scale. Five returns still sitting unprocessed on the fifth of the month means five refunds late and five complaints brewing: message those five customers before they chase, and the queue never forms. The math is always the same, and I have made the full case for it on The Ecommerce Edge: one proactive message to N customers beats N inbound tickets, and it beats them at the exact moment your team is busiest. The full ticket-cost math is on the WISMO page.

Notifications are the voice. Something has to be the hands

Full disclosure on where Keeyu sits in this stack: sending milestone emails is not our core feature, it can be added event-based during scoping. The core is the detection and action underneath, which is the part you cannot bolt on. Everything above assumes you know which orders to message and when, and that is the honest catch: a notification stack is only as good as the detection feeding it. Keeyu watches every order against its checkout promise, catches the drift, fixes what can be fixed, and fires the message as the last step rather than the only step. Detect. Decide. Act. Then tell. Keeyu gets shoppers what they want, on time, as promised, and the notification becomes the receipt for a promise kept rather than an apology in progress. The wider discipline is on the post-purchase operations hub, and a demo shows the detect-to-notify flow on real orders. Every order is a promise. Keeyu keeps it. The notifications are just how the customer hears it happening.

• Keeyu customer results: keeyu.com/customer-stories