Omnichannel Architecture on SAP Commerce: From Strategy Slide to Working System
Turning omnichannel ambition into SAP Commerce mechanics: the six data domains that must unify first, cross-channel services like click and collect and endless aisle, customer identification across online and store, ASM for assisted selling, and the phasing that survives contact with reality.
Every retailer's strategy deck contains the same sentence: the customer should move between channels without friction. The distance between that sentence and a system where a store associate can see the cart a customer built on the train is roughly eighteen months of integration work, and most of it is data plumbing nobody puts on a slide. This guide reworks the classic CX Works omnichannel material into an implementation shape: what has to be true in the data layer, which cross-channel services to build in what order, and where SAP Commerce's own machinery (BaseStore modeling, stock service, OMS, ASM) carries the load.
Strategy, Reduced to Testable Statements#
Omnichannel programs fail as boil-the-ocean transformations and succeed as sequences of testable capabilities. Translate the strategy into statements you can verify in production:
- A customer is never told to call another department for something any channel can see.
- Any channel can quote the same price, promotion, and stock answer for the same customer at the same moment.
- A journey started in one channel resumes in another without re-entering data.
- Each data domain has exactly one system of record.
Attach a KPI to each (cross-channel conversion, repeat rate, CSAT on channel-switch journeys, order lines fulfilled cross-channel) and the program has a scoreboard instead of a vibe. Executive sponsorship matters for the org-change half, but engineering can start where engineering always starts: the data.
The Six Domains That Must Unify First#
The original guidance names the starting data set, and a decade of projects has not changed it. For each domain, decide the system of record and the distribution mechanism before building any customer-facing service:
| Domain | Typical system of record | Distribution into/out of Commerce |
|---|---|---|
| Customer | CDC/CIAM or ERP master | Identity federation (see the B2B identity and SSO guides); profile sync via Integration Objects |
| Product | PIM or ERP | Catalog loads (data loading guide), catalog sync to online |
| Prices and promotions | ERP for list prices; Commerce promotion engine for offers | Price rows via hot folders or OData; promotions authored once, scoped per channel via websites/modules |
| Stock | WMS/ERP aggregated | Stock service with per-warehouse levels; near-real-time deltas, not nightly dumps |
| Orders | OMS (Commerce Order Management or external) | Order capture from every channel lands in one order store |
| Cart/quote | Commerce | OCC-exposed so any head, including assisted channels, can read and write it |
The architectural sin to refuse: channel-local copies with reconciliation jobs. Every "we sync the store stock file nightly into a separate table for the app" decision resurfaces later as a customer standing in a store looking at an app that disagrees with the shelf.
Cross-Channel Services, In Earnable Order#
The purchasing phase carries the money, so harmonize sales channels first, then work outward. Each service below names its hard dependency, which is the honest sequencing constraint:
- View in-store stock online. Dependency: per-location stock in the stock service (point-of-service data with real feeds, not a store spreadsheet). This ships first because it is read-only and it forces the stock plumbing every later service reuses.
- Click and collect (BOPIS). Dependencies: per-store stock plus an order flow with a pickup delivery mode and store notification. Commerce's point-of-service model and delivery modes cover the storefront half; the store-side workflow (pick, hold, hand over, no-show release) is OMS territory and is where the effort actually lives.
- Buy online, return or exchange in store. Dependency: store systems can resolve an online order (order lookup by OCC or Integration API) and post a return against it. Returns policy alignment across channels is a business decision that must precede the code.
- Cross-channel ordering (order in store to home, store-to-store). Dependency: sourcing logic that treats stores and warehouses as one fulfillment network, which is the OMS sourcing-strategy conversation from the inventory guide.
- Resumable service conversations. Dependency: unified customer identity plus case tooling that bookmarks context across contact channels.
Shipping them in this order means every service funds the plumbing of the next. Shipping them by executive enthusiasm means building click and collect on stock data you do not trust, which becomes the program's first public failure.
Identifying the Customer Across Channels#
Online identification is solved: session, login, consent. The omnichannel-hard part is attaching offline behavior to the same profile:
- Loyalty as the identification bribe. Customers identify at the till when identifying is worth something: points, member pricing, extended warranty registration, digital receipts. Model the loyalty identifier in Commerce as a customer attribute usable by every channel, not as a card number in a separate silo.
- Post-purchase claiming. Receipts that carry a claim code let a customer attach an anonymous store purchase to their account later; cheap to build once order capture is unified.
- Progressive identity. Do not demand full registration at first touch; capture consent and identifiers incrementally (email at e-receipt, account at second purchase). The unified customer profile guide covers the CIAM mechanics and the consent obligations that come with cross-channel profiles, which the data protection guide treats in depth: a 360 view of the customer is also a 360 obligation under GDPR.
- ASM as the associate's head. Assisted Service Mode is the platform's built-in answer for "the associate acts on the customer's behalf": impersonation with consent, cart visibility, order history in the store. If your associates cannot see the online cart, you have not yet met the strategy sentence from the top of this page.
The Organization Is Part of the Architecture#
The technology fails quietly if incentives fight it. The classic killer: store P&L that gets no credit for online orders picked up in store, which reliably produces associates who steer customers away from cross-channel services. Cross-unit teams with representation from each channel, updated job descriptions, and attribution rules that pay the assisting channel are not HR fluff; they are the runtime environment your services execute in. Put a named business owner on every cross-channel service, the same way every integration has a technical owner.
Phasing and the Scoreboard#
A shape that has survived contact with several real programs:
- Phase 1 (data): systems of record decided, stock and order unification live, identity federation working. Customer-visible output: accurate in-store stock online. Modest, measurable, foundational.
- Phase 2 (money): click and collect plus in-store returns. This is where cross-channel conversion becomes a KPI with a trend line.
- Phase 3 (experience): cross-channel ordering, resumable service, personalization informed by unified profiles (the personalization and recommendations guides pick up here).
Report against the KPIs defined at the start, per phase, in the same dashboard the executives sponsored. Omnichannel is the present tense of retail, but it is earned one boring, verifiable capability at a time; the companies that "did omnichannel" successfully are the ones whose architecture diagrams got less exciting every quarter while their cross-channel numbers did the opposite.