A small business that sells through a website, a marketplace, a phone line and the occasional email soon collects orders in more places than it can watch. Someone says it needs an order management system. A search returns a dozen products, each with a feature table, and the choice becomes a comparison of channels, connectors and monthly price.
We think the comparison starts one step too late. Before any product, decide which system will own the status of an order. The product follows from that, and a system chosen without it will turn into one more place where an order has a state that nobody else agrees with.
An order moves through a small number of states, and each transition is something that happened in the real world.
It is received: the customer has asked for something. It is accepted: you have checked it and agreed to fill it. It is allocated: stock has been set aside for it. It is picked and packed, then shipped, with a carrier and a tracking number. It is invoiced, and it is paid. Some orders also move into partially shipped, backordered, returned and cancelled.
Each of these transitions is recorded somewhere. The website knows the order was placed. The warehouse tool knows it was picked. The carrier knows it was collected. The accounting system knows it was invoiced and paid. If each system keeps its own idea of the order's state and none of them is in charge, the same order is simultaneously "shipped" in one place and "processing" in another.
Ask this: can one person, in one place, answer "where is order 1234" without opening a second system?
If the answer is yes, some system already owns the status, and the job is to protect it. If the answer is no, the business has several partial views, and a staff member's afternoon goes into assembling the full picture whenever a customer calls. The cost of that is not dramatic and it is constant: replies delayed, orders shipped twice or not at all, an invoice that does not match what left the building.
Run the question on five real orders from the last month, chosen to include one partial shipment and one cancellation. Count how many systems you had to open for each. The average is a measure of how far the business is from owning its status.
The system that owns status should be the one that sees the most transitions or the one whose record is hardest to dispute. Three questions narrow it.
Which system is touched by the most states? An order system that sees receipt, allocation, shipment and invoice is better placed than a storefront that sees receipt only.
Which system holds the stock? Allocation, partial shipment and backorder are inventory decisions. Whichever system decides them is close to the truth about status.
Which system can write to the others, and which can only read? Status should flow one way: the owner publishes, the others read and display. When several systems can change it, you have a two-way sync, and we have written about why a two-way sync is usually a design failure.
In a very small business the owner may be the storefront's own order screen. In a business with a warehouse, it is usually the system that allocates stock. In a business with complex invoicing, it may be the accounting or ERP system. What matters is that it is one, and that it is written down.
Once the owner is chosen, the other systems have a clear job. The storefront shows the status to the customer and does not set it. The warehouse tool reports the picks and shipments as events and does not decide whether an order is complete. The accounting system invoices from the status and reports payment back, and does not decide whether an order shipped.
This is the same arrangement that holds anywhere in a business that works: a single place for each fact, and the rest of the systems pointing at it. The ownership idea is general, and our piece on where the quote stops matching the invoice applies it to the chain that follows the order.
With the owner and the transitions written down, comparing products becomes much easier, because the questions are specific.
Does it record every transition in the list, with a time and a user?
Does it accept events from the warehouse and the carrier, or must someone enter them?
Can the storefront and the accounting system read the status from it without a person in between?
What happens to an order that is split across two shipments or two warehouses?
A product that answers these cleanly fits. A product with a long channel list and a vague answer to the last question will leave the same problems behind a better screen. If nothing off the shelf fits the transitions you have, the question of building one is covered in when to build your own order management system and when not to.
Imagine a business with twenty-five people that sells through its own website and one marketplace and ships from a small warehouse. About two hundred orders a week arrive. A customer calls to ask about an order. The support person opens the storefront, which says "processing", the warehouse tool, which says picked, and the carrier's page, which says delivered. They explain, after ten minutes, that the order shipped yesterday and arrived this morning.
About twenty calls a week go this way, ten minutes each, which is about three hours of staff time. Worse, the storefront shows "processing" to the customer, who is calling because the page says nothing has happened.
The fix is not a new product. The warehouse tool is chosen as the status owner, because it sees allocation, pick and ship. It publishes each transition to the storefront, which displays it. The accounting system invoices on the shipped event. The one-question test now passes, and the three-hour weekly cost falls to a few minutes.
The owner of status does not have to stay the same forever. A business that starts with the storefront as owner may move it to a warehouse system when stock allocation becomes the hard part, and to an ERP when invoicing and multiple entities arrive. Moving it is a project, and a manageable one if the states are written down and the other systems read rather than write.
What does not scale is having no owner. The cost grows with every channel added and every person who has to assemble the picture by hand, and the day it becomes visible is usually a busy week, when it is hardest to fix. Deciding early, while the business is small, is cheaper than deciding after a missed shipment.
Write the list of order states your business actually uses, from received to paid, and put the name of the system that records each. Where a state has no system, or two, mark it. That page is the whole specification of the ownership decision, and it can be written in an hour before any product is considered.
We start with a no-risk discovery: we trace five of your recent orders through every system, write the state list with its recorders, and propose the owner and the connections, and you pay for the discovery only if you go on. A build comes with a guaranteed estimate, so if we estimate low, we absorb the difference. After go-live, Managed Technical Operations watches the status events so the owner and the readers stay in step.
Decide who owns the order's status first, and the choice of product gets simpler.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
