You know the systems need fixing. You see it every day in the duplicated effort, the manual workarounds, the information that lives in too many places, the team spending time on tasks that a better-connected setup would handle automatically. The problem is getting the people who can approve the investment to see what you see.

This is one of the most common positions operations, marketing, and sales managers find themselves in. They have a clear picture of what's wrong and a reasonable sense of what it would take to fix it. What they don't have is a leadership team that has ever had to quantify the cost of the current state because the costs are invisible. Spread across dozens of small inefficiencies rather than concentrated in one line on a report, operational debt rarely makes it into a board conversation unless someone puts it there deliberately.

This post is about how to do that effectively.

The common mistake

The instinct when making a case for a systems overhaul is to describe the problem. To explain how the team is spending time on things it shouldn't be spending time on, how the tools aren't talking to each other, how information is scattered and hard to find.

The problem with this approach is that leadership has usually heard some version of it before. "Our systems are a mess" is a complaint, not a proposal. And complaints, however legitimate, are easy to defer with a "we'll look at it after the next growth phase" or a "let's revisit this in Q3."

What's harder to defer is a number. A specific, calculated estimate of what the current state is costing the business annually in time, in errors, in revenue that's falling through the gaps. When the cost of doing nothing is visible, doing nothing stops being a neutral choice.

Start with the cost of the current state

Before you can make a compelling case for change, you need to quantify what staying the same is costing. It may feel speculative, but the methodology is straightforward, and even conservative estimates tend to produce figures that make the case clearly.

The time cost. Take the number of people affected by the operational inefficiency. Estimate how many hours per week each person spends on tasks that a better-connected system could handle automatically like manual data entry, searching for information in the wrong place, duplicating effort, chasing updates that should be visible. Multiply by their hourly cost. Multiply that by 48 working weeks. That's your annual time cost.

Research from McKinsey suggests knowledge workers spend roughly 20% of their working week searching for information or chasing colleagues for updates. Asana's UK data puts the figure on duplicated work alone at 227 hours per person per year. Even at half those figures, for a small team, the number is significant.

The error cost. Manual data entry runs at a 1-1.5% error rate. Each error that travels through connected systems costs between £40 and £120 to fix, once you account for the time to identify it, correct it, and communicate the correction. Estimate the number of manual data entries or transfers your team makes per week, apply a 1% error rate, and multiply by a conservative correction cost.

The revenue leakage cost. Disconnected processes cause roughly 1-3% of revenue to go unbilled or untracked from missed follow-ups, lost quotes, uninvoiced work that falls through the gap between systems. Multiply your approximate annual revenue by 1% for a conservative estimate of what's leaking.

Add the three figures together. That's your estimated annual cost of the current state. If the figure feels high, that's the point. This cost has always been there. It just hasn't been visible on any report.

Be explicit about the cost of delay

Leadership teams often respond to a systems overhaul proposal with a version of: we'll get to it once things calm down, or let's wait until after the next growth phase.

The problem with this logic is that it treats the systems problem as something that will cost the same to fix in eighteen months as it does today. It won't. Operational debt compounds. Every growth phase added on top of a disconnected system makes the eventual fix more expensive and more disruptive. The workarounds that feel manageable with a team of ten require twice the manual effort with a team of twenty and create four times the confusion, because now more people are involved in more handoffs.

McKinsey research shows that 10-20% of every new project or initiative budget is diverted to resolving issues caused by existing disconnected systems. The next hire will absorb the same manual processes. The next growth phase will multiply the duplication. The cheapest time to fix this is before the next phase, not after it.

A useful question to put to leadership: if our team doubles in the next two years, what does our current way of working look like with twice as many people trying to operate it?

Present the evidence for what fixing it delivers

There is substantial published evidence on what businesses achieve when they move from disconnected, manually-maintained systems to connected, integrated ones.

Businesses with integrated systems are 2.5 times more likely to achieve cost and time efficiencies than those with siloed tools, according to research. Forrester data on organisations that implemented proper systems integration shows a 30% improvement in productivity. UK case studies show a 50% reduction in daily admin when tools are properly consolidated with staff previously spending one to three hours a day moving between platforms.

You don't need to use all of this. Pick two or three outcomes that are most relevant to your specific situation and describe what they would mean for your team concretely. A 30% productivity improvement for a team of five is worth a specific number of hours per week. Say what those hours could go toward instead.

Ensure what you're asking for is clear

The difference between a systems overhaul proposal that gets approved and one that gets deferred is usually specificity. A vague ask is easy to defer. A clear, costed, phased proposal is much harder to say no to.

Be specific about what you're proposing including what would change, what would be built or fixed, and who would be involved. Give a realistic timeline. Provide a cost estimate, or note that getting a quote is the first step.

If the full scope feels like a large commitment, a phased approach often gets faster approval. The first phase delivers a concrete, measurable outcome and gives leadership evidence before committing to the next. An audit phase is often the right starting point as it produces a clear picture of what needs fixing and in what order, without requiring approval for the full implementation upfront.

Prepare for questions

Leadership teams ask predictable questions when presented with a systems overhaul proposal. Preparing for them in advance significantly increases the chances of approval in the room rather than a request to come back with more information.

How confident are we in these numbers? The honest answer is that they're estimates based on conservative assumptions drawn from published research. Even at half the estimated figure, the case for change holds.

What if the team doesn't use the new system? The research is clear that adoption depends on whether the system is built around how the team actually works, not imposed on top of it. This is why the process matters as much as the tool and why the proposal should include how the team will be trained and supported through the transition.

We've tried this before and it didn't work. Most systems projects fail due to poor scoping, inadequate training, or building the tool before mapping the processes. A well-structured overhaul addresses those failure modes specifically.

Why now rather than after the next milestone? Every growth phase added on top of disconnected systems raises the eventual cost of fixing them. The cheapest time to fix this is before the next phase of growth, not after.

A resource that does most of the heavy lifting

If you're an operations, marketing, or sales manager who knows the systems need fixing but needs help making the case, I've put together a free business case template specifically for this situation.

It includes the research summaries, the cost calculation tables, suggested responses to the questions leadership is most likely to ask, and a one-page summary you can hand to a leadership team at the end of a presentation. Everything is pre-written and you add your own numbers and context. It draws from published research from McKinsey, Gartner, Asana, Salesforce, Deloitte, and Forrester, as well as real UK SME case studies.

Download the free business case template here.

If you've made the case and got the approval - or if you'd like to talk through what a systems overhaul would actually look like for your business - Evolve is designed for exactly this situation. It starts with a full operational audit, moves through clear recommendations, and ends with full implementation of everything agreed.