An Order Management System Is a Set of Promises

Every rule is a promise

When a customer places an order, the retailer is promising that the item is available, that it will ship from a sensible place and that it will arrive when the site said it would. Sourcing rules, reservation logic and delivery estimates are just those promises written down. If the business has not agreed on the promises, the configuration will not save it.

So the first questions I ask are plain ones. Where can this order be fulfilled from? What happens when the first choice has no stock? Who decides when a split shipment is acceptable?

Multiple brands and regions multiply the questions

An implementation across several brands and regions sounds like one project. In practice each brand has its own habits around returns, cancellations and stock visibility. The job of the business analyst is to find out which of those differences are real requirements and which are history.

Writing those decisions into clear user stories, with acceptance criteria the business can check, is what keeps the backlog honest.

Stores and warehouses see different things

Store teams think about walk-in customers. Warehouse teams think about pick lists and cut-off times. Both are right, and both will be affected by the same order routing rule. Bringing them into the same conversation early saves a lot of rework later.

Test the unhappy paths

Happy-path orders are easy to demo. The cases that matter are the ones where stock is wrong, a payment fails or a customer changes their mind halfway through fulfilment. Those are the moments when the promise is tested, and they deserve as much attention in the backlog as the main flow.

Where AI fits

Building AI products in the Curious PM cohort made me think about how much of order management is reading and judging exceptions. A model can help a team spot patterns in failed orders or draft the first version of a requirement. The promise itself, and the rules behind it, should still be decided by the business.