The Tool Sprawl Audit: Counting What You Actually Use vs. What You Pay For

‍TL;DR: A tool sprawl audit compares two lists directly: every tool currently being paid for, pulled from finance's subscription and invoice records, against every tool someone has actually logged into or used in the last 60 days, pulled from login activity where available. The gap between these two lists, tools being paid for with no recent usage, is the actual sprawl, not a general sense that "we have too many tools." Most companies have never run this specific two-list comparison, which is exactly why the gap tends to be larger than anyone expects once it's actually measured.

‍

"We probably have too many tools" is a common, vague complaint at growing B2B SaaS companies, and it rarely leads to action because nobody's actually measured the specific size of the problem. A tool sprawl audit fixes this by comparing two concrete lists rather than relying on a general feeling: what's being paid for, and what's actually being used.

Why the vague version of this complaint never gets resolved

"Too many tools" is a feeling, not a finding. It's easy to voice in a team meeting and easy to nod along with, and it almost never leads anywhere because nobody has actually named which specific tools are the problem or how much money is involved. A tool sprawl audit replaces the vague complaint with two specific lists that can be directly compared, which turns a feeling into a decision-ready finding.

The two lists, and how to build each one

Why finance's records are the right starting point, not IT's

Finance holds the most complete record of what a company is actually paying for, since every subscription eventually shows up as a card charge or an invoice, regardless of which team originally set it up or whether IT was ever formally looped in. A tool sprawl audit starting from an IT-maintained software inventory often misses tools that individual teams purchased directly on a company card without going through any formal procurement process, which is precisely the category of tool most likely to be quietly forgotten and still being paid for.

Why login activity is a more honest measure than asking people directly

Asking a team "are you still using this tool" tends to produce an overly generous answer, since admitting a tool isn't being used can feel like admitting a mistake was made in requesting it originally. Pulling actual login activity, where the tool's admin panel supports it, removes this social pressure entirely and produces a more honest picture. For tools without exportable login data, a direct question is still useful, but it's worth phrasing it specifically, "when did you last log in and for what task," rather than a general "are we still using this," since the specific version is harder to answer vaguely.

What the gap between the two lists actually reveals

Once both lists exist, the comparison is mechanical: any tool appearing on the paid-for list with no corresponding recent usage on the actual-usage list is a sprawl candidate. This comparison typically surfaces three recurring patterns: a tool purchased for a specific project that ended months ago and was never cancelled, a tool with overlapping functionality to another tool the team switched to without formally retiring the first one, and a tool purchased by someone who has since left the company, with nobody currently using it or even aware it's still being billed.

Why overlapping functionality is the hardest sprawl pattern to catch

A tool that's simply unused shows up clearly once login activity is checked. A tool that overlaps in functionality with another active tool is harder to catch, because both tools might show some usage, just split between two systems doing substantially the same job. This pattern requires a slightly different check: for each pair of tools serving a similar function, ask directly whether the company genuinely needs both, or whether one has effectively become the default and the other is running on residual habit from a small subset of users who never fully switched over.

Why this connects directly to a broader CRM and RevOps hygiene practice

Tool sprawl and CRM data hygiene are closely related problems, since a company running multiple overlapping tools often ends up with fragmented data spread across systems that don't talk to each other cleanly. purple path's breakdown of who should own CRM data hygiene as a company scales covers the ownership question for the core CRM specifically; the same ownership logic applies to the broader martech stack, since tool sprawl, like CRM hygiene, tends to reaccumulate without an explicitly named owner responsible for periodically running exactly this kind of audit.

Why the cost side of this audit often surprises leadership more than the usage side

Once the two lists are built and compared, totaling the actual cost of the unused tools frequently produces a bigger number than anyone expected, since individual subscriptions that look modest on their own, a few hundred euros a month here, a similar amount there, add up considerably faster in aggregate than any single line item suggests. Presenting this total cost figure directly to leadership, rather than a general description of "some unused tools," tends to generate faster action, since a specific number attached to a specific list of cancellable subscriptions is a much easier decision to act on than an abstract sense of inefficiency.

What to actually do once the sprawl list is built

Not every tool on the unused list should be cancelled immediately. Some tools genuinely serve an infrequent but important purpose, an annual compliance tool used once a year, for instance, that would look like sprawl under a 60-day usage window but is actually functioning exactly as intended. The sprawl audit's output should be treated as a list of candidates for a closer look, not an automatic cancellation list, with each candidate getting a quick direct check with whoever originally requested it before any subscription actually gets cancelled.

How often this audit should be repeated

Running this exact two-list comparison annually, ideally timed a few weeks before major subscription renewal dates, catches most sprawl before it accumulates into a large, sprawling problem requiring another disruptive audit. purple path's recurring HubSpot health check follows the same underlying logic applied specifically to CRM workflows and fields; extending that same recurring-audit habit to the broader martech stack keeps the whole system, not just the core CRM, from drifting back toward sprawl between larger cleanup efforts.

Why a tool's original purpose matters when deciding what to do with the sprawl finding

Once a candidate tool is confirmed genuinely unused, the decision isn't always a simple cancellation. Some tools were purchased for a specific, time-bound purpose, supporting a single product launch or a particular campaign, and their current lack of usage is entirely expected rather than a sign of neglect. Others were purchased as an ongoing capability that simply never got properly adopted. Distinguishing between these two cases before cancelling anything matters, since the first case might still need a similar tool for the next comparable project, while the second case points to a deeper adoption failure worth understanding before deciding whether to replace the tool or invest in better rolling it out.

Why involving the original budget holder changes how this audit gets received

A tool sprawl audit run entirely by finance or by a systems owner, without input from whoever originally requested each tool, risks feeling like an audit performed on people rather than with them, which can create defensiveness that makes the whole exercise harder to complete cleanly. Involving the relevant budget holder directly in reviewing the findings for their own team's tools, framed as a joint cost and usage review rather than an accusation, tends to produce faster, more cooperative decisions about what to cancel, consolidate, or keep.

Frequently Asked Questions

How far back should login activity data be pulled for this audit?

60 days is a reasonable default window for most tools, though a tool with a naturally infrequent use case, an annual reporting tool, for example, needs a longer window or a direct conversation rather than being judged against a 60-day cutoff that doesn't match its actual usage pattern.

What if a tool shows low usage but only one or two people actually need it?

Low usage isn't automatically a problem if it reflects a genuinely small user base with a real, ongoing need, rather than a tool nobody uses at all. The audit should distinguish between "few people use this because few people need it" and "nobody uses this at all," since only the second case is a clear sprawl candidate.

Who should actually run this audit?

Ideally whoever holds broader systems ownership responsibility for the martech stack, following the same accountability logic covered in a broader RevOps staffing framework, rather than leaving it to finance alone, since finance can identify the cost side but usually lacks visibility into actual usage patterns without input from the teams using each tool.

Is it worth involving the original requester of each tool before cancelling it?

Yes, a brief check-in before cancellation catches the cases where a tool looks unused in the data but is actually serving an infrequent, legitimate purpose that a simple usage-window check wouldn't capture on its own.

How does tool sprawl typically accumulate in the first place?

Individual teams purchasing tools directly for a specific need, often without a formal procurement or renewal review process, is the most common accumulation path, and it compounds over time as teams change, priorities shift, and nobody circles back to reassess whether each original purchase is still justified.

‍

Running this two-list comparison against your own subscriptions and login data is a focused project that usually surfaces more savings than expected. Talk to purple path about auditing your current martech stack for tool sprawl.