The most common thing written about order management systems is a number. Five hundred orders a day. Ten thousand a month. Pick a threshold, cross it, buy the system.
It is the wrong frame, and it produces both errors. Brands buy at the threshold and find the OMS solving problems they did not have. Other brands sit at a third of the number, drowning in operational failure, and conclude they are too small to need one.
Two brands doing identical order volume can have completely different answers, because order volume measures how much is flowing through the operation, not how many decisions each order requires. A thousand identical prepaid orders shipping from one warehouse to metro pincodes is a simple operation at scale. Nine hundred orders across two warehouses, three vendors, two sales channels, with COD and a returns flow is a complex operation that happens to be smaller.
What follows is the complexity audit we actually run. Eleven signals. Count how many apply.
The eleven signals
Inventory and supply
1. More than one place inventory physically sits. Two warehouses, or a warehouse plus a vendor who dropships, or stock held at a 3PL alongside your own. The moment inventory exists in two places, something has to decide which one fulfils each order, and Shopify's native location logic is deliberately simple.
2. Vendors who fulfil on your behalf. Every vendor is a separate stock position, a separate SLA, and a separate source of truth about what is available. Vendor-fulfilled orders are the single most common reason Indian D2C brands outgrow native tooling earlier than their volume suggests.
3. Inventory numbers that disagree between systems. If your team has ever manually reconciled Shopify stock against a spreadsheet or a marketplace listing, this signal is live. It rarely resolves on its own; it compounds as SKU count grows.
Channels and orders
4. Selling on Shopify and at least one marketplace. Amazon, Flipkart, Meesho, or a quick-commerce channel alongside your own store. Two channels means two order streams competing for the same stock, and a sync lag measured in minutes becomes an oversell measured in cancellations.
5. Order routing that requires a human decision. Somebody looks at an order and decides where it should ship from, or which vendor gets it, or whether to split it. If that judgment lives in a person rather than a rule, it does not scale and it does not survive that person taking leave.
6. Split shipments or partial fulfilment as a routine event. Multi-item orders where components ship separately from different locations. Native tooling handles this awkwardly and the customer-facing communication around it is where the experience degrades.
Exceptions and post-purchase
7. Returns handled case by case rather than by policy. If the outcome of a return depends on who processes it that day, you have an unwritten policy, and unwritten policies are a system waiting to be built.
8. COD failures and RTO at a rate that affects margin. COD-heavy Indian D2C operations generate a stream of exceptions - failed deliveries, reattempts, returns to origin - that need decisions and tracking. Volume of exceptions matters more than volume of orders.
9. People chasing order status. If a meaningful part of someone's week is spent finding out where an order actually is, the systems are not agreeing with each other, and that disagreement is the problem an OMS is built to end.
Process and data
10. Spreadsheets doing load-bearing work. Not spreadsheets for analysis - spreadsheets that operations would stop without. A reconciliation sheet, a vendor allocation sheet, a returns log. These are the visible outline of the system you have not built yet.
11. Reconciliation as a recurring calendar item. If somebody spends the last days of every month matching orders against payouts, shipments, or vendor invoices, that work exists because no single system holds the authoritative record.
How to read your score
One to three signals. You have specific problems, not an architecture problem. Buy the narrow tool - an inventory sync, a returns portal, a shared support inbox. An OMS at this stage solves problems you do not have and adds implementation overhead you will resent.
Four to six signals. The transition zone, and the hardest place to make a decision. The honest test is whether the signals are clustered or scattered. Four signals all sitting in inventory and channels is a real architecture problem. Four scattered across unrelated areas is usually still four point problems.
Seven or more. The signals are almost certainly reinforcing each other. At this density, point solutions stop helping because the problem is that no system holds the authoritative version of an order. Adding another tool adds another opinion.
Notice that none of these signals is a number. A brand at 400 orders a day with eight signals has a harder operation than one at 2,000 orders a day with two.
For context on the external view: market guidance commonly cites adoption around 5,000 to 10,000 orders per month, earlier for multi-channel sellers, and notes that at 1,000-plus orders a day native Shopify functions as the system of record rather than the system of action. Those are useful reference points, but they describe the average brand rather than yours - which is exactly why the signal count is the better instrument.
What an OMS actually does that Shopify does not
Three things, and it is worth being precise because the category is often oversold.
It holds one authoritative order state. Shopify knows what it knows. The courier knows scan events. The marketplace knows its own status. An OMS reconciles these into a single record that every downstream system reads, which is what ends the internal disagreement about where an order is.
It makes routing a rule instead of a judgment. Which warehouse, which vendor, which courier, whether to split - encoded once, applied consistently, changed in one place.
It treats exceptions as first-class. Failed deliveries, partial stock, vendor rejections, returns. In native tooling these are edge cases handled by people. In an OMS they are defined states with defined transitions.
What it does not do is fix a broken process. An OMS applied to an operation nobody has mapped will encode the confusion rather than remove it.
Before you scope anything
Run the count on your own operation this week. Eleven signals, honest yes or no, no partial credit.
Then, for every signal you marked yes, write down what it currently costs - hours per week, error rate, or rupees of margin. Not an estimate of what fixing it would save. What it costs today. That number is the only thing that makes the investment case, and it is the number most brands have never assembled.
If the count is high and clustered, the next question is architecture rather than product - what should hold the authoritative record, what stays in Shopify, and what an ERP would or would not add. We work through that in Shopify Flow vs OMS vs ERP, and the cost side in what a custom OMS actually costs.
If you want the count run against your actual operation rather than self-assessed, book an operations diagnostic. We walk the order lifecycle end to end, mark the signals, price what each is costing you now, and tell you plainly when the answer is that you do not need one yet.
