Every time someone clicks "approve", a computer writes it down. Reading those notes tells you how many choices are made, how long they take, and whether people decide the same way.
Most organisations already have years of approval records in finance, HR and IT systems. They show how many decisions are made, how long each waits, who approves, and how often the answer is no. That's the baseline you need before introducing AI, and it costs nothing to collect.
Approval logs give per-decision volume, cycle time (submitted to decided), approver identity, outcome and sometimes reason codes. Derive rejection rates by approver and category, wait time vs handling time, and consistency across approvers. Use as the pre-change baseline and as labelled training and test data for a decision model.
Why approval logs are useful
An approval is a decision with a record attached. Expense claims, purchase orders, leave requests, access requests, contract sign-offs: each one usually leaves a trail with who asked, who decided, when, and what they decided. Many organisations have years of this sitting in finance, HR and IT systems, and rarely look at it as a whole.
For the decision inventory, approval logs replace guesses with counts. For a later AI project, they give you a baseline and a set of real past decisions to test against.
Five things to pull out
| Measure | How | What it tells you |
|---|---|---|
| Volume | Count per month, by type | How often the decision happens |
| Wait time | Time from submission to decision | How long people are kept waiting |
| Rejection rate | Rejections ÷ total, by type and by approver | How often the answer is no, and whether approvers agree |
| Approver spread | Decisions per approver | Whether a few people carry the load |
| Repeat submissions | Same request resubmitted | How often the first attempt was incomplete |
Wait time deserves a note. It's usually much longer than the time anyone spends deciding. A claim that waits four days and takes three minutes to approve has a waiting problem. An AI tool that speeds up the three minutes won't fix the four days.
Consistency is the surprising one
The measure I find most interesting is rejection rate by approver. If one manager rejects 2% of expense claims and another rejects 15% for similar teams, either their teams behave very differently, or they're applying the policy differently. Either way, it's worth knowing before you build a model, because a model trained on all of their decisions will learn an average of two different policies.
A worked example
These figures are illustrative. A finance team pulls 12 months of purchase order approvals.
| Measure | Result |
|---|---|
| Volume | 4,800 a year, about 400 a month |
| Median wait | 2.5 working days |
| Median time with the approver open | Under 2 minutes |
| Overall rejection rate | 6% |
| Rejection rate, highest approver | 19% |
| Rejection rate, lowest approver | 1% |
| Resubmitted after rejection | 70% of rejections, mostly within a day |
Three conclusions follow. The delay is in the queue, so a reminder nudge may help more than an AI tool. Approvers don't agree, so the policy needs a conversation before any model learns from these decisions. And most rejections are quickly fixed and resubmitted, which suggests a check before submission could prevent many of them.
Using the logs as test data
Once a decision model is considered, the same logs become test cases. You can run the model on last year's requests and compare its suggestions with what approvers decided. Where it disagrees, look at the case: sometimes the model is wrong, sometimes the approver was. Both are useful.
Care with personal data
Approval logs name people, and analysis by approver is effectively analysis of individual performance. I'd agree the purpose with HR and data protection colleagues first, share results by role or anonymised approver where possible, and be clear that the aim is to improve the process.
What I'm still checking
Many logs record only the final outcome and miss any conversation that happened outside the system, such as a quick call that resolved a query. Where that's common, the log understates how much work a decision takes. I haven't found a good way to measure it except by asking.
Sources
This article describes my own method. It uses no external facts or figures; all results in the example are illustrative.