How to tell if a business tool is actually being used.

Most small businesses have the same quiet problem. There is software they are paying for but do not use, and nobody is quite sure how much of it there is.

It accumulates the way these things always do. Someone bought a tool eighteen months ago to solve a real problem. It worked for a while. The person who championed it left, or moved roles, or the problem changed shape. The tool kept billing. Nobody noticed, because the direct debit is small enough to slide past the monthly review, and large enough to add up across twenty of them.

I spent a long stretch of my career on the inside of businesses like this. The pattern is consistent across every one I have worked in. A meaningful slice of the software bill, somewhere between fifteen and forty per cent depending on how strictly you count, is usually going on tools nobody has opened in months. That is not a number I can promise applies to every business. But it is enough that the bill is worth a proper look.

This is not anyone’s fault. Software has become very easy to buy and very hard to inventory. The cost of any individual tool is small. The cost of the pile is meaningful, but it is the kind of cost that does not show up as a single line on a P&L. It hides in eighteen direct debits of fifteen to ninety pounds each, signed off by different people, billed to different cards.

Why this is bigger than the money

The wasted spend is the obvious problem and the smallest part of it.

The real cost of unused tools is what they do to the team. Every tool a business buys carries an implied instruction: this is part of how we work now. When the team can see that half the tools they were told to use are not actually being used by anyone, the implied instruction quietly degrades. It teaches them that what the business says it does and what it actually does are different things. After a while, the same scepticism extends to the tools that do matter.

There is a related cost in attention. A business that runs on twenty-two tools spread across six different logins is harder to think in than a business that runs on eight. The team spends a small amount of time every day deciding which place to go for which thing, and answering the same question slightly differently depending on which tool they happened to use.

And there is a cost in trust with the team. New hires arrive, are pointed at the full stack of tools the business technically uses, and quickly work out which ones are real. They learn the actual operating system of the business by watching, not by being told. The business that knows what its tools are for has a head start on every new hire.

How to audit what you are actually using

This is one of the easier things a small business can do, and one of the highest-return.

The exercise takes about two hours. It needs the finance person, the operations lead, and whoever runs the work day to day in the room together. A laptop, a spreadsheet, and the bank statements for the last three months.

Start with the bank statements. Go through every direct debit and card payment to a software company and write it down. Tool name, monthly cost, who set it up, who currently owns it. You will almost certainly find five to ten you had forgotten about. Add to the list anything that is billed annually and is not yet on the statement.

For each tool, ask three questions. Who logged into this in the last month. What job is it doing that nothing else does. If we paused it tomorrow, what would actually break.

If the answer to the first question is nobody, the tool is not in active use. If the answer to the second is “it overlaps with another tool we have,” it is a duplicate. If the answer to the third is “nothing immediate,” the tool is dormant.

That is it. The whole audit is those three questions, applied honestly. The people in the room will know the truth. The job is to write it down.

You will end up with three piles. Tools that are clearly working, where the answers are confident and specific. Tools that nobody can defend, where the right call is usually to cancel. And a middle pile, where someone thinks the tool might still be in use but cannot quite say by whom or for what.

What to do with the middle pile

The middle pile is the interesting one. It is also where most of the bad calls get made, in both directions.

The temptation is either to cancel everything you cannot defend immediately, or to leave the whole pile alone because cancelling feels risky. Neither is right. The middle pile is mostly an information problem. You do not yet know whether the tool is doing real work, and the answer is to find out before you decide.

A simple way to do that. For each tool in the middle pile, send a short note to the team naming the tool, asking who uses it and what for, and saying that if nobody comes back within two weeks you will assume it is dormant and pause it. Most modern SaaS tools have a pause or downgrade option that costs little and keeps the data intact. Pause, do not delete. Set a calendar reminder for thirty days and check what, if anything, broke.

This is gentler than the gut response, but it is more useful in practice. It turns the question from “should we keep paying for this” into “is this actually part of how the business runs.” A tool that nobody mentions when you ask is, almost by definition, not part of how the business runs. A tool that someone comes back to defend, even quietly, probably is.

The same principle applies to features inside tools you are definitely keeping. If you are on the premium tier of something and nobody can name what the premium tier gives you, ask. If nobody can answer within a fortnight, that is information worth acting on.

What it does beyond the saving

The interesting part of doing this properly is not the money saved. It is what happens next.

The act of going through the stack and being honest about what is actually working makes it easier, in the months that follow, to be honest about other things. A few processes get similar treatment. So do some meetings. The discipline of asking what is earning its place, rather than letting things continue by default, becomes something the business does for itself.

That is the part most consultants will not write about, because the saving on cancelled software is too small to send a proposal about. But the saving is not really the point. The point is the habit underneath it. A business that knows what its tools are for is a business that knows what its work is for, and those are not coincidences.

So here is the test, if you want one. Open the bank statements for the last three months. Write down every software direct debit. Ask the three questions about each one. Be honest, especially about the middle pile, and give yourself the time to find out before you cancel anything.

Most businesses that do this end up with a quieter stack, a clearer team, and a habit they did not have before. The money is the smallest of the three.

If you want a second pair of eyes on what your stack is doing and what could come out of it, that is part of what an audit covers. Either way, I write something like this most weeks. You are welcome to follow along.