Multi-Channel Order Management
Why unify order management across channels
Section titled “Why unify order management across channels”Customers buy through whichever channel is convenient — desktop browsers, mobile apps, in-store kiosks, or phone orders entered by sales reps. When each channel runs its own order system, you get inventory conflicts (overselling because channels do not share stock data), pricing inconsistencies (a promo that works online but not in-store), and fragmented customer histories (a returns desk that cannot see online orders).
Unified order management routes all channels through the same Commerce backend. Inventory is always accurate because every channel draws from the same pool. Pricing rules apply consistently. Customer profiles in ODP capture purchases from every touchpoint.
Architecture overview
Section titled “Architecture overview”┌────────────┐ ┌────────────┐ ┌────────────┐│ Web App │ │ Mobile App │ │ POS / In- ││ (Next.js) │ │ (React │ │ Store ││ │ │ Native) │ │ Terminal │└─────┬──────┘ └─────┬──────┘ └─────┬──────┘ │ │ │ └───────────────┼───────────────┘ │ ┌───────┴────────┐ │ Commerce API │ │ (Unified) │ └───────┬────────┘ │ ┌──────────────┼──────────────┐ │ │ │ ┌────┴────┐ ┌─────┴────┐ ┌─────┴─────┐ │ Catalog │ │ Pricing │ │ Inventory │ │ Service │ │ Engine │ │ Service │ └─────────┘ └──────────┘ └───────────┘ │ ┌───────┴────────┐ │ Order Router │ │ & Fulfillment │ └───────┬────────┘ │ ┌────────────┼────────────┐ │ │ │ ┌────┴────┐ ┌────┴────┐ ┌────┴────┐ │ East DC │ │ West DC │ │ Store │ │ │ │ │ │ Pickup │ └─────────┘ └─────────┘ └─────────┘Step 1: Design the unified Commerce API layer
Section titled “Step 1: Design the unified Commerce API layer”Create a single API surface that all channels consume. Each channel sends orders through the same endpoints, ensuring consistent business logic.
| API endpoint | Purpose | Channels |
|---|---|---|
GET /api/products | Catalog browsing | Web, mobile |
GET /api/products/{sku}/price | Real-time pricing | All |
POST /api/cart | Cart management | All |
POST /api/orders | Order submission | All |
GET /api/orders/{id} | Order status | All |
POST /api/orders/{id}/return | Return initiation | All |
Each request includes a channel identifier (web, mobile, pos) so the system can track order origin for analytics and apply channel-specific rules if needed.
Step 2: Implement shared inventory management
Section titled “Step 2: Implement shared inventory management”All channels must see the same inventory to prevent overselling. Implement a centralized inventory service with reservation support.
When a customer adds an item to cart on any channel, the system creates a time-limited inventory reservation. This prevents the same unit from being sold simultaneously through two channels.
Key design decisions:
| Decision | Recommendation | Reasoning |
|---|---|---|
| Reservation timeout | 15 minutes (web/mobile), immediate (POS) | POS transactions are synchronous |
| Stock visibility | Real-time across channels | Prevents overselling |
| Backorder handling | Channel-specific rules | POS may not allow backorders |
| Safety stock | Reserve 5% for walk-in customers | Prevents store stockouts |
Step 3: Apply consistent pricing across channels
Section titled “Step 3: Apply consistent pricing across channels”Pricing rules should evaluate identically regardless of channel. Customer-specific prices, volume discounts, and promotions apply the same way whether the order comes from the website or the sales floor.
Exceptions to handle:
- Store-only promotions — Tag promotions with eligible channels
- Channel-specific shipping — POS orders may have different fulfillment costs
- Sales rep discounts — POS may allow manual discounts with manager approval
Route all pricing through the same pricing engine. Add a channel filter to promotions so you can run channel-specific campaigns without duplicating pricing logic.
Step 4: Route orders to fulfillment
Section titled “Step 4: Route orders to fulfillment”After order placement, the order router determines the best fulfillment strategy based on the order channel, shipping address, and inventory location.
| Order source | Fulfillment options |
|---|---|
| Web order, ship to home | Nearest warehouse with stock |
| Web order, buy online pick up in store | Designated store location |
| Mobile order, same-day delivery | Local store or distribution center |
| POS order, customer carry-out | Fulfilled at point of sale |
| POS order, ship to home | Nearest warehouse with stock |
| Phone order, ship to customer | Nearest warehouse with stock |
The router checks inventory at each candidate location, calculates shipping cost and time, and selects the optimal fulfillment point. If no single location can fill the order, the router splits it across locations.
Step 5: Unify customer identity across channels
Section titled “Step 5: Unify customer identity across channels”Connect all channels to ODP so purchase events from web, mobile, and POS link to the same customer profile. This requires consistent customer identification:
- Web and mobile: Authenticated users identified by email or account ID
- POS: Loyalty card scan, email lookup, or phone number
- Guest checkout: ODP anonymous profile that merges when the customer identifies later
With unified identity, a customer who browses products on mobile, visits the store to see them in person, and orders online has a complete profile that reflects all three interactions.
When to use this pattern
Section titled “When to use this pattern”Multi-channel order management is essential when you sell through more than one channel and share inventory across them. The complexity is justified when overselling, pricing inconsistencies, or fragmented customer data are causing real business problems. If you operate a single online channel with no physical presence, this architecture adds unnecessary complexity.