Requisition Aging & Approval Escalation Nudger

The problem this kills

A requisition sits in someone's approval queue for six days and nobody knows until the requester pings you asking where their order is. So you become the human escalation engine: you open the ERP, scroll the pending list, work out who is sitting on what, send a "gentle reminder," wait, send another one, and when the approver is on vacation you go hunting for their backup or their manager. Meanwhile the requester is stewing, the vendor's lead time is ticking, and you have no clean answer for "how long has this actually been stuck and whose desk is it on?"

The painful part is that all of this is rules-based. Each step has an owner. Each step has a reasonable amount of time it should take. There is a backup and a manager for when it overflows. You already know the rules — you just don't have anything watching the clock for you, counting only working hours, nudging before things go red, and surfacing the genuinely stuck ones so you can escalate on purpose instead of by panic.

This is exactly the kind of patient, repetitive, watch-the-clock work a small internal tool does better than a person — and you do not need to be a developer to build it.

What you'll build

A simple internal web tool for whoever shepherds requisitions through approval. You import two things: your open requisitions (each with its current step, current approver, and the timestamps for when it was submitted and when it entered the current step) and your SLA / escalation-path sheet (how many working hours each step is allowed, and who the backup and manager are). The tool computes, for every requisition, how long it has waited at its current step in business hours only — skipping nights, weekends, and the holidays you list — and paints a clear green / amber / red aging board.

Polite reminder emails go to the current approvers automatically on a schedule, with a daily cap so nobody gets spammed. When a step blows its SLA, that item drops into an escalation queue. Reminders are automatic; reassignment is not. The procurement owner reviews the breached items, and only when they click confirm does the tool reassign the approval to the named backup or manager, notify everyone, and log it. Each day, the team gets an aging digest so the whole queue is visible at a glance.

What's inside the Implementation Plan

The plan is a single file you paste into an AI coding agent. It opens by interviewing you about your business — your real approval steps and who owns each one, where your requisitions live (which ERP or sheet), the exact field and naming conventions in your data, your working hours and holiday calendar, your per-step SLAs and escalation path, your typical and peak volumes, and your messiest edge cases — and then tailors the data model, the aging math, the reminder rules, and every later step to your answers. This is a tool shaped around how your approvals actually flow, not a generic template.

From there it walks the agent through the database schema, the two imports with their duplicate guards, the business-hours aging engine, the scheduled reminder emails with a per-approver daily cap, the green/amber/red board, the owner's confirm-before-reassign escalation queue, and the daily team digest. Every step ends with a ready-to-copy prompt. Because the whole thing runs on a CSV (or Google Sheet) in and a clean CSV out, you can build it and use it this afternoon even if you have no live connection to your ERP.

The governance it includes (this is the point)

Reassigning an approval changes who has authority over a purchase, so it is built like it matters: login so only your team can use it, row-level security so you only ever see your own organization's requisitions, and a complete audit trail of every reminder sent, every escalation confirmed, and every reassignment — who did what, and when. Reminders go out automatically, but escalation is a hard human-in-the-loop gate: the tool surfaces the breached items and proposes the backup or manager, and nothing is reassigned until the procurement owner clicks confirm. A duplicate guard keyed on requisition id plus step number means the same approver can't be nudged twice in a day and the same item can't be escalated twice for the same step.

Who it's for

Procurement coordinators, buyers, and operations managers who are tired of personally chasing approvers and explaining delays to requesters. If you can describe your approval steps and how long each one should take, you can build this.

You've got this — open the plan, paste the first prompt, and let it interview you about how your approvals flow.