We counted the marketing tools we were paying for and arrived at twenty-three. When we checked actual usage, nine were being used meaningfully and four had not been logged into in six months.
Cutting it down took a quarter and the benefits went beyond the licence costs.
How it got that way
No single decision, which is the usual pattern.
Tools were acquired for specific projects and never removed when the project ended.
Some arrived with people who had used them elsewhere.
Several were bought to solve a problem that a tool we already owned could have solved, because nobody knew the existing tool could do it.
And a few were renewed automatically for years by a finance process that had no visibility into whether anybody used them.
The audit
Straightforward and revealing. For each tool: what it cost annually, who the owner was, when it was last used, what it was used for, and what would break if it were removed.
Several had no identifiable owner, which is the clearest possible signal.
Several were used by one person for one report that nobody read.
Three were duplicates in function, bought by different teams who did not know the others existed.
And two were genuinely essential and under-utilised, which was the most useful finding — we were paying for capabilities we were not using while buying other tools to do the same thing.
The hidden costs beyond licences
The argument that made the case internally, because the licence savings alone were not dramatic.
Integration and maintenance. Every tool connected to others requires those connections to be maintained, and they break.
Data fragmentation. Customer data spread across many systems means no single view, reconciliation work, and reports that disagree with each other.
Training and onboarding. Every new person has to learn a larger surface area.
Security and compliance surface. Every tool holding customer data is an obligation and a risk, and several of ours had access to data they did not need.
That last point was what actually moved the decision, because it turned a cost conversation into a risk conversation.
What we removed and how
The unused ones went immediately, which was uncontroversial.
The duplicates required choosing, which was political. We resolved it by picking on integration with our core systems rather than on feature comparison, which produced defensible decisions.
The single-user tools we assessed individually, and kept two where the person made a case.
And we consolidated several point solutions into capabilities we were already paying for in a larger platform, which required somebody to actually learn that platform properly.
What we kept and why
The principle we arrived at, which has held up.
Keep tools that hold data you cannot easily reproduce, that are used weekly by more than one person, or that do something genuinely specialised that a general platform does badly.
Remove anything used monthly or less, anything with one user who could use something else, and anything whose output nobody acts on.
Be sceptical of anything bought to produce a report, because reports proliferate and are read less than anybody admits.
What went wrong
Two things, in fairness.
We removed one tool that turned out to be doing something load-bearing that nobody had documented, and spent two weeks reconstructing it. The lesson is to disable rather than delete for a period before cancelling.
And we underestimated the migration effort on historical data, which took considerably longer than planned and which is the main reason the project took a quarter rather than a month.
Keeping it from happening again
The governance we put in, which is minimal and has worked.
Any new tool requires a named owner and a stated purpose.
Annual review of the whole stack against usage data, at renewal time rather than after it.
A check against existing capability before any purchase, which requires somebody to actually know what the existing tools do.
And a default assumption that the answer is no, which is a cultural position rather than a process and is the part that matters most.
The build versus buy drift
One further observation from the audit.
Several tools existed because a small internal need had been met by buying software rather than by a small piece of internal work.
That is frequently the right trade and it accumulates. Twelve small subscriptions solving twelve small problems is a substantial annual cost and a substantial integration surface.
The question worth asking on each is whether the problem is still there, which in about a third of our cases it was not. The tool had outlived the situation that produced it, and nobody had noticed because the invoice was small.
Data ownership on exit
The check worth making before removing anything, learned the awkward way.
Establish what data the tool holds, whether it is duplicated elsewhere, and what the export format is.
Some vendors make export straightforward. Some provide it in a form that is technically compliant and practically unusable.
Exporting before cancelling, and confirming the export is readable, is a step we skipped once and will not skip again.