Systemising Pain: When to Fix a Process with Software, Automation or AI

Every team carries a few jobs that hurt every time they come round. The same report rebuilt by hand. The same approval chased across three inboxes. The same spreadsheet reconciled at month-end because no two copies agree. The pain is real, but the response to it is usually wrong in one of two directions: the team buys software for a process nobody has yet defined, or it absorbs the pain indefinitely because fixing it never reaches the top of the list.

Systemising pain is the discipline between those two failures. It means deciding, deliberately, what kind of fix a repeated pain actually needs before spending money or effort on the wrong one.

Is the fix behavioural, procedural or software-shaped?

Most operational pain has one of three roots, and each takes a different cure.

• Behavioural — the pain comes from people and habits. Someone forgets to update the tracker; nobody owns the handover. No tool fixes this; the fix is a clear owner and a changed habit.
• Procedural — the steps are unclear, the ownership is fuzzy, the rules live in someone's head. This is what most people mean by systemising: write the process down, name who does what, make it repeatable.
• Software-shaped — the process is already clear and stable, but doing it by hand is slow, error-prone or simply too frequent to keep paying for. This is where automation or a purpose-built tool earns its cost.

The expensive mistake is treating a procedural problem as a software one. Buy a system to run a process you have not yet defined and you hard-code the confusion, making it costlier to change later. That is why order matters: systemise first, then automate the system that survives contact with reality.

Systemising a recurring pain usually starts by making the work visible: process mapping lays the steps out so you can see where they break, capturing lessons learned turns each failure into a permanent change rather than a repeated one, and a just culture keeps people honest enough to surface the problems in the first place.

"Automating a mess gives you a faster mess." — The Control Standard

When is a process worth automating?

A process is worth fixing with software when four things are true together: the pain is frequent, the process is structured enough to describe in steps, the pain is costly in time, errors or commercial impact, and the data it needs already exists somewhere. Miss any one and the case weakens. A rare task is rarely worth tooling. An unstructured one resists it. A cheap one does not repay the build. And without the underlying data, the tool has nothing to stand on.

The decision framework walks through how to weigh those factors against each other rather than fixating on a single one. McKinsey's research on automation potential found that while around half of the activities people are paid to do could be automated with existing technology, fewer than 5% of jobs can be automated entirely — most pain is a mix, and the skill is isolating the part worth tooling, not the whole job.

The most common trigger for this question is simple: a team has outgrown its spreadsheets but is not yet sure whether the answer is a better-organised sheet, an off-the-shelf product, or something built. That is a real fork, and it has its own guide on building versus buying.

The value isn't only internal efficiency

Systemising pain is usually framed as saving internal time, and often it does. But the higher-value version points outward. A process that hurts your team often hurts your customer too: the client chasing a status update, the supplier waiting on an approval, the buyer filling the same form twice. Fix it and you have a feature, not merely a cost saving.

Deciding where a fix creates the most value — quiet internal efficiency versus a visible improvement customers feel — is its own judgement, covered in customer-facing versus internal software. For a wider lens on the kinds of improvement available beyond "make it faster", the ten types of innovation is a useful map.

Where to start

The cost of leaving pain unsystemised is rarely on the books, which is why it gets tolerated for years; the guide to the drift tax puts a number on it. When you have a specific recurring pain in mind, the free Pain Automation Score weighs whether it is worth automating in about five minutes — frequency, cost, process stability and data availability — and tells you whether to systemise it first or build something now.