Automating a process: where humans must stay in the loop

Classify the decisions before automating the tasks

A process mixes mechanical tasks and decisions. The first can be handed over without debate; the second require knowing what happens when the machine is wrong.

The last line deserves particular attention: an adverse decision taken without human involvement raises duties of information and appeal that are better handled at design time.

Measure confidence, not only accuracy

A process that is 95 % correct is excellent for classification and unacceptable for invoicing. What matters is not the overall rate, but the system’s ability to know when it is unsure.

Design the chain so that it produces three outputs: processed automatically, to be validated, refused. The second queue is what makes automation acceptable — provided someone actually works it.

Keep a usable trace

Every automated decision must leave enough to reconstruct it: the input data, the version of the processing, the decision and its reason. Without that, the first challenge becomes impossible to examine.

• The version of the model or rules applied, with a date.
• The elements that led to the decision, not only the result.
• The identity of the human validator, when there is one.
• The ability to replay a case on an earlier version.

Assess the gain after reallocation

Time saved only becomes a gain if it is reallocated. If automation frees twenty minutes per person per day without changing the organisation, the benefit is real but diffuse: it shows up as comfort, not as capacity.

Add the new costs too: monitoring, handling rejected cases, maintaining the rules, upgrading versions. Automation costs less than manual work, rarely nothing.

The right question is not “can we automate?” but “who answers when the system is wrong, and with what information?”