Designing the four-second approval

The step that stops working

Rung three (the model prepares, a person approves) is where most small businesses should live. It is also the rung that degrades without anybody deciding to degrade it.

Week one: you read every item carefully. Week four: you skim. Week nine: there are forty waiting on a Friday afternoon and you approve them in a block because they have all been fine for two months.

Nothing was switched off. The control stopped being applied, and because the output is fine most of the time, nothing tells you it stopped.

Design for the tired version of yourself

The fix is not discipline. It is making the check cheap enough that the tired version still does it.

Show what matters, not everything. For a drafted reply, the checkable content is the price, the date, the promise and the name. Put those four things at the top of the item, extracted as fields using the earlier lesson, and put the prose below. Now the check is reading four values, not reading a paragraph and remembering what to look for.

Show the source next to the claim. If the reply says delivery is Thursday, show the line from the order that says Thursday. Verification becomes comparison, which is fast, rather than recall, which is not.

Flag what the model was unsure about. Anything the extraction marked NOT STATED, anything that failed validation, anything unusual. Put those at the front of the queue. The items that need you are a small minority, and finding them should not require reading the majority that do not.

Two buttons, not a form. Approve and reject. If rejecting requires typing an explanation, people approve things to avoid the friction: a well-documented effect in every review system ever built, and the most common way an approval step becomes theatre.

Batch by kind, not by time

Approving forty mixed items is slow because your attention resets at each one: different customer, different product, different thing to check.

Approving forty of the same kind is fast, because you hold one mental checklist across all of them. Group the queue by type and do one type at a time. In practice this halves the time for the same care, and it is the single highest-return change most people can make to an approval step.

The number that tells you if it is real

Track the rejection rate: how many items you sent back, out of how many you looked at.

If it is around 5 to 15%, the step is working. You are catching things.

If it is 0% for weeks, one of two things is true. Either the automation is reliable and you should climb a rung and free the time, or you have stopped looking. You can tell which by deliberately putting a broken item into the queue once a month and seeing whether it comes back. Most people find out something uncomfortable the first time they try this.

If it is above 30%, do not fix the queue. Fix the prompt. An approval step doing a third of the work is a drafting tool pretending to be an automation, and you would save more time writing the items yourself.

The trap of approving in bulk

Bulk approve is the feature everybody asks for and the one that converts rung three into rung five. If your tool has it, the compromise that actually holds is: bulk approve is allowed within one type, after you have read the flagged subset, and never on anything involving money.

What this is worth

A well-built queue costs about four seconds an item. Forty items is under three minutes a day, and in exchange nothing reaches a customer that you have not seen.

A badly built queue costs forty seconds an item, takes half an hour, and within two months is being clicked through without reading: at which point you have all the exposure of full automation and all the labour of supervision.

The difference between the two is entirely in the layout of the screen, which is worth knowing before you accept whatever your tool does by default.