What separates unified commerce from omnichannel
Omnichannel describes what the customer experiences: consistent pricing, branding, and service across every channel they touch. Unified commerce describes what sits underneath: a single operational record that every channel reads from in real time.
A retailer can deliver a convincing omnichannel experience on fragmented systems, for a while. Staff check a second screen. Someone runs a manual stock reconciliation each morning. The gaps get papered over by people who know the workarounds, and the model holds until volume or channel count rises.
The distinction matters commercially because the two require different investments. Omnichannel improvements are largely front-end and marketing work. Unified commerce is an integration and data-model problem, which is why e-commerce architectures are moving from platforms to data backbones. Confusing the two is how retailers end up funding a redesign when their actual problem is that stock figures disagree.
The four records unified commerce has to share
Unified commerce is easier to scope when it is broken into the specific records that every channel needs to agree on.
- Inventory: one available-to-promise figure per location, updated on transaction rather than on schedule
- Customer: one identity that resolves across guest checkout, loyalty card, app login, and in-store purchase
- Order: one order record that survives being created in one channel, fulfilled from a second, and returned through a third
- Price and promotion: one set of rules, including customer-specific and channel-specific pricing, applied from the same source
Very few retailers need all four unified at once. The order of work usually follows where the money leaks. For most that is inventory first, because a wrong stock figure either oversells or hides sellable goods.
Why do cross-channel returns break so often?
Returns expose the gaps because they run the whole chain backwards. A return requires the store to identify an order it did not create and confirm what was paid, including any promotion applied at the time. It then authorizes a refund against a payment it did not take, and returns the item to a stock pool another channel is already selling from.
Each of those steps reads a different record. If any one of them is stale, the outcome is visible to the customer immediately. Staff either refuse a valid return or accept an invalid one, and both are expensive in different ways.
This is also why returns are a good diagnostic. A retailer that can process a cross-channel return in one transaction, without a phone call or a second system, has genuinely unified those four records. One that cannot has an omnichannel front end on fragmented foundations.
Unified commerce across seven webshops
Multi-storefront retailers feel this hardest, because every additional webshop is another place a stock figure or loyalty balance can drift. Obelink runs seven of them alongside a physical store. The Dutch camping and outdoor retailer has been family-run since 1959 and is one of the largest in Europe.
It connected its ERP, warehouse system, point of sale, and Adobe Commerce storefronts through the Alumio iPaaS rather than consolidating onto a single suite. Customer accounts, stock availability, and the omnichannel order process now run as governed flows between those systems. Gift cards and loyalty points synchronize across all four, so a balance earned in one channel is spendable in another.
The retailer kept the systems its operation was built on and changed how they exchange data, rather than replacing them.
How an integration platform enables unified commerce
An integration platform makes unified commerce achievable without a replatform by holding the shared record between systems rather than inside any one of them. The Alumio iPaaS receives a stock movement from the warehouse and applies the allocation logic that decides what each channel may sell. The result publishes to every storefront and the point of sale as one event.
On the platform, that work splits into four parts:
- Transformers: reshape an order so a record created by the storefront arrives at the ERP in the structure it expects, without anyone maintaining a mapping script
- Storage: holds intermediate state, so a channel that was briefly unreachable receives the update on replay instead of missing it
- Monitoring and audit trails: record which channel received which figure and when, turning a stock discrepancy into a lookup rather than an argument
- Configuration: handles the routing and mapping rules, with the Code Transformer covering what configuration cannot express
Because those flows are configured rather than hand-built per channel, adding a marketplace or a new country storefront reuses the existing logic instead of restarting it.
Building unified commerce without replacing what works
The instinct when channels disagree is to consolidate onto fewer systems. It is an understandable response and occasionally the right one, but it treats a data problem as a licensing problem. The systems are rarely the issue. The absence of a shared record between them is.
Retailers who approach unified commerce as an integration program tend to get value earlier. They can unify one record at a time and measure the result. Inventory first, then customer identity, then order, then pricing. Each step is independently useful and none of them requires a launch date.
The end state is a retailer that can add a channel, a country, or a fulfillment model without wondering whether the rest of the operation will still agree with itself.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
