5 spreadsheets that should be software and the 5 that shouldn't

These five are worth moving when they start to creak:

1. Job or case trackers. When the whole team updates it, statuses drift and nobody knows which row is current.
2. Capacity or roster boards. Double bookings and "I didn't see the change" are the giveaway.
3. Pricing or quoting sheets. One broken formula or an out-of-date rate, and every quote is wrong until someone notices.
4. Customer inventories. Lists of clients, properties or assets that several people edit, and that other tools should be reading from.
5. Anything that triggers email, invoices or access from a cell. If changing a cell is supposed to send something, bill someone or open a door, it needs the checks and logs proper software gives you.

Say you run a lettings agency where the property list lives in a shared spreadsheet: address, landlord, tenancy dates, gas safety due date, and whoever's managing it. Negotiators sort and filter it all day, and one bad sort scrambles the landlord column against the addresses. Nobody notices until a gas safety reminder goes to the wrong landlord. That list should be records in a system, with each certificate date tied to the property it belongs to.

These are doing exactly what spreadsheets are good at:

1. One-off models. A cash flow forecast for a decision, a "what if we hired" calculation, a price test.
2. Personal notes. Your own working list that nobody else relies on.
3. Short-lived event checklists. The list for a launch, a move or an open day that's finished in a few weeks.
4. One-off exports. Data pulled out of a system to answer a question, then thrown away.
5. Throwaway prototypes. Trying out a process in a sheet before anyone builds anything. This is often the best brief you'll ever write.

The test is simple. If the sheet is used by one person, for a short time or for a single question, leave it. If it's used by several people, every day, as the record of what's true, it's become a system, and it deserves to be treated like one.

When you replace a spreadsheet, don't just rebuild the grid on a web page. Build around the job. A job tracker becomes a list of jobs with clear stages, an owner each, and a history of changes. A quoting sheet becomes a form that pulls current rates and produces the quote. The existing spreadsheet is a great starting point for the brief, because it shows you exactly what the team actually tracks.

Picture a small accountancy practice running its year-end work from a spreadsheet: one row per client, columns for records requested, records received, in review, sent for signature and filed. It works until two people update the same row, or someone sorts one column on its own. A simple internal tool with those same stages, one owner per client and an automatic reminder when records are late does the same job without the risk. The accounting software stays exactly where it is.

Before anything gets built, write a short brief, and check whether the real issue is disconnected tools rather than the sheet itself. Building focused tools like this is what we do with Internal tools, and you'll find more in our guides.