Skip to content

The spreadsheet layer: finding the six figures hiding in your ops

SigmaJunction · Automation practice7 min read

Every company we audit believes its systems cover the business. Every audit finds the same thing underneath: a hidden layer of spreadsheets, exports, re-keying and inbox rituals holding those systems together. We call it the spreadsheet layer, and in a mid-size company it routinely costs six figures a year — unbudgeted, unmeasured, and growing.

Why the layer forms

No system covers 100% of a real operation. The gap between what your tools do and what your business needs gets filled by the most flexible software ever made: a spreadsheet and a determined person. Each individual patch is rational — five minutes here, one export there. The layer is what those patches become in aggregate, five years later.

The layer has a second, nastier property: it concentrates in your most differentiated processes. The standard stuff is covered by the standard tools; it's precisely where your business is unusual — your pricing logic, your exception handling, your service promise — that the spreadsheets breed. Your competitive edge runs on your most fragile infrastructure.

Don't expect your software vendors to surface it, either. Each vendor's product genuinely covers what it covers; the layer lives in the seams between their products, which is precisely the territory no vendor owns, measures or gets a ticket about. The ERP support portal will never show you the four hours a week spent re-keying into the ERP. The layer is structurally invisible to everyone whose job is one system — it's only visible to whoever is responsible for the whole operation. Which is why finding it is an audit, not a feature request.

Every workaround is a vote: your operation telling you where it has outgrown its tools.

Field marks: how to recognise it

You don't need an auditor to spot the layer; you need to know its field marks. A file whose name contains a person — "Milena's sheet" — is not a file, it's an unbudgeted system with a single point of failure and no backup strategy. A filename ending in _final_v3_REALLY is version control by prayer. A month-end that requires two late nights of copy-paste is a batch job wearing a human costume. An inbox used as a work queue — orders arriving as emails, status tracked by who replied — is a database with no indexes and a retention policy called "archive."

The most reliable field mark is social: ask each team lead, "if this person is on holiday for three weeks, what breaks?" The answers map the layer almost perfectly. What breaks is never the ERP — it's the twelve invisible bridges between the ERP and reality, each maintained by exactly one person, none of them written down.

How to price it

The audit method is simple enough to run internally. For two weeks, have each team log every task that involves moving data between systems by hand: exports, re-keying, copy-paste, manual reconciliation, status-chasing emails. For each task: minutes per occurrence, occurrences per week, who does it, and their loaded hourly cost.

Then add the error term — usually bigger than the labour term. What does a mis-keyed order cost? A missed reconciliation? Estimate conservatively and it will still surprise you. Multiply out to a year, and you have the number the layer costs. In our audits of companies between 50 and 500 people, it has never come in under six figures.

Don't stop at labour and errors, because the layer has two more expensive properties. Latency: work that moves by manual hand-off moves at the speed of the busiest person in the chain, and a quote that takes two days loses to one that takes an hour — you pay the layer in lost revenue, not just salary. And key-person risk: everything priced above also has a probability of simply stopping when its one maintainer resigns. That risk never appears in the log, and it is the most expensive line of all when it lands.

Running the log without killing the team

The two-week log fails in a predictable way: announced as a productivity study, it reads as surveillance, and the team logs defensively or not at all. Frame it as what it is — a case for giving people better tools — and say explicitly what it is not: nobody's output is being measured, and no role is being priced for elimination. The people who maintain the spreadsheet layer are not the problem; they are the load-bearing walls, and the log exists to get them budget.

Keep the capture lightweight or it lies. A shared sheet with four columns beats a tracking tool nobody opens; a fifteen-minute end-of-day recall beats per-task timers that get abandoned by Wednesday. If two weeks is politically impossible, sample: one normal day, one month-end day, one day when something went wrong. The estimate will be rougher, but the ranking — which is what you actually need — comes out the same.

One more source deserves a manual pass: the finance team's month-end. It is the densest concentration of the layer in almost every company — reconciliations, exports, chasing, re-keying — and its cost hides inside a week everyone has agreed to treat as normal. It isn't normal. It's a backlog item with a recurring monthly price.

The three standard fixes

Nearly every item on the ranked list resolves into one of three shapes. An integration — two systems you already own, finally speaking directly, with retries and monitoring instead of a Tuesday export. A small internal tool — a focused screen that replaces the heroic spreadsheet, with permissions, an audit trail and more than one person who can operate it. Or a workflow automation — the multi-step ritual (collect, check, chase, reconcile) encoded as a process that runs on schedule and escalates only its exceptions to a human.

Whichever shape it takes, hold the fix to a production standard, because a fragile automation is just a faster way to make mistakes. "Done" means: it retries on failure, it alerts someone when retries run out, it logs what it did, and the error path lands in front of a human with enough context to act. Automation that fails silently is worse than the spreadsheet it replaced — the spreadsheet at least had someone watching it.

What to do about it — and what not to

Resist the instinct to automate everything at once. Rank the logged tasks by annual cost, and automate from the top — each automation is a small, boring project with its own payback period. The first one usually pays back in months and funds the political will for the rest.

And keep a rule of thumb from the other side of this trade: if the payback on an automation is longer than twelve months, don't build it. The spreadsheet layer is a target-rich environment; there is no reason to start anywhere but the top of the list.

The layer never fully disappears — operations keep evolving, and new gaps keep forming. But once it's measured, it stops being invisible. And what's measured gets budgeted, prioritised and shrunk — which is why the two-week log, not any piece of software, is the real beginning of the fix.

Want your spreadsheet layer priced properly?

The automation audit takes a week and returns a ranked list with payback periods.