How to Keep a Human in the Loop

Where the belt should have a person standing on it

Everything so far has been about work that runs on its own. This lesson is about drawing a line, and about not feeling apologetic when you draw it.

There is a mood in automation circles that any human step is a failure of nerve, a bit of old fashioned caution slowing down the machine. That mood is written by people who do not have to ring the customer afterwards. A human step is not a fallback. For certain kinds of work it is the correct design, and choosing it deliberately is the sign of somebody who has done this before.

Four categories, and they are easier to remember than they look.

The four that never run alone

Anything sent to a customer. The moment something leaves your building with your name on it, you own it. Not the tool, not the vendor, you. An automation that emails a customer directly can produce an apology addressed to the wrong person, a price that is out of date, or a cheerful chase for an invoice that was paid last Thursday. All three are recoverable, and all three cost you goodwill you had spent a year building.

Anything involving money. Payments, refunds, credit notes, discounts, purchase orders. Money is where mistakes are hardest to reverse and most visible. Automate the preparation of the payment run all you like. Somebody presses the button.

Anything hard to undo. Deleting, publishing, cancelling, archiving anything that other things point at. Ask one question: if this were wrong, how long would it take to put right, and would anyone outside the team have seen it in the meantime? If the answer is more than a few minutes, or yes, that step waits for a person.

Anything about a named person. A decision about an individual, whether a customer, an applicant or a colleague, needs a human in it. Assessing an application, flagging someone as a problem, scoring a candidate, deciding who gets an offer. Aside from the fairness of it, in many places there are legal expectations about decisions made about people without human involvement, and finding that out afterwards is a bad way to learn it.

Run every step of every automation through these four. One yes
is enough to require a person.


DOES IT REACH A CUSTOMER?
Would somebody outside this team see the result of this
step, with our name attached?


DOES IT MOVE MONEY?
Payments, refunds, credits, discounts, purchase orders,
or anything that changes what someone owes or is owed.


IS IT HARD TO UNDO?
If this were wrong, how long to put right, and would
anyone outside the team have seen it meanwhile? More
than a few minutes, or yes, counts as hard.


IS IT ABOUT A NAMED PERSON?
A decision, score, flag or assessment concerning one
individual, whether customer, applicant or colleague.

Count the yeses. One yes means an approval step or a draft.
Two or more means this is the last thing you automate, not
the first, and probably not this month.

The draft do not send pattern

This is the most useful pattern in the whole course, and it takes one line to build.

The automation does every piece of the work. It reads the message, works out the answer, composes the reply, formats it properly, attaches the right thing, and then stops. The finished item sits in a drafts folder or a review column. A person opens it, reads it, and presses send.

Look at what you kept. All of the thinking time, all of the typing time, all of the looking up. Look at what you gave back. Four seconds of reading. That is the trade, and it is not a close call.

Prepare the reply. Do not send anything, anywhere, to anyone.
Write the draft in full, ready to go out with no further editing:
correct greeting, the answer to what they actually asked, and a
closing line in our usual tone.
Then, above the draft, add these three lines for the reviewer.
FOR REVIEW: the one thing in this draft most likely to be wrong.
I ASSUMED: anything I inferred rather than read directly.
I COULD NOT FIND: any detail I needed and did not have.
If you could not find something that changes the answer, do not
write a draft at all. Write NEEDS A HUMAN and the reason, in one
line, and stop.
Never state a price, a date or a policy that was not in the
source material in front of you.

Those three review lines are the difference between a draft that gets read and a draft that gets rubber stamped. Left to itself, a reviewer approving forty drafts a day stops reading by the eleventh. A line saying the most likely thing to be wrong is right here gives the reviewer's attention somewhere to go.

Approval steps, and making them survive

An approval step is a pause built into the middle of the automation. It prepares, it waits, somebody approves, it continues. The mechanism is easy. Keeping it healthy is the part people get wrong, and there are three ways it fails.

It fails when nobody owns it, so the queue grows until somebody approves forty items in one go without reading any of them. It fails when the request arrives without enough context, so approving means opening three other systems and the reviewer stops bothering. And it fails when everything goes through it, because a reviewer who has never once found a problem is no longer reviewing, they are clicking.

ONE NAMED OWNER
Not a team, not a channel, a person. Plus one named deputy
for holidays. Write both names down where the queue lives.
A DEADLINE, AND WHAT HAPPENS AT IT
Approve within ...... hours. If nobody does, the item does
NOT proceed by default. It escalates to the deputy. Anything
that auto-approves after a timeout is not an approval step,
it is a delay with a nice name.
ENOUGH CONTEXT TO DECIDE IN THE MESSAGE
The reviewer should not have to open anything else. Include
what will happen, to whom, and the one thing most likely to
be wrong.
TWO BUTTONS, NOT ONE
Approve and reject. If rejecting is not possible, or is
harder than approving, everyone approves everything.
A REASON WHEN REJECTED
One line, kept. Three months of rejection reasons is the
best list of improvements you will ever get for free.

The honest tradeoff

A human step slows things down. Pretending otherwise helps nobody. Your instant reply becomes a reply within the hour, and if your reviewer is on a train it becomes tomorrow morning.

Sometimes that genuinely costs you something, and the answer is not always to keep the human. The answer is to narrow the category so fewer things need approval, rather than removing the review from all of them. Approve only the refunds above a threshold. Approve only the replies where the AI step marked itself LOW confidence. Approve only the first message to a new customer, not every message after it.

That is the mature version of this: not a choice between speed and safety across the board, but a line drawn in the right place, so the cases that need a person get one and the rest flow past.