Where to put the checkpoint
Not everywhere, and not at the end. The useful ones sit where a decision changes what happens next.
Every workflow we build has named checkpoints: points where the run stops and a person decides before it continues. Where they go matters more than how many there are. Too few and the automation makes calls it shouldn’t. Too many and people click through them without reading, which is worse than none.
Where should a human checkpoint go in an automated workflow?
At the point where a decision changes what happens next, and before anything with a consequence: a payment, a message to a customer, a record posted to the ledger. Not at the end, where a review screen becomes a formality, and not at every step, where approvals turn into noise. Ask what happens if this step is wrong, and put the checkpoint just before the answer becomes expensive.
Why not put a review at the end of everything?
Because an end-of-line review sees a finished result with no context. The person can’t tell which of forty matched invoices deserved a second look, so they approve the batch. The checkpoint that works sits at the individual decision, with the evidence the agent used next to it, so the person is judging one thing they can actually judge.
Why not approve every step?
Approval fatigue. When people are asked to confirm things that are never wrong, they stop reading and start clicking, and the one time it matters they click through that too. Checkpoints are scarce on purpose. The agent handles what it can resolve with confidence; the person sees what it couldn’t, and nothing else.
What does a checkpoint look like in practice?
A supplier invoice arrives. The agent reads it, matches it to a purchase order and a job, and drafts the entry. If everything agrees, the approver sees a one-line summary with the match beside it and confirms. If the quantity or price doesn’t agree, the run stops there, shows the difference, and waits. Nothing posts until a named person says so, and the run records who that was.
How do you decide what counts as a decision?
Two tests. Does the right answer depend on who’s asking, or on a relationship the system can’t see? Does being wrong cost more than being slow? If either is true, it’s a decision, and it stays with a person. If neither is true, it’s drafting, and the agent can do it. The line moves as the workflow earns trust, but it only moves when the client says so.
Who decides where the checkpoints go?
The people who do the work, with us. In the audit we map the process with them and ask where they currently hesitate, double-check or pick up the phone. Those moments are the checkpoints. They go in the checkpoint map that ships with the workflow, so anyone on the team can point at one and ask why it’s there.
Our own inbox runs this way. An agent reads, sorts, files and drafts; the draft waits for a person; nothing goes out unsent by a human. It costs a few minutes a day and it’s why the flow is still trusted.
If your automation asks for approval forty times a day, or never, the checkpoints are in the wrong place.
Start with the work that keeps getting in the way.