Skip to content
Codivine
Automation

Which Business Processes Should You Automate First?

A scoring method for ranking automation candidates by frequency, stability and error cost — plus the processes to leave alone.

Oskar Szymczak3 min read

The first automation project sets the tone for every one after it. Pick well and you get budget for the next five. Pick badly and automation becomes "that thing we tried".

Here’s the scoring method we use.

Score each candidate on four axes

Frequency (how often). Daily is excellent. Weekly is good. Monthly is rarely worth it unless the task is very long.

Duration (how long each time). Include the switching cost — the two minutes of finding the right tab and remembering where you were.

Stability (how often the rules change). A process that changed twice last year is a good candidate. One that changes monthly is not; you’ll maintain the automation more than you use it.

Error cost (what happens when it goes wrong). A typo in an internal note costs nothing. A typo in a customer’s delivery address costs a shipment, a phone call and some goodwill.

Multiply frequency by duration for the time saving. Weight it by stability. Add error cost. Rank.

The winner is usually not the process that annoys people most. It’s the small, boring, frequent one that nobody complains about because they’ve stopped noticing it.

The usual winners

Getting enquiries into your CRM. Website form to CRM, deduplicated, assigned, acknowledged. High frequency, high error cost, completely stable. This is the most common first project we do, and it’s the one that most reliably pays for itself.

Order to fulfilment to accounting. For anyone selling physical goods, the data path from store to warehouse to books is repetitive, high volume, and expensive to get wrong.

Recurring reports. Somebody exports three files every Monday morning and pastes them into a template. It’s usually two to four hours a week, and the automated version is more accurate.

Document generation. Quotes, contracts and invoices assembled from existing data. Fast to build, immediately visible, and it removes a category of embarrassing mistakes.

Onboarding checklists. New client or new employee triggers a set of tasks, accounts and emails. Stable, forgettable, and expensive when a step gets skipped.

Follow-up sequences. Nothing has happened on this lead/quote/invoice in N days — do something. Cheap to build, disproportionately valuable, because the alternative is human memory.

The usual losers

Anything requiring real judgement. If a person weighs several factors and decides, automation replaces the mechanics at best. Be honest about which part you’re actually removing.

Rare, complex processes. Annual reporting. Contract renegotiation. The effort-to-benefit ratio is terrible and the rules will have changed by next year.

Processes nobody can describe. If three people describe it three ways, you don’t have a process yet. Map it first — that alone is often the improvement.

Processes about to be replaced. Automating around a system you’re planning to change is money you’ll throw away.

Anything where the real problem is a decision nobody has made. Two teams doing the same work differently doesn’t need automation. It needs someone to decide.

Run a two-week diary

Before scoping anything, ask three or four people to note every task they do more than twice in a fortnight, with rough timings. It takes them a few minutes a day and it beats any workshop.

Two things happen. You get a real inventory instead of impressions. And people identify their own candidates, which matters more than it should — automation imposed on a team gets resisted, automation people asked for gets adopted.

Set a baseline before you build

Time per case, cases per week, error rate, turnaround time. Whatever you’ll use to judge success. Without it you’ll be arguing about whether it helped, and the people who were sceptical will win by default.

Do one properly

The temptation after a good first project is to automate five things at once. Resist it. Each automation is something to maintain, monitor and understand. A small number of reliable automations beats a sprawl of half-working ones — and reliability is what earns you the next project internally.

If you want help ranking your candidates, that’s the first thing we do in an automation engagement. Often the discovery is worth more than the build.

Oskar Szymczak

Founder & Software Engineer

Leads the technical side of every project — architecture, development and the decisions that are expensive to change later.

More about the team

Want help with this?

This is the kind of work we do. These pages explain how.

Got a version of this problem?

Describe it in your own words. We'll tell you what we'd do about it — and whether it's worth doing at all.

No specification needed. A description of the problem is enough to start.