Retail Systems Rarely Share What They Know. The Connection Is Usually a Person.
We reviewed the public record on retail systems that do not share: tills, website, stock and accounts. Here is what we found, what waits while people carry the data, the four ways forward, and the benchmark we would set.
A customer orders a kettle on your website on Friday evening. The website says there are four in stock.
On Saturday morning the warehouse goes to pick it. There are two on the shelf, and both were sold in a store an hour ago. The till knows that. The website does not, because the stock file that joins them is sent once a night.
The order is cancelled with an apology. It happens most weeks.
The paradox: Every system in the business is right about what it was told, and the business as a whole is wrong.
What We Found
For this article we went through the public record on retail systems that do not share what they know: a survey of retail and brand leaders in the UK, one large group’s own account of an in-house system it could no longer build on, and a survey of mid-size firms, from 2023 to 2026.
Four findings stand out.
Most brands that sell direct are not yet joined up. In a survey of more than 100 senior retail and brand leaders in the UK, “Among direct-to-consumer brands, 70% said their core systems were not yet fully integrated”. The survey was paid for by firms that sell to retailers.
Retailers say it costs them. In the same survey, “Some 56% of retailers said fragmented systems were affecting profitability and customer experience”.
An old in-house system can stop new work altogether. A group the source calls a “retail and hospitality giant” described a supply chain portal of its own: “This bespoke system, which was built internally 10 years ago, was obsolete and the business was unable to add new, data-led functionalities.” And: “Before, we didn’t have access to real-time data visibility.” This is an older case, from 2023, about a large group. The record gives no money figure.
Old technology is said to hold mid-size firms back. In a vendor-sponsored survey of 200 leaders at US and UK manufacturers, retailers and wholesalers with revenue between 25 million and 500 million US dollars, 72% agreed that outdated technology is holding them back. That survey is about old technology in general, not about systems that do not share.
The record does not say how the unjoined systems are kept in step. Our reading is that data passes between the tills, the website, the stock system and the accounts every day all the same, carried by people, by timed files and by scripts that nobody has listed.
What our review does not show: We found no named mid-size retailer with this problem, and no case or figure from India or the Middle East. The source for the large group gives no country, and we give none. Both surveys were paid for by firms with something to sell, and they are not named here. We found no figure for what a cancelled order, an hour of re-typing or a failed file costs, and we give none. That unjoined systems are kept in step by people, files and scripts nobody has listed is our reasoning, not a measured finding. The kettle is imagined.
What Waits While People Carry the Data
Our reading is that systems that do not share are a business problem first, and that three things wait on them.
The number to believe. When the website, the tills and the accounts disagree, someone decides which figure is right, every time, in the Monday meeting and at month end.
The next way of selling. Collecting an online order in store, a marketplace listing, one loyalty card: each needs two systems to share one thing, and each stops at the oldest system.
The crossings nobody can see. A nightly file, a spreadsheet, a small program on a spare machine, a person with two screens. When one stops, nothing announces it, and the effect turns up hours later, looking like someone’s mistake.
The staff who carry the data are not the problem. They are doing work that exists only because the systems do not share, and they are usually the only people who know where the crossings are.
The gap we see: most retailers can say that their systems do not talk to each other. Few can say where the data crosses today: which crossings are live links, which are timed files or scripts, which are done by hand, who owns each one, and which of them the next idea depends on. A retailer that holds that list can choose which gap to close first. One that does not keeps patching mismatches one at a time.
This is our reading of the evidence. It is not a measured market figure.
Four Ways Forward, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Let people and spreadsheets carry the data, as now | Volumes are low, and few new ideas depend on the systems sharing | The work grows with every channel, and a stopped file is found by its effects |
| Put a connection layer between the systems, bought from a supplier or built for you | The old systems can already give out what is needed, and are sound otherwise | It depends on systems nobody can change, and needs looking after once it is running |
| Replace everything at once | Most of the systems are failing, and the business is ready for a long programme | Every team changes on one date. The new ideas wait for the whole programme, and the crossings nobody listed are found on launch day |
| Map every crossing, then rebuild the part that has to share, module by module | The systems are old, much changed and used every day, and a few crossings carry most of the problem | It costs money before anything is joined, and the map may show more crossings than anyone expected |
Our recommendation: map every crossing first, including the ones done by hand. Then rebuild the part of your own software that has to share, module by module, while the old system keeps running. If you also want a connection layer, that is your choice and another firm’s product, and the map tells it what is there to join. We have no connection or integration product. We cannot change a packaged product that belongs to another supplier, such as a till system, an accounts package or a marketplace. We do not run or monitor a connection once it is built.
Where You Are Now, and Where You Should Be
Before any work begins we set a benchmark: a few measures taken from your own business, each with a target.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| Places where data crosses between systems | Known in parts, to the people who do them | Every crossing listed, including those done by hand, timed files and scripts | The map of the system as it stands |
| The carrier of each crossing | Not recorded | Each marked as a live link, a timed file, a script or a person | The map, beside the specification |
| Which figure to believe | Argued in meetings | The source of each figure named | The specification |
| What the next idea needs | ”Dependent on replacement” | Each idea traced to the crossing or the part it needs | The staged plan |
| An owner for each crossing | Nobody, or whoever set it up | A named owner on your side | The list beside the specification |
The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a retailer.
How We Work With You
- We listen: a free Reliability Review. A first conversation about your systems, the numbers that disagree, and the ideas that keep stopping. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
- We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
- We read the system and propose: the Legacy System Specification Assessment. Here the system is the software your firm built or had built, such as the stock, order or portal application the others depend on. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
- If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means the part that has to share is rebuilt first. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
- We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.
The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.
What we do not do: we have no connection or integration product, and this article is not leading to one. We cannot change a packaged product that belongs to another supplier; where a system is one, we can describe what goes in and out of it, not what happens inside. We do not run, host or monitor a connection, or any of your systems; your own team does. We do not clean or correct the data that crosses. We do not install or implement a packaged shop platform or a packaged ERP product. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a retailer.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | One picture of where the business’s numbers disagree, and a choice of which gap to close first. |
| CTO or CIO | A map of every place data enters and leaves each system: files, scripts and people included. |
| CFO | The copying and correcting hidden inside month end becomes a list with causes. |
| COO | Operations knows which stock figure each system uses, and where an order can fall between two of them. |
| Head of marketing | Marketing knows what the business really holds about a customer across store and web, before a campaign promises it. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| A large retail and hospitality group said its ten-year-old in-house portal “was obsolete and the business was unable to add new, data-led functionalities”. | Our part is narrower, and the group was not an IOanyT client. For a retailer’s own software, our assessment maps how it is joined to the other systems and what rebuilding the part that has to share would take. We sell no product to put in its place. |
| In a UK survey, 70% of direct-to-consumer brands said their core systems were not yet fully integrated. | We have no connection product. We map where data crosses between a retailer’s systems, including by hand, and rebuild the retailer’s own part that has to share, module by module. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We start by finding out how your systems are joined today, because nobody can say what to join until someone has drawn it.