Why the obvious answer is usually the wrong one
The most common way to allocate work is to look at what the machine is good at and assign it there. It is fast, produces a plausible plan in an afternoon, and is wrong in a specific way: it allocates by capability while the business runs on consequence. A machine that can summarise a file reliably is still the wrong choice to be the last person to read a termination letter, and a person who can be trained in a fortnight is still the wrong choice to be the only check on a figure that decides whether a claim is paid.
The allocation question is not what can be automated. It is what must be owned, by whom, and with what left of human judgement in the loop. The owner of that decision is the head of the function; the compliance lead signs the boundary. The question has a defensible structure: a set of properties any activity can be described in.
Seven properties that decide the allocation
For each activity, answer the following. The answers do not produce a score; they produce a conclusion you can explain to the person whose job is being touched.
- Judgement. Does the activity require a conclusion about what should happen, or only the correct execution of a known step?
- Ambiguity. How often does the input fail to match the expected pattern, and how much does the organisation tolerate that?
- Consequence. What does a mistake cost, and who outside the team feels it?
- Empathy. Does the activity involve a person who is distressed, frightened or in a dispute, and does the act of doing it carry meaning?
- Repetition. How often is it performed, and how predictable is the outcome across those repetitions?
- Data availability. Does the required context exist in a system, in a defined form, with an owner who can be asked when it is wrong?
- Accountability. Can the organisation name the person who will answer for the outcome, and does that person have the standing to refuse it?
Reading the properties together
Judgement, ambiguity and consequence point towards a person. Repetition and data availability point towards a machine. Empathy and accountability are the two that most often get overridden, and they should not be.
| Activity profile | Allocation | The condition to satisfy |
|---|---|---|
| Known step, high repetition, clean data | Machine | The output is checked by a rule or sampled periodically. |
| Known step, high repetition, contested data | Both | The machine drafts; a named person confirms before it is used. |
| Unfamiliar input, low consequence, reversible | Machine | It is treated as a proposal, and a person may discard it freely. |
| Judgement, high consequence, policy written down | Both | The machine prepares the case; the person decides and signs. |
| Distress, dispute, or legally binding outcome | Person | The machine may assist, but the act and the accountability stay human. |
Where the framework resists the obvious answer
Two cases recur, and both need to be handled explicitly.
The first is the empathetic task. There is a persistent argument that a machine cannot hold a difficult conversation, and the argument is usually right for the wrong reason. The reason is not that a machine cannot be warm. It is that the conversation is a commitment, and the organisation has already decided who will carry it. A machine can draft the words, summarise the case history and assemble the options. It should not be the one who apologises, explains a decision or takes the blame for a policy it did not write.
The second is the data availability trap. Plenty of activities are called unsuitable for automation because the data is scattered, and the conclusion is that the activity must stay manual. The data problem is real, and it is a separate problem with a separate owner. Treating them as one question is how organisations keep a process manual for a decade for reasons nobody would defend if pressed. The honest split is: if the data problem is fixable and worth fixing, fix it and then allocate; if it is not, say so and record it.
The decision to leave the work alone
One option in every allocation exercise is to change nothing, and it is the one most often left unstated. Many activities should stay exactly as they are, because their cost is low, their volume small, their consequence bounded, and the time required to design and maintain a workflow would exceed the benefit. Recording that conclusion is as valuable as recording an allocation, because it protects the organisation from a portfolio of thin interventions that consume maintenance capacity for a small return.
A working session that produces a decision
- Take one activity, described as a single sentence, and describe the properties above before discussing any technology.
- Read the seven answers back to the team that performs the activity and correct them where they are wrong.
- Choose the allocation, and write the reason in one sentence that does not mention the technology.
- Name the accountable person and the check that will be applied to the output.
- Record the cases that should not be handled this way, and route them somewhere specific.
- Set the review date, and set the condition that would change the allocation.
The reason to insist on the one-sentence reason is that it has to survive a challenge from a manager whose team is affected, and from a compliance reviewer six months later. The framework for building the workflows themselves, including the approval and exception handling that allocation depends on, is set out in building the work architecture around the allocation, and the application layer that follows the decision is covered by business application engineering. How the allocation, the capability and the governance fit together is handled in building human–machine capital.