What does an order management system actually do?
It owns the order from the moment it is placed to the moment it is settled or returned, independently of the channel that captured it and the location that fulfils it. It holds one order record, decides which location or warehouse should serve each line, tracks state through picking, dispatch, delivery, and return, handles the exceptions when reality diverges from the plan, and gives every part of the business one truthful answer about where an order stands. Without it, each channel keeps its own partial version and the contact centre becomes the integration layer.
Do we need an OMS if we already have ecommerce and a POS?
You need one when orders start crossing boundaries. If everything online ships from one warehouse and stores only sell over the counter, your platform and till are probably sufficient. The moment you introduce click-and-collect, ship-from-store, cross-channel returns, multiple fulfilment locations, marketplaces, or preorders, the routing and state logic has to live somewhere. Left unaddressed, it ends up spread across spreadsheets and staff knowledge, which does not survive volume.
Should we buy an OMS or build one?
Commercial OMS products are capable and worth evaluating first, particularly if your fulfilment model is conventional. Building is justified when your sourcing rules, promise logic, or operational model genuinely does not fit a product, when integration into a mixed legacy estate would cost more than the product licence saves, or when order orchestration is a competitive capability rather than back-office plumbing. We assess honestly and have no incentive to recommend a build where a product fits.
How does allocation and sourcing logic work?
It is a ranked rule set applied per order line rather than a single setting. Typical inputs are available stock by location, distance to the customer, carrier cutoff times still achievable, store labour capacity, whether splitting the order is acceptable, markdown or ageing priority, and cost to serve. The rules must be transparent and adjustable by your operations team, because sourcing policy changes with season, capacity, and margin pressure far faster than software releases can accommodate.
How do you handle order splitting and partial fulfilment?
By modelling shipments as first-class entities beneath the order rather than treating the order as one indivisible thing. One order can produce several shipments from several locations, each with its own carrier, tracking, and delivery date, while the customer sees one order with honest per-item status. Payment capture, invoicing, and refunds then need to work at shipment level, which is a common gap in systems that assume one order equals one parcel.
What happens when an item cannot be found at the chosen location?
This is routine, not exceptional, and the quality of the OMS is largely measured by how it handles it. The store or warehouse marks the line short, the system reallocates to the next eligible location under the sourcing rules, the customer is informed with an accurate revised expectation, and the stock position is corrected so the same phantom unit is not promised again. Systems that require a human to notice and intervene generate the majority of retail service failures.
Can the OMS handle returns and exchanges across channels?
Yes, and this is a common reason for the project. A return needs to be accepted wherever the customer presents it, matched to the original order and payment, checked against policy and window, processed as a refund or exchange to the correct tender, and recorded as a stock movement at the receiving location. Without a shared order record, an online order returned in store is effectively an untraceable transaction, which is where refund fraud and reconciliation gaps appear.
How does it fit with our ERP and warehouse system?
The OMS orchestrates; the ERP records financially; the warehouse system executes physical work. Overlap is normal but ownership must be explicit: which system decides sourcing, which holds the authoritative order state, which posts revenue, and which owns stock. Most order project failures we see are ownership ambiguity rather than technical difficulty, so we settle that map before design.
Can you make delivery promises reliable?
Yes, if the promise is computed rather than configured as a static message. A truthful promise combines real availability at the sourcing location, remaining time to carrier cutoff, the location's actual pick throughput, and carrier transit performance on that lane. We recommend measuring achieved versus promised delivery from launch and tuning cutoffs against that evidence, because a promise the operation misses costs more than a slightly longer one it keeps.
How long does an OMS project take?
A first release covering one order record, sourcing rules, and integration to ecommerce, stock, and fulfilment typically takes four to six months, driven mainly by integration surface rather than interface scope. We sequence it so one flow such as click-and-collect goes live and stabilises before adding ship-from-store, marketplaces, and returns, since each adds exception paths that need real operational testing.
What engagement models are available?
We offer a Dedicated Development Team for continuous product work and Staff Augmentation to extend your in-house team. AgileTech Vietnam brings 10+ years of experience and 200+ developers, with quality management certified to ISO 9001:2015 and information security to ISO 27001:2013. Share your requirements and we prepare a tailored proposal within 48 hours covering team composition, timeline, and cost.
