Knowing a WooCommerce Order Came In, Without Refreshing Your Inbox

Every WooCommerce store sends the merchant an email when an order comes in. It is the default, it costs nothing, and for a lot of shops it is also the least reliable part of the whole operation.

If your working day involves checking your inbox to find out whether you have orders to pack, this is for you.

Why the new-order email fails so often

The email itself is fine. The delivery path is the problem, and it has several failure points that all look identical from the outside: nothing arrives.

The store sends mail as PHP. Shared hosting sends through whatever local mail agent is configured, from an IP with no reputation, with no authentication. Gmail and Outlook are rightly suspicious of that, so the message lands in spam or is dropped silently. Silently is the important word.

SPF, DKIM and DMARC do not match. The mail claims to come from your domain but leaves through the host's server. If your DNS does not authorise that, receiving servers treat it as forged, and the stricter your DMARC policy, the more reliably your own order notifications disappear.

The queue is delayed. WordPress runs scheduled work when someone visits the site. A quiet shop can sit on a delayed send for a long time, and when the mail does arrive it is timestamped now, so nothing looks wrong.

Your inbox buries it. Even when delivery works, an order email is one message among supplier invoices, newsletters and customer questions. Filters help. Attention does not scale.

A phone does not push it usefully. Mail apps batch, sleep and fetch on their own schedule to save battery. "I get an email" and "I find out within a minute" are not the same claim.

The compounding problem is that all of this fails quietly. You do not get an alert saying the alert failed. You find out when a customer asks why their order has not shipped.

Fix the email first

Before adding anything new, fix the thing you already have, because you need order emails working anyway for your customers.

Send through a proper SMTP service rather than PHP mail. Authenticate your domain with SPF and DKIM so your own mail is trusted. Send from an address on your domain, not from a Gmail address you do not control. Then actually test it: place a real order and watch where the mail goes, including the customer's copy.

If your customer receipts are unreliable, that is a bigger problem than your own notifications, and it is the same fix.

Why a push notification is a different thing

Once email is healthy, it is still not a good tool for "there is work to do right now".

A push notification goes to the device rather than to an inbox. It arrives on a lock screen, it does not compete with a newsletter, and it does not depend on domain reputation or a mail queue. It also reaches the person whose job it is, rather than reaching the owner who then has to relay it.

That last point is the one merchants underestimate. The useful signal is not "an order came in". It is "there is something for you to pick", sent to the picker, whose phone is in their apron rather than in an inbox they check twice a day.

The privacy trap nobody mentions

Here is the part that makes a difference in how you should choose a tool.

A notification is displayed on a locked screen. Whoever is near the phone can read it: another customer at the counter, someone on the bus, a family member at home. If the notification contains the order number, the customer name or the amount, you have just published a small piece of personal data to whoever happens to be looking.

The safe design is a notification that carries nothing useful. It says something is ready to pick, and the details only exist inside the app, behind a login. That is a deliberate constraint, not a missing feature, and it is worth checking before you install anything that promises rich order alerts on your phone.

It also matters technically. A push that carries no payload cannot leak order contents in transit or on a push service's infrastructure, because there is nothing in it to leak.

What to look for

If you are evaluating how to be told about orders, four questions cover most of it.

Does it reach the right person? A notification that only goes to the owner is a relay step, not a solution.

Does it work with the app closed? Otherwise it is an in-page alert, and it only tells you what you would have seen anyway.

What does it contain? If the answer includes customer names, see above.

What happens when it fails? Networks drop, permissions get revoked, iOS is stricter than Android about web push. A tool that also shows a queue you can open on demand degrades gracefully. A tool whose only signal is the notification does not.

How Order Prep Pro handles it

Order Prep Pro sends a notification to the device as soon as an order is ready to pick, with the app closed, on the phone or tablet of the person who picks rather than to your inbox.

The notification deliberately carries no order number and no customer name. It tells the device that there is work, and the work itself lives behind the app's own login. The push keys are generated on your own store rather than being handed to a third-party notification service.

And because the app also shows the picking queue, the notification is a convenience rather than a single point of failure. If a push is missed, the queue is still the queue.

None of this removes the need for working transactional email, which your customers depend on. It removes the need for you to use email as a work queue, which it was never good at.