The spreadsheet is the specification

Every organisation has one: a spreadsheet that started as a stopgap and became the place a critical process actually runs. The approvals tracker. The capacity plan. The onboarding checklist with colour codes only two people understand.

The usual instinct is embarrassment, then replacement. A new tool arrives, the spreadsheet is retired, and six months later a new one quietly appears beside the new tool. That's not a training problem. It's a signal that the spreadsheet knew something the tool didn't.

Read it like a requirements document

A spreadsheet people maintain without being told to is a working model of the process, written by the people who do it. Its structure tells you more than most workshops:

• Columns are the record: what has to be known about each item, in the words the team uses.
• Status columns and colours are states, and the rules for moving between them.
• Comment threads and 'notes' columns are the exceptions: the cases no form anticipated.
• Hidden tabs and lookups are the reference data and the rules nobody wrote down.
• Whoever is allowed to edit which columns is your permission model.

What it can't do

None of this means the spreadsheet should stay. It can't enforce its own rules, so they're applied inconsistently. It can't tell anyone a step is waiting for them. It can't keep a trustworthy history of who changed what. And it can't share a customer with the next team without someone copying and pasting.

The goal is to keep what it knows and lose what it can't do: the same states, fields and rules, enforced by a platform, connected to the rest of the business, with every decision on record.

Replace the spreadsheet's limitations, not its knowledge. The knowledge is the hard part, and your team has already done it.

Where to start

Pick the spreadsheet that would hurt most if it disappeared tomorrow. That's usually the process with the most value in codifying, and the one whose owner will tell you exactly what good looks like.