Order Status Automation — How to Save Time in E-commerce

An order status is the simplest piece of information in your whole store — “new”, “paid”, “shipped” — and yet it eats a surprising amount of time. Because someone has to actually change it: spot the payment, click “processing”, click “shipped” after the parcel goes out, paste the tracking number. With a dozen orders a day it’s nothing. With a few hundred it becomes daily, mechanical clicking that creates zero value and is easy to get wrong.

The good news: status transitions are the easiest part of order handling to automate. The events are unambiguous, the rules are simple, and the payoff shows up on day one. This article walks through a typical status cycle, which transitions are worth handing to automation, how to express them as event-driven rules, and how much time you can realistically save.

The order status cycle — map it before you automate anything

Before you set a single rule, you need your own status cycle in front of you. It rarely matches the textbook version, because every store has its own exceptions (pre-orders, cash-on-delivery, personalization). The typical skeleton, however, looks like this:

1. New — the order landed, not paid yet.
2. Paid / ready to fulfil — payment confirmed, picking can start.
3. Picking — the warehouse gathers and packs.
4. Shipped — parcel dispatched, tracking number exists.
5. Delivered / completed — the buyer received it, time to ask for a review.

On top of that come the “side” statuses that must exist so automation knows what not to touch: on hold, awaiting payment, needs clarification, return / complaint. Each arrow between statuses is an event, and each event can trigger an action. That’s the whole idea: you don’t automate “the store”, you automate specific, repeatable transitions.

Which transitions to automate — and which to leave to a human

Not everything is worth automating to the same degree. Stick to the principle: automation handles the rule, a human handles the exceptions. In practice, these transitions pay off best:

• “new” → “paid” once payment is confirmed — the classic, fully deterministic step,
• “paid” → “picking” when the order enters fulfilment,
• “picking” → “shipped” the moment the parcel is dispatched, together with saving the tracking number,
• “shipped” → “completed” after delivery is confirmed (if the channel reports it),
• flagging for priority — high-value orders or those with a tight deadline.

And what not to hand to automation unsupervised:

• returns and complaints — these almost always need a human decision,
• “needs clarification” orders (out of stock, wrong address, suspected fraud),
• cash-on-delivery and pre-orders, where “paid” doesn’t mean what it usually means.

Automation should catch and flag these cases rather than push them further down the cycle. Well-configured status automation actually increases control: the human only ever sees the exceptions, because everything else moved through the cycle on its own.

Event-driven rules: WHEN → IF → THEN

The most convenient way to think about status automation is a three-part formula: when something happens, if a condition holds, then run an action.

WHEN event (e.g. “order paid”) → IF condition (e.g. “channel = Allegro and amount > PLN 200”) → THEN action (e.g. “set status to ‘ready to fulfil’, send an SMS and flag for priority shipping”).

A few ready-made rules that work for most sellers:

• WHEN order paid → THEN status “ready to fulfil” + email confirmation to the customer.
• WHEN parcel dispatched → THEN status “shipped” + save tracking number + notification with a tracking link.
• WHEN order paid IF amount > PLN 500 → THEN flag “priority” + alert to an internal webhook.
• WHEN order delivered IF 3 days have passed → THEN send a review request (especially valuable on Allegro).
• WHEN an item is out of stock → THEN status “needs clarification” + alert to the team (don’t push it further).

Sellaro’s automation engine works exactly this way — on domain events (new order, status change) with conditions and actions. Today’s available actions are email (SMTP) and SMS notifications, webhooks (HMAC-signed, with retries), and a log entry. This lets you build your own paths instead of forcing your store into a tool’s rigid schema. For the whole cycle — from payment to shipping — see our piece on e-commerce order automation.

Statuses in multichannel selling — one dictionary instead of five

The real pain with statuses begins with the second channel. Allegro names its stages differently from WooCommerce, which names them differently from PrestaShop, and you end up translating one into another in your head. The result: the same “shipped” order in one panel is “processing” in another, and the customer gets contradictory signals.

The solution is one normalized status dictionary across all channels. Sellaro pulls orders from connected stores (PrestaShop, Sylius, WooCommerce — modules ready; Allegro, Amazon, Shopify — on the roadmap, added on request) into a single, consistent view. Then one status rule behaves the same regardless of where the order came from — you don’t write separate logic for each platform.

An important note on honesty: the store integrations are READ-ONLY. Sellaro reads orders and maintains their status on its own side for automation and viewing, but it does not write changes back to the store. Writing the status back to the channel in sync is something we are working toward — today we centralize and automate on the Sellaro side. For a practical look at wiring up a multichannel flow, see our guide to automating Allegro and WooCommerce sales.

What it actually saves — time and mistakes

Status automation doesn’t look impressive in a demo, because it’s “just a label change”. The payoff shows up at scale. A rough estimate: manually changing a status and pasting a tracking number takes around 30–60 seconds per order. At 200 orders a day that’s 1.5–3 hours of pure clicking — a full working day every week that simply disappears.

Add the effects that are harder to price but very real:

• fewer mistakes — automation won’t forget to change a status or paste a number onto the wrong order,
• fewer “where’s my parcel” tickets — the customer gets the status and tracking immediately, support gets peace,
• faster flow — orders don’t wait for someone to “get around to” changing their status,
• cross-channel consistency — one status dictionary instead of five different ones.

Most importantly, you collect these savings before you reach the pricier automations like courier labels or invoices. Statuses and notifications are the cheapest starting point with the highest return.

Frequently asked questions

Where do I start with status automation?

By mapping your own status cycle and identifying the fully deterministic transitions — the ones that don’t require a human decision. Usually those are “paid” after payment confirmation and “shipped” after dispatch, together with the tracking number. These two transitions give the fastest return.

Won’t status automation take away my control over orders?

Quite the opposite. Well-configured automation only pushes rule-compliant cases through the cycle, while exceptions (returns, out-of-stock, cash-on-delivery) are flagged and held for a human decision. As a result you only deal with what genuinely needs attention, instead of clicking on every single order.

Does Sellaro change statuses back in Allegro or in my store?

No. Store integrations are READ-ONLY — Sellaro reads orders and maintains their status on its own side (for viewing and automation) but does not write changes back to the store. Writing the status back to the channel is a direction we are working toward; today we centralize and automate on our side. The Allegro integration is on the roadmap and we add it on request.

What is a WHEN → IF → THEN rule?

It’s a way to express automation: WHEN defines the event (e.g. “parcel dispatched”), IF adds a condition (e.g. “channel = WooCommerce”), and THEN runs an action (e.g. “set status to ‘shipped’ and send an SMS with the tracking number”). Sellaro’s automation engine works exactly this way — domain events with conditions and email/SMS/webhook/log actions.

Summary

Order statuses are the simplest and at the same time the most rewarding area to automate: the events are unambiguous, the rules are short, and the time saved is measurable from day one. Start by mapping your own cycle, hand the deterministic transitions (“paid”, “shipped”) to automation, keep the exceptions for yourself, and write everything as WHEN → IF → THEN rules. In multichannel selling, add one shared status dictionary so you’re not translating stages from panel to panel.

Sellaro already offers a working event-driven automation engine (email, SMS, webhook, log actions) and a central, normalized view of orders across all channels; Allegro, couriers and accounting are added as modules on request. See the Sellaro pricing — a flat fee with a generous limit, all integrations included, and 0% commission on sales value. Missing an integration you need? Get in touch — we’ll add it for free.