Tool sprawl is not an efficiency problem

Tool sprawl costs you continuity of commercial truth, not just licences and logins.

The efficiency framing is the one everybody reaches for. A few extra subscriptions, some duplicate entry, a bit of switching between systems. Annoying, quantifiable, manageable. That framing is not wrong, but it prices the smallest part of the problem.

The mistaken diagnosis

Read as an efficiency problem, sprawl looks like a procurement exercise. Consolidate licences, cut the two tools nobody uses, negotiate the rest.

What that misses is what fragmentation does to the record. When scope lives in one place, delivery updates in another and billing logic in a third, the business loses continuity between what was sold, what is being delivered and what can be billed. Statuses stop matching. Assumptions get lost at the boundary. Finance rebuilds the story at month end because no single system owns it.

At that point the problem is not tool sprawl. It is a broken operating chain, and the cost is not measured in licences.

Price the swivel first

Before arguing about it, count it. Take one recent invoice cycle and count four things: hand-overs between tools, duplicate entries, corrections and write-offs, and minutes spent reconciling.

Then price it. Minutes per invoice, times invoices per month, times a loaded hourly rate. That is your monthly swivel tax, and it is a real number you can put in front of a partner group rather than an assertion.

The arithmetic is deliberately crude, and it is still more honest than a vendor estimate. It also has a second use: it tells you the size of the prize before you commit to anything, which is the only responsible order to do this in.

There is a quicker diagnostic if you want the qualitative version. Ask three people — one from sales, one from delivery, one from finance — to describe the same job. Three different answers is not a communication problem. It is three systems, each internally consistent, disagreeing.

Why the standard remedy usually disappoints

The instinctive fix is an integration programme. APIs, middleware, a synchronisation layer that keeps the tools agreeing.

The category-level evidence is not encouraging. MuleSoft’s 2025 Connectivity Benchmark Report, summarised by Salesforce, surveyed 1,050 enterprise IT leaders and found that only 29% of applications are typically connected within an organisation, with 95% of respondents reporting difficulty integrating data across systems. Those are large-enterprise figures rather than mid-sized services firms, so treat them as directional — but the direction is consistent with what firms report.

The structural reason is worth naming. Integration synchronises fields. It does not establish which system is authoritative when two of them disagree, and disagreement is precisely what happens when a rate is changed in one place and a timesheet is approved in another. You end up with the same three versions of the truth, arriving faster.

Integration is the right tool for moving data between systems that own genuinely different things — your ledger is a good example, and the patterns for that are on our integrations page. It is the wrong tool for deciding who owns the commercial record.

The mechanism

Consolidation only pays if what gets consolidated is the record, not the interface.

That means the engagement carries its commercial rules from the point it is quoted, so time entered against it inherits those rules rather than being reclassified downstream. Approvals are states on the record. Change orders attach to the engagement they change. WIP entries link back to the work, the approval and the clause that permits billing, so the invoice is assembled from evidence rather than from recollection. How that runs through to billing is described on our invoicing and WIP page.

The test of whether you have done this is not how many tools you have. It is whether a number can be interrogated without a meeting — which is the same test as reporting on top of disagreement.

When consolidation is the wrong call

Sometimes the arithmetic says stay, and that is the honest outcome of doing the arithmetic properly.

For a firm with two tools and twenty people, the swivel tax is genuinely smaller than the switching cost. Migration, retraining, a quarter of reduced throughput and the risk of getting it wrong are real costs paid up front against a saving that accrues slowly. Do the sum and act on the answer, including when the answer is no.

Consolidation also means giving up best-of-breed tools your teams may prefer for good reasons. A specialist design or engineering tool usually beats the equivalent module inside a platform, and telling your delivery leads otherwise will cost you credibility you need later. The workable position is usually that specialist tools keep doing specialist work, and the commercial record stops being distributed across them.

And consolidation concentrates risk. One vendor, one availability profile, one renewal negotiation. That is a genuine trade, not a rounding error, and it should be made deliberately rather than as a side effect of tidying up.

The position, restated: count the swivel tax, then decide whether the problem you have is duplicated effort or discontinuous truth. Only the second one justifies changing your operating model, and only the arithmetic will tell you which one you have.