Approver delay prediction

The job is to predict that the named approver will miss the SLA, then tell that person and a named, authorized backup while there is still time to act. A meeting-heavy calendar is not permission to auto-approve.

Aged reminders after the clock is already dead are not this job. Neither is skipping the primary because a model prefers the backup's response time.

Do not publish an SLA hit-rate. There is no honest percentage for a predictor that depends on whose calendar you can read, how the queue is coded, and whether the backup is actually on the matrix. The test is whether the dual notification went out with time left, whether the backup was already authorized, and whether anyone auto-approved from a busy Outlook day.

This is not low-risk auto-approval. That path is for rows policy already says can skip a human. This path is for rows that still need a human, when that human is about to miss the clock.

This is not risk-based approval routing. Routing decides who belongs on the path. Delay prediction watches whether the people already on the path will answer in time.

Read three signals from systems you already run. Approval queues in the Coupa, SAP Ariba, and ServiceNow class hold the named approver, the open items, and the SLA clock. Calendars in the Microsoft Outlook class hold busy blocks and out-of-office. Do not stand up a second inbox for the model.

Calendar. Remaining free time inside the SLA window, not a red/green busy map. Back-to-back meetings, all-day offsites, and OOO are useful only when compared with how that person actually clears this queue. A full calendar is not a miss by itself.

Open queue. How many items already sit with this person, at what age, at what amount, at what priority. A VP with a dozen aging PRs will not clear a new plant-critical row in two hours even if the next meeting is tomorrow.

Historical response. Typical time-to-action for this person, this queue type, this priority. Keep catalog buys and capex apart. If they always clear laptops the same day and sit on capital for a week, an average across both is a fiction.

The output is this request, this named approver, remaining SLA, the predicted miss reason in plain language, and the named backup. If the model cannot name a reason, it is not a prediction. It is a nag.

If you cannot name the backup from the live matrix, you do not escalate. You hold the prediction and tell procurement operations. Inventing a delegate is how unauthorized approvals get into the file.

If policy pre-check at intake is working, incomplete and off-policy rows never reach this queue. Delay prediction on those rows just nags people about work that should have bounced.

This is a worked example with made-up names, not a case study with results.

Northvale Metals runs an eight-business-hour SLA on plant-critical PRs. A bearing kit for Line 3 sits in Coupa with Priya, VP Operations, as the named approver. The SLA started at 07:00. It is 09:15. Outlook shows Priya in a two-day leadership offsite with almost no free blocks. On offsite days she almost never touches the Coupa queue until the following morning. She already has twelve open PRs.

The named backup on the delegation-of-authority matrix for this entity and amount is Tomas, plant controller. He is in the plant, not at the offsite.

What the job does: at 09:30, notify Priya and Tomas. The note names the PR, the remaining SLA, the predicted miss (calendar plus open queue plus history), and that Tomas is the authorized backup. Priya can still approve from her phone. Tomas can approve if she does not. The requester is not told the PR is approved. The PO is not cut.

What they almost did is the usual failure set.

They auto-approved because the calendar was red. Finance later finds a VP never saw an $18,400 buy. A full Outlook day is not a control exception.

They escalated to Priya's executive assistant. The assistant is not on the matrix. A DoA check would have to hold that approval anyway, after the SLA was already burning.

They skipped Priya entirely because Tomas usually answers faster. Priya is still the named approver. She gets the first look. The backup is a second look, not a replacement chosen by a model.

They also pinged every other delayed laptop PR in the same hour. Priya muted Coupa. The plant-critical signal died inside a reminder storm.

The backup must be a named person who is already authorized for this amount, entity, and category. Do not invent a delegate. Do not pick the fastest responder in the cost center. Do not route to anyone in the VP's org.

Join the predicted miss to DoA compliance enforcement before the second notification goes out. If the named backup is over their limit, in the wrong entity, or missing from the matrix, stop. Tell procurement operations. Do not send an approval to a person who cannot take it.

Stale HR and a stale matrix are the usual failure. Someone left, someone changed entities, the backup field in Coupa, SAP Ariba, or ServiceNow still shows last year's controller. Delay prediction that trusts a dead backup field creates unauthorized approvals at speed.

A policy pre-check pass is not DoA. Intake can confirm the supplier and the threshold. It cannot deputize a backup.

If you fire on every item past median response time, you have built a reminder bot. Approvers learn to ignore it. Save the dual notification for predicted SLA misses on rows that still need a human and still have time left on the clock.

Separate delay from oddity. A row that is slow and also an unusual amount, an unusual supplier for the category, or a split-across-days pattern belongs with approval anomaly flagging, not with a backup ping. Delay prediction should not hide a controls hold, and a controls hold should not be "fixed" by escalating it to a faster person.

Catalog laptops delayed because a manager is in meetings are not the same as plant-down spares. If low-risk auto-approval already covers the laptop, do not also escalate it. Two systems nagging the same manager is how both signals get muted.

Watch who you copy. A predicted miss is a note to the named approver and the named backup. It is not a public list on a team channel. Public aging boards create workarounds: approvers rubber-stamp to get off the board, or they stop opening Coupa.

The model does not get to prefer the backup. Notify both. The primary stays on the hook until they act, decline, or the SLA forces the backup path you already published. Skipping the primary because the backup's history looks cleaner trains the system to route around the people the matrix named.

Do not wire a predicted miss to auto-approve. Do not let a script stamp the PR because Outlook is busy, because the queue is long, or because the backup has not opened the item either. Busy is not a control exception.

Show the prediction to procurement operations before you turn on dual notify in production. Ops should see the reason, the remaining clock, and the backup's DoA status. A lead who only sees a flood of "you will be late" mail will fight the signal instead of the SLA.

Trial this on one queue that already has a real SLA and a live backup matrix: plant-critical, or another path where a miss actually hurts. Run it in parallel with the reminders Coupa, SAP Ariba, and ServiceNow already send after items age. Microsoft Outlook already shows busy. The job here is the prediction plus the named, authorized backup, with a human still owning the approval.

If the only change is more mail, you have relabeled aging. If a backup without DoA ever received the item, stop the trial and fix the matrix join before you expand.