Human approvals in automated workflows
Good automation does not have to decide every case itself. It has to recognise which case it cannot decide — and present it in such a way that the decision is made quickly.
What you will learn
Where the decision stays with a person
Conversely: an approval step in which ninety-nine out of a hundred cases are approved is not a decision but a tick box. It costs time and creates the impression of control without exercising any.
What a good briefing contains
The quality of an approval step depends on whether the person can decide without first having to look something up. Four pieces of information belong in it:
The second point is the one that is missing most often. “Please review” is not a briefing; “The discount is above 20 percent and therefore needs approval” is.
An example from practice
Why approvals fail
Three patterns that repeat:
All three can be solved at the design stage: define a substitute, keep a visible list of open approvals, and agree a deadline with escalation — after n days the transaction goes to the next person in line or back to the sender.
Approvals must be traceable
For every decision, record who, when, with what result and on what basis. This is not mistrust, but the prerequisite for answering a question later — and, when in doubt, the basis for improving the rules.
An evaluation of which cases were presented how often and how they were decided shows, after a few weeks, which approvals are genuine decisions and which can be replaced by a rule.
Common misconceptions
About the author
Fabian Lücker is managing partner of PHP-Schmiede KG in Rheine and has worked in software development since 2007. He is responsible for development and design, and writes here about decisions that arise in real projects.