The tell is usually a spreadsheet.
Somebody opens a laptop to show you the system of record, and next to the system of record there is a spreadsheet. Sometimes it lives on a shared drive. Sometimes it gets emailed around as an attachment with a date in the filename. The person who maintains it is slightly embarrassed to show it to you, and then they explain it, and the explanation makes complete sense. The tool cannot express something the work actually requires, so a human built a shim out of columns.
I spent years in vendor risk and GRC, assessing other companies from the outside. Hundreds of them. Different industries, different sizes, wildly different maturity. Shadow spreadsheets are everywhere, which means finding one tells you almost nothing by itself. Most of them are fine. Somebody's scratchpad, a one-off pivot for a board deck, the last mile between a report and a meeting. Those are not worth your time.
The ones worth pulling the thread on have two properties. More than one person depends on the spreadsheet, and nobody was ever asked to build it. When both of those are true, you are looking at a process the organization relies on and has never acknowledged owning. The spreadsheet is free, and unlike almost everything else you will be shown that day, it was built by someone with no incentive to make it look good.
The instinct when you find one is to go shopping. Replace the tool with a better tool. I want to be honest about the limits of my own argument here, because a spreadsheet will grow next to most tools eventually. Software meets real work and there is always a seam. What matters is whether the seam is small and shrinking, or whether the seam is where the actual decisions are being made.
Why you will rarely hear this from the person selling you something
Most technology advice in the mid-market comes from someone who makes money when you buy. An MSP that resells licenses has a margin on every seat. A VAR gets a rebate tier. A managed security provider bundles a platform and prices the service around it. Everyone in that chain has a margin on the sale. The people doing that work are frequently good at it and genuinely trying to help. But when the honest answer is "you already own three things that do this, the problem is that nobody owns the process," there is no line item for that answer. It does not renew. It does not appear on anyone's quota.
So it does not get said often.
I am in a strange position here. I build infrastructure. I design, provision and run production systems: mesh networking, automated server builds, single sign-on, monitoring, backups, the whole stack. I could sell you a server this afternoon and I would enjoy it. That is exactly why "you don't need one" carries weight coming from me. I am talking myself out of the more profitable engagement, and I know precisely what the more profitable engagement looks like, because I could do it well.
What tool sprawl actually costs
The license fee is the part everyone can see, and it is usually the smallest part.
Every additional system is an identity to provision and deprovision. In vendor risk, the part that surprised people was the paperwork: each vendor is a questionnaire to send, a SOC 2 report somebody has to actually read, a data processing agreement, a renewal date, and an access review to sit through every quarter, and none of that work appears next to the subscription price when the purchase gets approved. Then there is the admin who knows how the thing works and is now a single point of failure.
This connects back to the spreadsheet more directly than it looks. The reason two systems disagree about a customer is usually that two teams entered the data under two different definitions, and the spreadsheet is where somebody reconciles them by hand every week. That is the cost, and it is invisible in the budget because it is being paid in somebody's afternoons. Every department hits its target and the company still misses.
There is a quieter cost too, and it comes out of my NOC and SOC years. Every tool with alerting adds signal, and most of that signal is not worth acting on. The hard part was never receiving more information. It was knowing which pages deserve a human at two in the morning. Buy enough tools and you manufacture an environment where nobody can tell anymore, and then a real alert arrives and gets triaged like all the others.
Consolidation is boring and it usually works
Before any of the security work, I ran CNC machines and wrote the programs that drove them. Manufacturing teaches you something about setup. Most scrap does not come from a machine that lacks capability. It comes from a setup error, a fixture that shifted, a tolerance stack nobody checked. The lathe was fine. The lathe was always fine.
Then years of phone support at Gateway and GoDaddy, thousands of calls, and the most durable lesson of my career: the stated problem is almost never the actual fault. The customer tells you the printer is broken. The printer is fine. They changed networks last Tuesday. If you buy a printer you have spent money and still have the problem, and now you also have two printers. After that came Linux support at LodgeNet and a long stretch administering enterprise Windows and Linux estates, which is where you learn what an organization genuinely owns versus what it thinks it owns. Those are rarely the same list.
Consolidation work is unglamorous, and the reason it stalls is not technical. You start by finding out what is actually deployed, which is always more than anyone believes and which is the step where somebody discovers a system they are personally responsible for and had forgotten. Then you find out who uses each thing and what for, described in their words rather than the vendor's, and the answers will not match the procurement justification. Then you decide which overlapping tool wins, and this is where it gets political, because one of them was championed by someone who is still in the building. Then you kill the losers properly, including the data migration nobody wants to own, which will be the thing still unfinished six months later if you do not name a person.
Nobody gets promoted for this. Nobody sends an email announcing it. It is also frequently where the savings are, and I would rather say "frequently" than put a number on it I cannot show you.
When buying is the right answer
Some things are genuinely not your business. I do not write my own email server. I do not run my own certificate authority. There are firms that do those things well, at a scale and with an operational discipline I cannot match for the money.
Then there is the case where the capability is missing rather than misapplied. If nobody can see what is happening on your network, no amount of process design creates visibility from nothing. You need the instrument. Buy the instrument.
Buy when you have a compliance obligation with a hard edge and a deadline and the tool is the shortest path to satisfying it. Buy when the manual workaround has a person in it who is going to quit. And buy when you have measured the current state and can say what better looks like, because then you will be able to tell afterward whether it worked. A recommendation nobody tests is just an opinion in a nicer font, and that applies to mine as much as anyone's.
I also have to be fair about what my preferred answer costs. Getting four people to agree on a definition and write it down is not free. It needs an executive sponsor, sustained attention across months, and somebody with the authority to break a tie. Buying the tool converts an unbounded political fight into a bounded expense one person can approve, and framed that way it is a rational purchase. I still think it is usually the wrong one, for a specific reason. The fight does not go away, it moves. It reappears as the spreadsheet next to the new tool, and now you are paying for the tool and still having the argument, except the argument is happening in a file nobody is accountable for.
What I actually do with the spreadsheet
My method is the same everywhere: observe, measure, map, identify, experiment, measure again. With a spreadsheet that means I ask to see it, and then I ask the person who maintains it to walk me through a week of it. Not the design of it. The use of it. Where it gets updated, who reads it, what happens when it disagrees with the system of record, which column caused an argument.
Usually somewhere in that walkthrough is the real fault. Two teams entering the same thing with different definitions. A handoff with no owner. An approval step that exists for a reason nobody in the room can name. Kahneman, Sibony and Sunstein call this kind of thing noise: unwanted variability in judgments that were all supposed to land in the same place. When four people need to agree on what "active customer" means, that is what you are looking at, and it is expensive. It does not explain everything, and I try not to stretch it further than it goes.
My recommendation does not always hold, either. The failure mode I have watched is decay. A definition gets agreed, written down, and works. Then the person who convened that agreement changes roles, nobody inherits the job of maintaining it, and the teams drift back to entering the data their own way. A process fix with no owner has a shelf life, the same as a tool purchase does. If I recommend one and do not tell you who has to keep holding it, I have sold you something that expires quietly.
Somebody built that spreadsheet because they cared enough about getting the work done to solve it themselves, with the only tool they had unrestricted access to. That person already knows what is wrong. The consulting is mostly getting a room to listen to them.