Siloed Systems and Omnichannel Promises: What a Multi-Location Retailer Owes Its Own Operations Team

The customer notices once. Your team notices every night

You promised shoppers they could buy online and pick up in any of your stores, return in one location what they bought in another, and see live stock before they drove over. Then you found out what that promise costs, and it was not the website.

Somewhere in your back office there is a person, usually more than one, whose evening consists of making two systems agree. The ecommerce platform says it sold four units. The point of sale says the store has two. The inventory system says six, because the receiving scan from Tuesday never posted. Nobody was hired to fix that. Somebody does it anyway, every night, because the alternative is a customer who drives to the store and finds an empty shelf.

That is the part of the omnichannel conversation nobody sells. Search the phrase and page one is a definitional fight between multichannel and omnichannel, written by the companies selling the second one. Every result frames disconnected systems as a customer experience problem. It is not, or not mainly. The customer feels the silo once, on the day the pickup order is wrong. Your operations team lives inside it.

Where the silos came from, and why they outlived the reason

The structure is historical and specific. Through the 2000s most retailers ran ecommerce as its own profit centre. Darpan Seth, writing in Chain Store Age, describes it plainly: each channel had its own P&L, its own inventory management, and often separate teams that did not talk to each other. Store staff had no reason to support an online order, and shoppers who came in for pickup met indifference at the register because the sale had already been credited somewhere else.

That was a strategy decision, and a defensible one at the time. Online was small, uncertain, and easier to manage as a startup inside the company. The problem is that the org chart outlived the strategy. The separate team became a separate platform, the separate platform became a separate inventory count, and by the time the board asked for unified commerce, the company had two or three of everything.

Vendor writing on multichannel operations still describes the same shape. Each channel typically operates with its own inventory, pricing, and customer data. Ecommerce, point of sale, warehouse management, and customer relationship tools frequently lack any native way to talk to each other. Trade coverage going into 2026 says the back office supporting those channels has not kept pace with the front, and that the gap is widening as the required stack keeps growing.

None of that is news to you. What is worth noticing is who the silo actually costs.

The reconciliation job that is not on any org chart

When two systems disagree and both keep running, somebody becomes the integration. That is the pattern we see in nearly every multi-location retailer we look at, and it takes the same handful of forms.

An assistant manager exports the day's point of sale transactions, pulls the ecommerce order file, and matches them in a spreadsheet so that tomorrow's on-hand count is close enough to trust. A finance clerk compares three settlement reports against the bank because each channel has its own payment processor. A buyer keeps a private stock sheet because the system of record is wrong often enough that she stopped believing it. A store lead marks online pickup orders as ready by hand, on a screen that does not know the item was sold at the register ten minutes earlier.

Each of those is a job. None of them has a title, a budget line, or a headcount request. They show up as overtime, as a manager who cannot leave the floor, and as a quiet rule that nobody trusts the number in the system until a person has looked at it.

One published integration case gives a sense of scale: a twelve-store apparel retailer with a warehouse and an ecommerce channel was spending more than three hours a day reconciling inventory by hand, with an 18 percent discrepancy between point of sale and the enterprise system at cycle count. Online orders were being fulfilled against stale stock and refunded after the fact. The figures come from an integrator's benchmark rather than an audited client, so treat the exact numbers with care. The shape, though, is one we recognise: three hours a day is 750 hours a year, which is a third of a full-time person doing nothing but agreeing two databases with each other.

Retail task management vendors report handing back somewhere between five and thirteen hours a week per store manager once manual coordination is removed. Again, sell-side numbers. But even the low end, across a forty-store chain, is a full-time equivalent or two spent on work that produces nothing a customer can buy.

The promise cuts both ways

Here is the framing we ask clients to sit with. When you promise shoppers unified commerce, you take on a matching obligation to your own staff. If the systems will not agree on their own, someone in your back office is agreeing them by hand every night. You do not get to make the first promise without making the second, because the second is how the first gets kept.

That reframing changes what the business case looks like. The vendor version of the case is built on customer metrics: conversion lift, basket size, retention from a smoother pickup experience. Those are real but they are also the numbers a vendor can make look good in a slide, and they are extremely hard to attribute after the fact. The operational version of the case is built on hours you are already paying for. It is smaller, it is duller, and it is the one you can actually verify.

Count the reconciliation hours before you buy anything. Walk every location and every back-office function and ask one question: what do you do by hand because two systems do not match? Write down who, how long, how often. Then price it. That number, not the customer experience deck, tells you whether integration pays.

If the number is small, you may not have an integration problem. You may have a process that works well enough, and a vendor who would like to sell you a platform anyway. We have told retailers exactly that, and it is usually the moment they decide to trust us. We wrote about the general version of this in when AI is the wrong answer to an operations problem, and the retail case is the same argument with a stockroom in it.

If the number is large, you now have a business case that does not depend on a single assumption about shopper behaviour.

Why the hours are usually higher than anyone guesses

The reason nobody has the total is that the work is distributed. No single person spends forty hours a week on reconciliation, so it never crosses the threshold where somebody asks whether it should exist. Twenty people spend two to four hours each, in a dozen different spreadsheets, and every one of them believes their version is a local quirk rather than a company-wide pattern.

It is also invisible in the tools you would naturally look at. Payroll shows a store manager on the clock, not what they did with the last hour. The ecommerce dashboard shows orders, not the refund issued three days later because the item was never actually there. The inventory system shows a count, not the fact that a buyer keeps a shadow copy because she has been burned.

So the diagnostic is not a report you can run. It is a set of conversations, in person, at the locations where the work happens. This is the same discovery problem we describe in our piece on what operational diligence finds that a quality of earnings report cannot: the cost is real, it is recurring, and it does not appear in any system because it is the work of compensating for the systems.

What the count tells you that the pitch does not

Once you have the hours, three things become clear that were not clear before.

You learn which silo matters. Seven or eight disconnected platforms is normal for a mid-market retailer, but they do not all generate the same manual work. Usually two of them produce most of the reconciliation, and it is almost always the inventory boundary between store point of sale and online fulfilment. Integrating those two may recover most of the hours at a fraction of the price of replacing the stack. A vendor selling a unified platform has no incentive to tell you that.

You learn whether the fix is software at all. Some of the nightly agreeing is caused by systems that cannot talk. Some is caused by a receiving process that nobody follows, a returns desk that does not scan, or a store crediting policy that makes staff prefer not to see online orders at all. Chain Store Age's framing is right on this point: the silo is an alignment problem across inventory, technology, and incentives. Two of those three are not for sale from anyone. Buy the integration before fixing the incentive and you will have a faster way to produce the same wrong number.

And you learn what the vendor's return on investment slide is actually claiming. When the pitch says the platform pays back in fourteen months, ask which of your hours it plans to remove, and check them against your list. We do a version of that arithmetic in the automation ROI math vendors show you, recalculated, and retail integration is where the gap between the slide and the floor tends to be widest.

Where writing stops and the work starts

An article can tell you where the cost is hiding and how to think about it. It cannot walk your stores, sit with the assistant manager who does the nightly match, or find out whether your inventory disagreement is a software gap or a scanning habit. Those answers are different at every retailer we have worked with, and they decide whether integration is a good purchase or an expensive way to keep the same problem.

If you are being pitched unified commerce and nobody in the room can say how many hours your own team spends making the systems agree, that is the number to find before the contract. Talk to us about counting it.