Only a few people understand it
Critical operations sit in a file whose formulas, tabs and exceptions live in someone’s head. New starters cannot tell what is current.
Spreadsheet replacement
Replace the shared spreadsheet that is running the business.
OpsForm is a UK custom software business based in Brighton. This page is for teams whose jobs, customers and status still live in a shared workbook—where a broken formula, a conflicting edit or a missing permission is an operational problem, not a formatting one.
The problem
The file became the operating system.
A spreadsheet is a reasonable place to start. It stops being a reasonable place to run the business once more than a few people depend on it.
Edits collide
Two people change the same rows. A formula breaks. There is no real permission model, so a mistake is hard to unwind.
Status is reconstructed
Jobs, customers and next actions are pieced together from the workbook, email and chat. Nobody has one dependable view.
What a replacement does
One system staff can trust day to day.
A spreadsheet replacement is a custom web application around the records and statuses the team already uses. It is not a prettier copy of the grid, and it is not a brochure website.
The usual shape is the same one OpsForm uses for a focused first release: login, roles, the core records, a status workflow, search and a history of important changes.
An illustrative scenario of this shape is on the Work page. It uses sample data. It is not a completed client project.
What the system holds
- Secure login and role-based access
- Structured customer, job or booking records
- Statuses with a named owner and a next action
- Search, filters and basic reporting
- A change history for important actions
- Production deployment of that first release
How OpsForm approaches it
Map the workbook before replacing it.
The first conversation is about what the file is doing for the business: who edits it, which columns are rules, and where people already keep a private workaround.
1. Understand the current file
Users, pain points, business rules, exceptions and the tools people copy into. You do not need a technical specification to start.
2. Write the first release
Core records, assumptions, dependencies and exclusions go in writing before a fixed build is accepted. New ideas stay out until they are chosen deliberately.
3. Build what staff will use
Work is shown in reviewable stages against the real workflow, including awkward cases, permissions and the actions people take every day.
In the first release
The part of the workbook the team cannot lose.
The records people open every day.
The statuses, owners and handoffs that currently live in columns or comments.
Permissions, so people see the rows they should and not the rest.
Search and a basic view of what needs attention.
Room to add modules once real use shows what matters.
Left out on purpose
What a spreadsheet replacement is not.
Every future report, portal or integration in version one.
A marketing site, or a native phone app as the product itself.
A rebuild when a standard product already fits and only needs configuration.
A promise of hours saved, revenue or error rates. Those are not invented here.
A named client project. Published demonstrations stay labelled as sample data.
If the pain is the chasing
Sometimes the workbook is only where the workflow is stuck.
Reminders, approvals and status messages are a workflow automation problem. They can sit on top of the same operational record once that record exists.
Related
Read the workflow automation page if the team is re-typing the same update into email, WhatsApp and the sheet.
Workflow automation for UK operations →Tell us what the spreadsheet is holding.
Who uses it, what breaks, and what a normal day looks like. A full specification is not required.