3 common misconceptions in retail IT - The true cost and the fix that holds

Janne Kärkkäinen

June 12, 2026
min read
Explore this topic with AI
Open ChatGPT×

Retail IT runs on promises you can rarely keep.

Saturday at peak. Or the week before Christmas. A store goes down. EPoS unresponsive, payments failing, tills dark. The operations director is calling. The store manager is calling. Your team is on the phone to three different service desks, each of whom has logged the incident in their own system, updated their own ticket, and is waiting for information from someone else.

An hour passes. The incident crosses a vendor boundary and slows to a crawl.

Nobody disputes that something is wrong. The EPoS partner thinks it might be the network. The network provider sees nothing at their end. The field service firm is waiting on a dispatch authorisation that needs sign-off from the managed service. You are the sign-off. You are also the person chasing all three of them while the operations director's calls go unanswered.

The technology is rarely the problem. The operating model is.

With that in mind, we’ve broken down the three misconceptions we hear most frequently when diagnosing retail IT issues.

Misconception 1: "Our vendors are good, so the system should work."

Large retail enterprises are not running one IT operation. They are running a three-layer operation simultaneously.

The internal layer: store systems, workplace IT, network and infrastructure, e-commerce platforms, supply chain, finance, security, data and analytics. All generating tickets. All dependent on external parties to resolve them.

The prime provider layer: managed service, field service, EPoS partner, network and telecoms, cloud and infrastructure, digital and application support, security operations, logistics. Each contracted independently. Each operating in their own tooling, with their own process, and their own definition of done.

The extended layer behind the prime providers: subcontracted service desks, field engineers, specialist repair partners, technology suppliers. Largely invisible to the retailer. Extremely important when something breaks.

This is the operating model that exists across every enterprise retailer in the UK. It was built through decades of procurement decisions, outsourcing waves, and technology investment cycles. 

But none of them were designed with the integration layer in mind.

The result is an IT estate where the vendors are good, the contracts are solid, but no one is accountable for the connections between them.

On a normal day, that's holding up. On a bad day, it's a major problem.

Misconception 2: "Someone must own what happens between vendors."

In theory, yes. In practice, nobody does. And that gap is exactly where incidents go to grow.

When an incident stays inside one vendor's domain, it resolves reasonably well. When it crosses a boundary - internal to external, prime provider to subcontractor, network to field service - it enters a gap where no one has operational visibility. No one is really accountable.

Tickets bounce. Updates lag. Each party works in their own system. The IT team in the middle chases updates across multiple outlets, while the SLA clock runs.

The person carrying this is the IT or Service Delivery Manager. They’re accountable for outcomes they cannot control, in an operating model not built to hold up to the pressures of retail IT.

They can’t promise the store manager when the terminal will be back up. They can’t promise the operations director it won’t happen again next week. They can only manage the situation as it unfolds. And write the post-incident review that says the same thing it said last time.

The join between vendors has no structural owner. Until someone builds one in, the IT team in the middle fills the gap manually, every time.

The real pain is not complexity. It's the unpredictability this causes.

Misconception 3: "We've tried everything to fix this."

Most teams have. The approaches are consistently limited, because they treat the symptom, not the cause.

Contractual pressure. You require vendors to use your portal, follow your workflow, meet your SLA terms. In practice, vendors comply minimally and run their real operations elsewhere. The result is double entry, untrustworthy data, and a governance burden nobody budgeted for.

Point-to-point connectors. Build custom integrations between key systems. These work until something changes (a field update, a new vendor, a version upgrade), and then they break. Each break is an incident. Each fix is a project. The integration layer becomes a maintenance liability.

More people. Hire to cover the coordination gap. This scales linearly, with complexity. Every new vendor, every new store format, every acquisition adds to the manual overhead. The estate grows faster than the team can follow.

None of these solve the underlying problem. They manage around it.

What the problem really costs

For large retail enterprises, an hour of IT downtime costs over $5 million. High competition, low customer tolerance, no margin for extended outages.

More than 70% of SLA breaches in multi-vendor IT environments are traceable to integration failures: connectivity loss, data sync delays, slow incident detection across disconnected systems. 

A quarter of all IT time in the average enterprise goes to vendor management overhead. Not delivery. Not improvement. Coordination that exists because the operating model requires it.

And the downstream commercial consequence: 40% of customers leave after a single unresolved service incident.

The fix that actually holds

Most teams respond reactively. More people. More process. Another post-incident review that says the same thing. These manage around the problem. They don't solve it.

ONEiO solves it structurally. By owning the layer between the vendors so you don't have to.

In practice, that means connecting your entire vendor ecosystem without replacing a single tool or renegotiating a single contract. Every provider keeps their own platform. ONEiO makes the service chain behave as one operating model.

When an incident crosses a vendor boundary, it moves automatically. No manual handoff. No phone call between service desks. What happens at the join stops being your problem to manage manually. One view across all parties, in real time.

The operational difference is vast. Incidents that used to depend on effort resolve at the speed of the model. Teams that were absorbed by coordination get that capacity back. SLA misses that had no clear cause become identifiable, addressable, fixable.

And it is delivered as a fully managed service. ONEiO owns the delivery, the operations, and the outcomes. No integration workload added to your team.

Retail IT does not fail because one vendor is bad at their job. It fails because no one owns the connections between them. ONEiO was built to own it.

Questions and Answers

No items found.

Jump to a section

Share this article

Scale integrations with ease – even as demands accelerate

Find out how ONEiO can help you meet demanding businesses' requirements at speed.
Close Cookie Preference Manager
Cookie Settings
By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage and assist in our marketing efforts. More info
Strictly Necessary (Always Active)
Cookies required to enable basic website functionality.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.