Perspectives · 2026-07-20 · 5 min
The spreadsheet is the tell
Why do companies still run on spreadsheets when they pay for SaaS?
Because software you rent fits its vendor's median customer, not any real process. The gap between what the tool does and what the work needs gets bridged by hand — exports, re-keying, reconciliation — and the bridge is usually a workbook someone maintains every week. That recurring, load-bearing spreadsheet is the most reliable diagnostic in a software audit: each one marks the exact place where the tool stopped and unpaid labor started, which is also where an owned replacement pays back fastest, because the logic already exists — in the workbook's columns and the operator's head.
Somewhere in your company there is a workbook that gets exported every Monday, cleaned by hand, and emailed to the people who actually need it. It has a name like final_v7. Officially, the process it covers lives in a tool you pay for by the seat. Practically, the workbook is the system of record and the tool is where the data sleeps between exports.
The workbook exists for an unglamorous reason: off-the-shelf software is built for the vendor's median customer, and no real company is the median customer. Most of your process fits the tool. The last stretch doesn't — the approval that crosses two systems, the report finance wants in a shape the vendor never imagined, the field that means something different in your industry. Software can't bridge that gap, so a person does: export, re-key, reconcile, repeat. That labor is a cost too. It just never appears on an invoice.
The spreadsheet is the third member of a family, and its siblings are better known. The first is lock-in: your data shaped to the vendor's object model, your team's habits shaped to the vendor's screens, until the cost of leaving does the renewal negotiation for them. The second is paying for more than you use — and the seat count is only the visible half. The quieter half is features: plan tiers are designed so the one capability a single team needs sits a tier up, and per-seat pricing multiplies that decision across the whole company. One team's needed feature drags every seat to Enterprise. You don't just pay for empty chairs; you pay for empty features, at every occupied chair.
What makes the spreadsheet special among the three is that it is evidence you can hold. Lock-in is an argument; utilization is a report someone has to pull. But the workbook is sitting in a shared drive right now, and every recurring export in your company is a pin on a map — it marks precisely where the tool stopped fitting and your people started compensating. When we audit a stack, the invoices tell us what you pay. The exports tell us what you actually do.
A distinction, because candor requires it: not every spreadsheet is a symptom. Ad-hoc analysis is what spreadsheets are for, and a workbook someone builds once to answer a question is a tool doing its job. The tell is the recurring one — load-bearing, maintained on a schedule, with a distribution list. If it stopped being updated and a process would break, that isn't analysis. That's infrastructure you're staffing by hand.
The reason this matters for build-vs-buy: those hand-staffed gaps are usually the cheapest places to start owning software, because the hardest part — knowing exactly what the system should do — is already done. The logic lives in the workbook's columns and the operator's head; it has been tested weekly for years. We don't start with your Salesforce. We start where your people already built the specification without meaning to, one export at a time.