What work a system can take over, and what it cannot

Every conversation about automating work eventually turns into an argument about capability: can it do this, is it clever enough for that. It is the wrong argument, and it is why these conversations go nowhere.

The useful question is not how clever the system is. It is what kind of work the task is.

The only question that matters

Take one task. Ask: does it follow a rule, or does it need somebody to decide?

If you cannot tell, there is a sharper version of the same question that almost always settles it:

Two people entering the same invoice produce the same rows. Two people deciding whether to waive a fee for a difficult customer might not, and both might be right. The first is work a system takes over. The second is not, and no amount of capability changes that, because the disagreement is the job.

Things that look like judgement and are not

Plenty of work feels like it needs a person because a person has always done it, and because it involves reading something written by a human.

• Reading a document and pulling out the data. An invoice, a delivery note, a form, a photo of a receipt. It feels like interpretation. It is a rule, as long as you can say what should be pulled out.
• Deciding which pile something goes in. If you can describe the piles, so can a system.
• Checking that two things agree. Invoice against order, price against what was quoted, quantity against what arrived. Comparison is the most rule-shaped work there is, and it is the work people are worst at doing consistently at four in the afternoon.
• Answering a question that has one answer. Where is my order, what is the returns window, do you deliver here.

Things that look like a rule and are not

The reverse trap is more expensive, because it is the one that breaks projects.

• "Approve it if it looks right." If nobody can write down what "right" means, it is judgement wearing a rule's clothes.
• Anything where the exception is the point. If the task exists to catch the case that does not fit the pattern, a system that follows the pattern is precisely the wrong tool.
• Work whose rule lives in one person's head. Common, and not really a technology problem: the first job is getting it written down, and that is worth doing whether or not you automate anything afterwards.
• Anything where being wrong is expensive. Even if it is a rule, this belongs on the list of things the system prepares and a person signs.

The middle: faster, not gone

Most real lists have a third pile, and pretending it does not exist is how people end up disappointed.

These are tasks where the gathering is a rule and the deciding is not. Preparing a quote where the numbers are looked up and the final price is a call. Assembling a case for a complaint. Drafting a reply that a person then reads and sends.

The system does the fetching, the checking and the drafting, and hands a person something almost finished. The task does not disappear. It goes from twenty minutes to three, and it happens the same way every time.

Money and promises stay with a person

One category stays on the human side regardless of how neatly it follows a rule: anything that spends money, promises something, or creates an obligation.

Approving a payment. Granting an exception. Promising a delivery date. Quoting a price on something non-standard. Settling a complaint. A system can prepare all of these to the point where a person only has to read and confirm, and that is the right shape. It should not be the one deciding, because when it is wrong it is wrong with complete confidence and the cost lands on you.

Sorting your own list

Take whatever list you already have of what your team does by hand. Put three columns next to it: rule, judgement, and both. Go through it once, quickly, without arguing with yourself.

The rule column is what a system can take over. The both column is what gets faster. The judgement column is what stays, and it is worth being pleased that it stays, because that is the part of the work that needed a person in the first place.

You will have done in half an hour what most proposals never do at all: separated the work that can be removed from the work that cannot, using your own tasks rather than somebody's demo.