Keep a human in the loop where it matters.

Once a team has one automation working, the next question arrives quickly: does someone need to check every step, or can it just run? Teams tend to answer it in one of two ways, and both cause trouble. Some put a person in front of everything, so the automation saves nobody any time. Others let it all run and find out about the mistakes from a customer.

Most steps don't need you.

A typical workflow has more steps than people realize, and most of them are low stakes. Pulling an attachment out of an email, renaming a file, filling a spreadsheet row from an intake form, drafting a summary that someone will read anyway: if one of these goes wrong, the cost is a few minutes of cleanup. Asking a person to approve each one turns them into a clicker, and clickers stop reading.

When approvals pile up, people learn that almost everything they approve is fine, so they approve faster. By the time a request comes through that actually needs judgment, the habit of reading has worn off. Every unnecessary checkpoint makes the necessary ones a little weaker.

So the starting position is that a step runs on its own unless there is a reason for a person to see it. Name those reasons ahead of time, before a busy week decides them case by case.

Some steps always need a person.

In our work with teams, three kinds of step come up again and again as the ones that should never run unseen. The first is anything that spends money: paying an invoice, issuing a refund, placing an order, approving a discount. The second is anything that speaks to a customer, client, patient, parent or member of the public in the organization's name. The third is anything that can't be undone, like deleting records, sending a file outside the organization or changing a contract.

They share one property. A mistake leaves the building, or it can't be taken back once it does. A wrong row in an internal spreadsheet can be fixed on Tuesday. A wrong refund, a reply to a grieving family that reads like a form letter, or a purged folder of student records cannot.

The question to ask of each step is simple: if this went wrong and nobody noticed for a week, who would find out first?

If the answer is "us," the step can probably run on its own with a periodic review. If the answer is a customer, an auditor or a bank, put a person in front of it.

Put the check before the action.

Many teams add review after the fact: the automation sends the email, and someone skims the sent folder on Friday. That catches patterns but does nothing for the one message that should never have gone out. For the three kinds of step above, the check has to sit between the draft and the action. The automation prepares the payment, the reply or the deletion, and it waits.

This is a design choice, and it is easier to make at the start than to retrofit. When a team maps a workflow, it helps to mark each step with one of three labels: runs alone, runs and gets reviewed later, or waits for a person. A school district's enrollment flow might let the system read the forms and build the student record on its own, then hold the welcome email to families until someone in the office has looked at it.

Make the check easy to do well.

A checkpoint only works if the person at it can judge what they're seeing in under a minute. If approving a vendor payment means opening three systems to compare the invoice with the purchase order, people will start approving on trust. The automation should put everything the reviewer needs on one screen: the draft, the source it came from and anything unusual it noticed, such as a total that doesn't match the order or a customer who has written in four times this month.

It also helps to give the reviewer more options than yes and no. Approve, edit and send back covers most cases. A clinic's front desk reviewing drafted replies to patient questions will fix a sentence far more often than it rejects a whole message, and if editing is awkward, people send the slightly wrong version instead.

Name the person who owns each checkpoint, along with who covers when they're out. A checkpoint assigned to a shared inbox tends to become a queue that nobody clears, and the automation either stalls or someone switches the check off to get things moving again.

Move the line as the record builds.

Where the checkpoints sit should change over time. Start tighter than feels necessary, and keep a simple log of what reviewers changed or rejected. After a month or two, the log tells you which checkpoints are earning their place. If reviewers at a professional firm have approved every drafted appointment confirmation without a single edit, that check can move to a weekly sample. If they keep rewriting the drafted fee estimates, that one stays, and the instructions behind it probably need work.

Whoever owns the checkpoint should make that call deliberately, with the log in hand, before a busy reviewer makes it for them by clicking through.

A checkpoint rule of thumb by risk level.

Run every step in a workflow through this table before it goes live. When a step fits two rows, use the higher one until the review log gives you a reason to move it down.