How do you keep a person in charge of an automated process?

You want the hours back. You don't want a system that sends a wrong quote to a customer, or pays a supplier twice, with nobody noticing until the complaint arrives. Those two wishes feel like a trade-off, and in badly designed systems they are. In well designed ones the person is still in charge, and the system does the fetching, sorting and drafting around them.

This is how to design for that, in a way your team will trust and your finance lead can sign off.

Three places a person belongs

Not every step needs a person. The three that do are the same in almost every process.

Before: setting the rules

Someone who knows the work writes down the criteria the system will apply. Which enquiries count as qualified, which invoice differences are small enough to approve, which support questions can be answered from the approved documents. The system never invents a rule; it applies the ones your people gave it, and they can change them.

During: the decisions that need judgment

Anything that spends money, anything that goes to a customer in the early weeks, and anything the rules don't cover goes to a person. The system's job at that moment is to make the decision fast: the item, the context, what it suggests and why, and a way to say yes or no.

After: reviewing the log

Every run is recorded: what arrived, what the system did, what it sent on, and what it passed to a person. Someone reads that log, weekly at first, and that reading is how the system earns more room.

What the person needs to see

The difference between a review step that works and one the team resents is what lands in front of them. A notification that says a supplier invoice needs approval, with a link to the accounting system, is a chore. The same invoice, shown next to the purchase order, with the line that doesn't match highlighted and the difference stated, is a decision that takes twenty seconds.

So each decision arrives with five things: the item itself, the records it relates to, what the system suggests, why it suggests that in one plain sentence, and the two or three actions the person can take. If they regularly need to open another system to decide, the design is incomplete.

Start narrow and widen on evidence

In the first weeks, everything passes a person. That sounds like it defeats the point, and it would if it stayed that way. What it does is build a record. After a few hundred runs the log shows that invoices matching the order to the penny were approved by the finance lead every single time. So that class of invoice stops waiting for her. The ones with a difference still do.

Widening happens one class of case at a time, on the evidence in the log, with the process owner's agreement. It never happens because the system seems to be doing fine.

A morning with the queue

Here's what that looks like a month in. The finance lead opens her approvals queue at nine. Yesterday the system read thirty-one supplier invoices from the shared inbox. Twenty-six matched a purchase order to the penny and are already queued for payment, because that class was widened two weeks ago after the log showed she had approved every one of them for a fortnight. Five are waiting for her. Three are from a supplier whose delivery charge never appears on the order; the system shows the order, the invoice and the charge highlighted, and she approves each in a few seconds, then adds a note that this supplier's delivery charge can be approved automatically under a set amount. One is for an amount higher than the order with no explanation, and she sends it back to the buyer from the same screen. One is from a supplier the system has never seen, and the rule is that new suppliers always come to her, so she checks the details and approves.

Before the system, that morning was an hour of opening emails, finding orders and typing figures. Now it's ten minutes, and every one of those minutes was a decision only she could make. Next month the delivery charge rule will mean the three from that supplier stop waiting for her too.

The controls that make it safe to widen

• Limits. A ceiling on what the system can approve, send or change without a person: an amount, a count per day, a list of customers it may reply to.
• A stop switch. One action, known to the team, that pauses the system and routes everything to people. Test it before launch, and again whenever the system changes.
• A log of every run. Not a summary. The actual inputs, outputs and decisions, kept where the process owner can read them.
• A named owner. One person who can change the rules, widen or narrow what the system does, and is the one to call when something looks wrong.

These are the things a security review or an auditor asks about, and they're easier to build in at the start than to add later. How we handle them is set out on our reliability page.

The sign it's working

The person's queue gets shorter and more interesting. In week one it holds everything. By the end of the quarter it holds the invoice from a new supplier, the enquiry from a company nobody has heard of, the support request that mentions a lawyer. Those are the decisions a person should be making, and they're the ones the person is now making with everything in front of them.

If instead the queue stays full of routine items the person approves without reading, the widening has stalled, and that's a conversation about evidence, not about trust.

What to do this week

1. For the process you're automating, write down the decisions a person must make and the rules they apply today.
2. For each decision, list what the person would need in front of them to decide in under a minute.
3. Set the starting limits: what the system may do on its own from day one, which is probably nothing.
4. Name the owner, and agree how often the log is reviewed and who widens the limits.
5. Decide what the stop switch is and who can use it.

This is also the part of a design we'd want to agree with you before anything is built, because it is where the trust comes from. If you'd like to talk through the decisions in your process, that's a good first call. If you're still choosing the process, What should you automate first? is the place to start, and which approvals can run on rules shows the same design applied to one decision.