Almost every organisation runs at least one critical process on a spreadsheet: a request tracker, an approvals log, a project register, a schedule. Spreadsheets are flexible, familiar and quick to set up — which is exactly why they end up holding processes they were never designed for.
The question is not whether spreadsheets are bad. It is knowing when one has quietly become a system that your organisation depends on, without the controls a system should have.
Signs a spreadsheet has outgrown itself
- Several people edit it, and there are rules about who may change which columns.
- There are multiple versions in inboxes and nobody is sure which is current.
- Work depends on someone remembering to check it and chase the next step.
- It holds personal or sensitive information that everyone with the file can see.
- One person understands how it works, and the process stalls when they are away.
- Reports are rebuilt manually every week or month by copying data between files.
- Mistakes have already happened because of a broken formula or overwritten row.
If three or more of these apply, the spreadsheet is carrying operational risk. The cost of that risk is usually hidden in time spent checking, reconciling and fixing.
What a system gives you that a spreadsheet does not
- Structured data entry with validation, so information is complete and consistent.
- Workflow: requests move between people with clear status and notifications.
- Role-based access, so people see and edit only what they should.
- An audit trail of who changed what, and when.
- Live dashboards instead of manually rebuilt reports.
- Integration with other systems, removing duplicate capture.
When not to build custom software
Custom development is not always the answer. If the process is common — expense claims, leave requests, ticketing — a configured off-the-shelf tool may serve you well. Custom applications make sense when the process is specific to how your organisation works, when existing tools force awkward workarounds, or when you need to connect several systems in a particular way.
How to approach the change
- 1Map the current process, including the workarounds and exceptions people rarely mention.
- 2Identify who does what, which decisions are made, and what information each step needs.
- 3Simplify before you digitise — remove steps that exist only because of the spreadsheet.
- 4Prototype the new workflow and test it with the people who use the spreadsheet today.
- 5Plan data migration: clean the existing records rather than moving errors into a new system.
- 6Launch with support, retire the old file clearly, and review after a few weeks of real use.
Start small and prove value
Pick one process with clear pain and a contained scope. A successful first project builds confidence, shows what good looks like, and makes the next decision easier. Trying to replace every spreadsheet at once is the most reliable way to stall.