- Replace the spreadsheet when it has become a system: several people edit it, one person knows the formulas, and mistakes reach customers.
- Put a number on it first: hours a week, times the people, times a loaded hourly rate, times fifty weeks. That is the yearly cost of the manual work.
- Build when a year of that cost is clearly above the price of a pilot, usually $12,000 to $25,000. Otherwise keep the spreadsheet.
- The first build is one workflow, intake to result, in four to six weeks, with the number on a dashboard from day one.
Every operating business runs something important on a spreadsheet: quotes, scheduling, intake, follow-ups, a report someone rebuilds every Monday. Most of the time that is fine. A spreadsheet is fast, free and understood by everyone. This note is about the moment it stops being fine, and how to decide what to do about it without guessing.
The four signs
A spreadsheet has become a system, and started to cost you, when most of these are true.
- Several people edit it, and there are copies. Someone keeps a “clean” version. Two versions disagree about a customer. Nobody is sure which one is right.
- One person knows the formulas. When they are on holiday, the process waits. When they leave, it breaks.
- The same data is typed twice. A request arrives by email, gets copied into the sheet, then copied again into the invoicing tool. Each copy is a chance for an error.
- Mistakes reach customers. A wrong price on a quote, a missed booking, a follow-up that never went out. The sheet did nothing wrong; it has no way to know.
If one or two apply, tidy the spreadsheet. If three or four apply, put a number on it.
Put a number on it
The number is the yearly cost of the manual work, and it takes five minutes.
Hours a week spent on the process, times the number of people doing it, times a loaded hourly rate, times fifty weeks.
As an illustration, three people spending six hours a week each on quoting, at a loaded rate of $45 an hour, cost about $40,000 a year in time alone. That figure leaves out the errors, the delays and the customers lost while a quote sat in someone’s inbox.
Two other numbers are worth writing next to it: the turnaround time from request to answer, and the error rate you can count. These three, hours a week, turnaround time, cost per task, are what a build is measured against afterwards.
The rule of thumb
Build when a year of the manual cost is clearly above the price of a pilot. A pilot, one workflow shipped to production, usually lands between $12,000 and $25,000. At $40,000 a year of time, the arithmetic is straightforward, and the software keeps paying every year after that.
Below that line, keep the spreadsheet and improve it: one shared file, validation on the columns that matter, a locked template. Or configure an off-the-shelf tool. A form builder plus a decent CRM covers more than people expect.
There is a third case: the process still changes every month. Software freezes a process. Freeze it when it has settled, and not before.
What the software usually is
Operations software is rarely exotic. Most builds we do for this kind of problem share the same skeleton.
- Intake. A form or an inbox rule that captures the request once, with the right fields, in the right shape.
- Validation. Rules that reject the impossible before a human sees it: a missing postal code, a price outside the allowed range, a date in the past.
- A queue and statuses. Every request has an owner and a state, visible to everyone, so nothing waits in a personal inbox.
- Notifications. The customer gets a confirmation, the team gets a nudge, without anyone typing an email.
- A report. The number, on a page, updated by the system rather than rebuilt by hand.
Integrations come after that skeleton: accounting, calendar, payments, whatever the process touches. Each one is a rule set you do not control, and each one is quoted on its own.
What to keep in the spreadsheet
Not everything should move. One-off analyses, exploration, a model you change every week: these belong in a spreadsheet, where a change costs nothing. The rule is simple. Repeated, shared, customer-facing work goes into software. Everything else stays where it is.
The first build
A first build should be one workflow, intake to result, shipped in four to six weeks with the number on a dashboard from the first release. Not the whole operation. The pilot proves the arithmetic on one process, and the second workflow is quoted from what the first one taught you.
Before that, a Discovery of one to two weeks writes the specification: the workflow, its states, the data, the integrations and the risks, with a fixed quote and a date. If the arithmetic does not work, the Discovery says so, and you keep the document.
If a spreadsheet in your business fails three of the four signs above, write to us with the process and the hours. The first reply, within one business day, will tell you whether it is a build or a tidy-up.
