COD order confirmation workflow

What are the actual states a COD order should pass through?

New, the moment it arrives with no contact made yet, straight from a store checkout, a form, or a direct message sent to the page. Awaiting confirmation, once the first message has gone out and a reply is genuinely pending from the customer on the other end. Confirmed, once the customer has given a written yes to the specific product, price and address as restated to them in that message. Or cancelled, if they explicitly decline the order outright, or expired, if the follow-up window closes with no reply at all despite the reminder sent. Shipped happens only after confirmed, never as a shortcut from an earlier state no matter how the day is going. Naming these states explicitly, rather than leaving orders in an undifferentiated list where everything just looks like "an order" with no further distinction, is what makes it possible to see where orders are actually stuck at any given moment without digging through each one manually.

Why does the transition trigger matter more than the state name?

Because a state that anyone can set by hand at any time stops meaning anything reliable to anyone reviewing it later. If "confirmed" can be set by a person clicking a button without a stored customer reply behind it, the state no longer tells you whether a real confirmation happened, only that someone believed it did or wanted it to look that way in the system for their own reasons. Tying each transition to a specific recorded event, a message sent, a reply received and parsed, a follow-up window expiring without response, means the state is auditable: you can look at any confirmed order later and see the actual reply that confirmed it, word for word, rather than trusting a label that could have been set for any reason at all by anyone with access.

What does each transition actually require?

An order should never move from new or awaiting directly to shipped, and this rule should hold with absolutely no exceptions regardless of urgency or how many orders are waiting in the queue behind it. That shortcut is exactly how unconfirmed orders end up shipped, usually under pressure to clear a backlog quickly at the end of a busy day when someone decides one more unconfirmed order will not matter much in the grand scheme.

What should happen when a confirmed order needs a change?

Reopen it to awaiting confirmation rather than editing the confirmed record silently in the background without telling anyone. If a customer asks to change their address after confirming, that is a new fact that itself needs a quick acknowledgment before it ships, especially if the change affects delivery pricing or moves the order outside what the current carrier serves reliably in that new commune. Silently editing a confirmed order without a fresh acknowledgment reintroduces the exact problem confirmation exists to prevent in the first place: shipping something the customer has not actually agreed to in its current, corrected form as it now stands.

How should this workflow handle orders from multiple sources?

The same way, regardless of whether the order arrived from a store checkout, a direct message, or a spreadsheet row filled in by hand from a reseller. The states and triggers do not change based on where the order came from; only the initial data quality does, which is a separate concern handled at verification rather than at the workflow level itself. Building one workflow that every order passes through, rather than a different ad hoc process per channel that a busy team improvises differently each time depending on who is handling it, is what keeps the confirmation rate and delivery success numbers comparable across your whole order volume instead of fragmented into channels nobody is tracking the same way.