Skip to content
ENع
Schedule call
All guides
Governance8 min read

Designing approval gates

The gate is where the automation meets the organisation, and it is where most projects lose their business case. Put it everywhere and you have added a review step to work that used to be one step. Put it nowhere and the first bad posting ends the project.

Gate on consequence, not on confidence alone

The common design routes low-confidence cases to a person. It is necessary and it is not sufficient, because a confident wrong answer on a large amount is the case that hurts.

  1. Start from what the action does. Reversible and small, let it run. Irreversible or large, gate it regardless of confidence.
  2. Then add confidence as a second axis. Low confidence gates even on small amounts.
  3. Then add novelty. A vendor never seen before, a category never used, an amount far outside the distribution. These are worth a look even at high confidence.
  4. Write the policy as a table the business owns, not as a constant in the code. It will change, and it should not need a deploy.

One useful question for the client: what is the largest amount you would be comfortable with a new joiner posting unsupervised in their first week? That number is usually a good starting threshold, and it is a question they can answer.

What the reviewer needs to see

A gate that shows a decision and two buttons trains people to approve everything within a week. The review has to be genuinely quicker than doing the work, and genuinely informative.

  1. The decision, and the reason, in one sentence.
  2. The evidence, positioned. Not "see attached", but the actual page with the relevant figure highlighted.
  3. What it will do if approved, stated concretely, including the amount and the target.
  4. What was unusual about this case, since that is why they are looking at it.
  5. One click to approve, one to correct. If correcting means opening another system, the correction will not be recorded and you lose the feedback.

Design for the gate to loosen

A gate that never moves is a permanent tax. The plan should be explicit from the start about how it relaxes as evidence accumulates.

  1. Start tight. Gate everything for the first fortnight, and use it as a supervised run that produces evaluation data.
  2. Measure the override rate per category. Categories where people approve 99% of cases are candidates to release.
  3. Release one category at a time, and keep sampling: review one in twenty of the released ones so you keep a signal.
  4. Agree the ratchet in advance, in writing. "Below 2% override over 500 cases and we automate that category" is a decision made calmly, which is not when it will otherwise be made.

The failure modes

Rubber stamping
Approval rate near 100% and review time near zero. The gate is now theatre. Sample and check, and if it is theatre, either remove it or make it informative.
The queue nobody owns
Items waiting days. Worse than no gate, because work is stalled and everyone assumes somebody else is on it. Alert on age, and name an owner.
Escalating everything
Thresholds set so tight that most cases gate. The business case evaporates. This is usually fear rather than policy; go back to the consequence table.
No record of the decision
If an approval is not stored with who and when, you have added a step and gained nothing auditable.

Want us to run this with you?

The Audit is this method pointed at your systems, with a costed build plan at the end of it.

Schedule call
Tell us the number you want to move.Schedule call