Teams rarely arrive with a specification. They arrive with a sentence: there is too much manual work and it is slowing everything down. That sentence is true and useless in equal measure, because it does not say which work, or how much.
This is the audit we run before proposing anything. You can run it yourself in a week, and you should, because it surfaces the dependencies and exceptions that never make it into a software brief, which is what makes the later scoping accurate.
1. List the work, not the tools
Write the process as things people do, in the order they do them, using verbs. Receive the order. Check stock. Confirm with the client. Create the invoice. Chase the payment. Do not write the names of the software, because the tools hide the handoffs, and the handoffs are where the cost is.
Include the exceptions someone handles quietly, the ones people describe with a shrug. Do not skip them: they are often where the workload hides, because they are handled informally and rarely appear in the documented process.
2. Tally for one week, do not estimate
Ask each person to keep a tally rather than a memory: a mark every time they do the step, and a rough duration. One normal week is usually enough for a first sample, and a shared sheet is fine, since you are about to replace it anyway. If the work is seasonal or piles up at month-end, measure across that cycle instead.
Expect the numbers to surprise you in both directions. Nobody reconstructs either figure well from memory, and frequency is the one the arithmetic multiplies, so a week of rough tallies beats a confident estimate made afterwards.
3. Score each step on five things
- Hours per month, from the tally rather than the estimate.
- What an error costs, and whether anyone would notice it.
- How many people can do it. A step only one person can perform is a risk as well as a cost.
- How stable the inputs are. Stable inputs are cheap to automate; inputs that change shape are not.
- Whether it blocks somebody else. A ten-minute step that holds up three people is not a ten-minute step.
4. Fix the cheap ones before building anything
Start with the steps consuming the most hours, then read them against the other four scores before deciding what deserves attention. Some of what you find will not need software at all: a setting nobody enabled, a template, a form field that should have been required, a report that could be scheduled instead of assembled.
Clear those first. They are cheap, and there is no point paying to automate a step that should not exist in the first place. What remains after that is the honest candidate list.
5. Decide what pays back
For each remaining candidate, turn the hours into money first: multiply the hours it removes each month by a realistic loaded hourly cost, then divide the build cost by that monthly saving. That gives you a payback period in months. Add maintenance honestly, because every integration needs occasional attention when the other side changes.
A step that frees twenty hours a month and pays for itself in half a year is an easy decision. Two hours a month is usually hard to justify on labour cost alone, though it can still be worth fixing if those two hours block other people, carry a serious error risk, or sit in the middle of something much larger. Hours are one input to the decision, not the whole of it.
What usually wins
The same three patterns come up again and again in this work, and none of them is exciting: re-entering the same record into a second system, chasing colleagues or clients for a status that a system could show, and rebuilding the same report by hand every week.
If you already know which of those three is yours, you are most of the way through the audit. Doing it properly just turns the suspicion into a number you can defend to whoever signs off the budget.