Score a Process Before You Automate It

Only if it also scores well here. The most-hated process is often hated precisely because it is messy, exception-heavy and full of judgement calls, which are exactly the properties that make automation difficult. That does not mean never automating it. It means not making it your first project. Build credibility on something that ships cleanly, then use the confidence and the lessons from that to tackle the painful one properly.

Above seventy-five per cent means the process is well suited and should ship without drama. Between fifty and seventy-five is workable, but expect the build to take longer than estimated and to surface exceptions during testing, so scope it with contingency. Below fifty per cent, automation is likely to cost more than it returns unless the process is redesigned first. A low score is frequently a signal that the process itself should be simplified rather than encoded in its current form.

Three to five is the practical range. Fewer than three gives you no basis for comparison, and beyond five the exercise becomes a project in itself and stalls. Score them, write the numbers down, and choose the highest scorer that also has a willing owner. Keep the list, because the second and third candidates become your natural next projects once the first is live, and you will already have done the analysis.

System accessibility is the dimension most likely to turn a promising candidate into an expensive one, so treat a low score there seriously. There are workarounds (scheduled exports, screen-level automation, document parsing) but all of them are more fragile and more expensive to maintain than a proper integration, and they break when a vendor changes a screen layout. If the rest of the process scores well, it is often worth checking whether a higher licence tier of your existing software includes API access, since that is frequently cheaper than engineering around the limitation.

No, it means the design has to include human approval at the right point rather than running unattended. Payment approvals, regulatory submissions and anything with legal consequence can absolutely be automated up to the point of decision, with a person confirming the final step. You still capture most of the time saving, because the preparation work is the slow part, while keeping accountability where it belongs. What you should avoid is unattended execution on anything irreversible and expensive.

Yes, and cross-departmental processes often score well because handoffs between teams are where delay and error concentrate. Be aware that they are harder to sponsor: multiple owners means multiple people who need to agree, and the ownership question in this scorecard becomes the binding constraint rather than the technology. If you pick one, secure a single accountable owner across the whole flow before starting, otherwise the project will stall at the first departmental boundary.