Automated Order Status Alerts for Restaurants — SMS, Email, Push, Browser Compared

An automated order status alert is a message that fires when an order changes state — confirmed, preparing, ready, out for delivery, delivered. It runs without anyone clicking a button. Done right, it cuts "where is my order?" phone calls to near zero and gives the customer a sense of control without requiring them to install anything.

Done wrong, it spams the customer with seven messages they didn't ask for and gets the restaurant's sender ID blacklisted. The difference is mostly about choosing the right channel for each state — and being honest about which messages are useful versus which only exist to make the operator feel busy.

The four channels, ranked by signal-to-noise

Browser/web push (free, instant, only works while the tab is open or the customer has granted persistent permission) — best for "your order is ready for pickup" moments where the customer is actively waiting on the same device they ordered from. Zero cost per message, zero infrastructure to maintain.

Mobile push (only works if the venue has an app, which most don't) — included here mainly to explain why most restaurants skip it. Browser push covers 80% of the same use case without the app overhead.

SMS (€0.04–€0.08 per message in EU, lands instantly, no install needed) — the right channel for "your order is on the way" and "your delivery arrived." Works on any phone, even an old one, even without internet. The cost adds up at volume, so reserve it for the 1–2 moments that actually move customer satisfaction.

Email (free at low volume, slower delivery, customer may not check until later) — best for the order confirmation receipt with the full breakdown, plus next-day "thank you" with a reorder link. Not a real-time channel.

Which states actually deserve an alert

Out of the typical 6–8 status transitions, only 2–3 generate enough customer anxiety to justify pinging them. The rest can stay silent (the customer doesn't need to know the kitchen has accepted the ticket — they care that food is coming).

• •Confirmed — email receipt only (free, gives them a record to forward)
• •Ready for pickup — SMS + browser push (the moment that actually matters for pickup orders)
• •Out for delivery — SMS with ETA (the highest-anxiety moment in the order)
• •Delivered — SMS (closes the loop; reduces "did it arrive?" calls)
• •Cancelled / refunded — SMS + email (these always need both channels)

Why dual-carrier SMS routing matters in EU

A single SMS provider has a small but real failure rate on cross-border delivery, especially for Greek and Bulgarian numbers routed through aggregators based outside the region. The fix is to route through two providers in parallel and fall back automatically when the primary stalls. This is invisible to the operator and to the customer — but it raises delivery success from ~95% to ~99.7% in measured EU routes.

Ordering.Tools uses LinkMobility as the primary EU route and GatewayAPI as the fallback. Operators do not configure this; it just works. Cost is identical to single-provider routing because the fallback only fires when the primary fails.

A simple rule for which to enable

Start with all four channels turned on for the five states above, then run the venue for two weeks and check the audit log for which channels are firing on which order types. Most venues end up with: email always, browser push for pickup, SMS only for delivery, no mobile push. That configuration costs roughly €0.05 per delivered order in SMS — and saves an order of magnitude more in support time.

See the Order Notifications feature page for the full state map, the SMS Notifications page for the dual-carrier routing details, or the "reduce where is my order calls" blog post for the customer-experience side of the story.