Every system we build has a point where the work goes to a person. Where a person approves each output, that step is not a formality. It is where the team's judgement enters the work, and where mistakes are caught before they reach a client or a ledger. A good approval step takes seconds and gets used. A bad one takes minutes and gets clicked through. This guide is about designing a good one.
What a reviewer should see
A reviewer needs to answer one question quickly: is this right? Everything on the screen should serve that question. Everything else should be a click away, not in the way.
Show the proposed action in plain words. "Book Mrs. Okafor for a cleaning on Thursday at ten." Not a form with twelve fields. The form exists, but it opens on request.
Show the evidence beside it. The sentence from the call where the time was agreed. The line of the invoice where the amount appears. The paragraph of the email with the request. The reviewer should not have to open the source and hunt.
Show the record it will change, and what will happen on approval. "This will add an appointment to the calendar and send a confirmation by text." The reviewer should never be surprised by what approving does.
Show what changed from the usual. If the system drafted a reply, mark the part that is specific to this case. If it filled a form, mark the fields it was unsure of. The routine parts can be read fast; the unusual parts deserve attention.
Then stop. One screen, one proposal, one decision. If the reviewer needs to scroll to find the approve button, the screen has too much on it.
How confidence should be shown
A score on its own is not helpful. A reviewer who sees a figure beside every proposal learns to ignore it, because they cannot tell what the difference between two nearby figures means for their decision.
Show confidence as words with agreed meanings, and show the reason behind the words. Three levels are usually enough.
| Signal | What it means | What the reviewer does |
|---|---|---|
| Matched a known case | The request fits a rule the system has handled many times | Approve in one tap after a glance |
| Close match, check one thing | The request fits a rule, but one detail is unusual | Read the marked detail, then approve or edit |
| Could not decide | The request does not fit a rule, or two sources disagree | Open the full record and handle it as before |
The words are chosen by the team, not by the vendor, and each one changes what the screen looks like. A matched case shows the one-line proposal and the approve button. A close match shows the proposal with the uncertain detail marked. A case the system could not decide opens the full record, because the system is now asking for help rather than offering an answer.
The reason matters more than the level. "Close match: the caller gave a time outside normal hours" tells the reviewer where to look. A level without a reason tells them only that something, somewhere, is off.
When the system should stop and ask
A system should stop and ask whenever a rule does not give it an answer. Asking is a correct outcome. It is not a failure, and it should never be counted as one in the reports.
Write down the cases where it must stop. The list is specific to your work, but it usually includes these.
- The request does not fit any rule it has been given.
- Money, a commitment or a legal obligation is involved above a line you set.
- The client asks for a person.
- A record it needs is missing or does not match the request.
- Two sources disagree: the call says Thursday, the email says Friday.
- Anything it has not seen before, including a new kind of document or a new supplier.
- The person it would have asked is away and no one else is named.
When it stops, it should say why, in the reviewer's words, and it should hand over everything it had gathered so far. A system that stops and hands over a half-finished case with its notes attached saves time even when it cannot finish.
A system that guesses when it should ask will be right most of the time and trusted none of the time.
Keeping the audit trail useful
Every approval leaves a trail. The question is whether anyone can read it later. An audit trail is useful when a person who was not there can open one entry and understand what was proposed, what was decided, by whom, and what happened next.
Each entry should hold the proposal as the reviewer saw it, the evidence that was shown, the confidence signal and its reason, the decision, the name of the person who made it, the time, and what changed afterward if the reviewer edited the proposal before approving.
Keep the trail in plain language and in a place you control. If reading it requires the vendor's help, it is not your trail. Keep it as long as you keep the record it relates to, because a question about the record is a question about the trail.
Then use it. Once a week, read the entries where the reviewer changed something. Three changes of the same kind are a rule that needs adjusting. Once a month, read a sample of the entries that were approved without change, to be sure they deserved to be. The trail is the system's report card, written by the team, and it is the fastest way to find out where the system is drifting from the work.
Designing the step with the team
Decide who reviews, and name a second person for when they are away. A queue that waits on one person is a queue that stops.
Decide how long a proposal can wait. Some work can sit until the afternoon. A caller asking for an appointment cannot. The system should know the difference and raise the ones that are waiting too long.
Watch for two signs that the step is not working. The first is a reviewer who approves everything within a second of it appearing. Either the category is ready to run on its own, or the screen is not showing them anything worth reading. Both are worth a conversation. The second is a reviewer who edits almost everything. The rule needs work, and the category should go back to shadow mode until it does.
Finally, remember that the approval step is where the team is most likely to feel the system as a colleague or as a chore. Ask them, often, what they wish the screen showed. The best improvements to an approval step come from the person who uses it every morning.
For how a category earns its way out of review, read Shadow mode before launch. For where this information lives and who can see it, read Ask for a data map.