How the scorecard works
Each answer scores from 0 to 4. The questions fall into three groups, and each group is reported separately so one strong area cannot hide a serious weakness in another.
| Group | Questions | What it tells you |
|---|---|---|
| Value (0–100) | How often it runs, how long it takes, how many people do it, and the cost of mistakes | Whether automating would save enough time or errors to matter |
| Feasibility (0–100) | Clear rules vs judgement, structured vs messy inputs, exception rate, system access, how often the process changes | How reliably software could do it, and how much maintenance it would need |
| Risk (low / medium / high) | Data sensitivity, customer impact if it goes wrong, and how easily mistakes can be undone | Whether a person must review or approve the output |
Value and feasibility are the average of their answers, converted to a 0–100 scale. In the value group, frequency and time per run count double, because they drive the hours saved. Risk takes the highest of its three answers, because one serious risk is enough to need a safeguard.
How the recommendation is chosen
- Strong candidate: value 60+ and feasibility 60+ with low or medium risk.
- Automate with a human checkpoint: value and feasibility are good, but risk is high. Automate the preparation and keep a person approving the final action.
- Standardise first: value is high (60+) but feasibility is below 50. Write the rules down, reduce exceptions and tidy the inputs before building anything.
- Partial automation: mid-range scores. Automate the predictable steps (data entry, reminders, routing) and keep the rest manual.
- Not a priority: value below 40. The time saved is unlikely to justify the build and maintenance.
These thresholds are our practical rules of thumb from scoping automation work. They are not a scientific model, and the reasoning is shown so you can disagree with it.
Why repetitive is not enough
A task you do every day can still be a poor candidate if every case is slightly different, the inputs arrive as messy emails or phone calls, or a wrong output would upset a customer. Those processes tend to produce automations that break, need constant fixing, or quietly make mistakes. Equally, a task done once a month can be worth automating if an error is expensive and the steps never change.
Using the result
- Score your three to five most time-consuming processes and compare them side by side, or use the Automation Priority Matrix.
- For the strongest candidate, estimate hours saved and payback with the Automation ROI Calculator.
- Map the steps and mark which ones a person should check. Our article on automation mistakes covers where projects usually go wrong.
- Start small: automate one well-defined step, measure it for a month, then extend.
What the scorecard cannot judge
It does not know your tools, your data quality or the regulations that apply to you. Personal, financial or health data may need specific legal and security controls, whatever the score says. Treat a high score as a reason to investigate properly, not as approval to build.