Which approvals can run on rules, and which need a person?

Someone in your business is waiting for an approval right now. A supplier invoice sitting in a manager's inbox behind forty other emails. A purchase request that needs a signature from someone in a meeting. A customer discount that the rep knows will be approved but can't quote until it is. The approval itself takes thirty seconds. The waiting takes days, and the cost of the waiting lands on someone else.

Approvals exist for good reasons: to control spend, to catch mistakes, to keep someone accountable. Most of them, though, are approving things that were always going to be approved. The question is which ones.

The one-sentence test

Take any approval you give regularly and try to write the conditions under which you would always say yes. One sentence, with the numbers in it.

• A supplier invoice that matches a purchase order on supplier, quantity and price, from a supplier we've paid before, under a set amount.
• A purchase request from a department head, within their budget for the quarter, from an approved supplier, for a category they're allowed to buy.
• A customer discount of up to a set percentage on an order above a set value, where the customer is in good standing.
• An expense claim with a receipt, within the policy limit for its category, from an employee with no open queries.

If you can write the sentence, and you'd be comfortable with every request that fits it being approved without you seeing it, that approval can run on a rule. If you find yourself adding "unless" clauses that depend on something you'd have to look at, that's the signal: the approval needs a person, or the rule needs to be narrower.

Narrower is fine. A rule that approves only the plainest cases still removes most of the waiting, because the plainest cases are most of the volume. The ones that don't fit go to a person, and now that person's queue holds only the requests that need them.

What pushes an approval to a person

Three things, and they are worth naming separately because each one gets a different threshold.

The amount

The obvious one. Above a certain value, you want eyes on it regardless of how routine it looks. Set the threshold where the cost of a mistake becomes uncomfortable, not where it matches the old sign-off policy. Many businesses find the old threshold was set years ago for a smaller company and now catches far more than it needs to.

The risk

Some requests are small in money and large in consequence. A new supplier, a change to a customer's payment terms, access to a system, anything that touches a contract. These go to a person at any amount, because the thing being approved isn't the number.

How unusual it is

A request that doesn't look like the last hundred from the same source deserves a look even if it's within every limit. The first invoice from a supplier. An expense category an employee has never claimed before. A discount from a rep who never asks for one. The system can spot this because it sees all of them; a manager approving from an inbox can't.

Designing the rule path

When a request fits the sentence, the system approves it, records that it did and why, and moves the work on. Three details make this safe rather than merely fast.

• The rule is written down where people can read it, in the same words you used in the sentence. Not buried in configuration. When the finance lead asks what gets approved without them, the answer is a page.
• The log is complete. Every rule approval shows the request, the rule that matched, the values that satisfied it, and the time. An auditor can replay any of them.
• There's a weekly review of what the rule approved, for the first months at least. Not to re-approve, but to see whether the rule is right. If the review turns up something that shouldn't have passed, the rule gets narrower that day.

Designing the person path

This is where the time goes today, and where most of the improvement is. A request that needs a person should arrive ready to decide: the request itself, the policy limit it's against, the budget position, the history with this supplier or customer, and the specific thing that pushed it past the rule. One screen, one decision, one click to approve, reject or ask a question.

Give every approval a named owner and a deputy, so a meeting or a holiday doesn't stop the business. If the owner hasn't decided by an agreed time, the request goes to the deputy with a note, not to a shared inbox where it belongs to no one. And keep the queue visible: how many are waiting and how long. A manager who can see five requests have been sitting for two days behaves differently from one who can't.

If the request came from an automated process, such as invoice matching, the exception that caused it is already attached. The person isn't being asked to approve an invoice; they're being asked to decide about a difference, with both documents in front of them.

Where the common approvals usually land

Every business draws the line in its own place, but the approvals most businesses give sort in a familiar way once the test is applied.

• Matched supplier invoices under the threshold: rule. This is the biggest volume in most finance teams and the clearest sentence.
• Purchase requests within budget from an approved supplier: rule, with the budget position checked at the moment of approval rather than against last month's figure.
• Expense claims within policy with a receipt attached: rule, with a person seeing any category the claimant hasn't used before.
• Customer discounts within the rep's band: rule, with anything beyond the band going to the sales manager with the deal's margin shown.
• New suppliers, new customers on credit, changes to payment terms, anything touching a contract: a person, every time, at any amount.
• Refunds and credit notes: a person for the first months, then a narrow rule for the small, clear cases once the review shows what those look like.

Where an approval sits on this list isn't permanent. The weekly review moves things: a rule that keeps catching nothing gets wider, a person path that keeps approving the same shape of request gets a sentence written for it.

How to start

1. List the approvals you give in a normal month, roughly how many of each, and who gives them.
2. For each one, try the one-sentence test. Sort them into rule, person, or rule-with-a-narrow-sentence.
3. Measure the waiting. Pick a recent month and look at how long requests sat before being approved. This is the number that will move.
4. Put the rule path live on the one approval with the most volume and the clearest sentence, with the weekly review in place.
5. Rebuild the person path for the same approval: one screen, everything attached, an owner and a deputy.
6. Repeat for the next approval.

What to measure

• Time an approval waits, from request to decision, for the rule path and the person path separately.
• The share approved by rule, and what the weekly review found.
• Hours of manual work removed each week from the approvers and from the people who used to chase them.
• Errors and re-work: approvals that had to be reversed, and whether they came from the rule or the person.

Approvals with exception routing is one of the systems on our Operational Efficiency page. If you'd like to walk through your approvals and try the one-sentence test on them, that's a good use of the first call.