The approval did not fail. It just sat. And nobody counted the days until the deadline forced the question.
Here is the week you recognise. A renewal has to be signed by the last business day of the quarter to hold the price. The paper is clean. Legal cleared it. The commercial terms are agreed. And yet on the Tuesday before the deadline, someone finally asks the question out loud in a channel: where is this with finance? Nobody knows. It turns out the request has been sitting in one inbox for eleven days, unread, behind a holiday and a reorg. Now the escalation is a fire drill. Three people ping the approver, someone loops in the approver's manager, and the deal gets signed at 6pm on the last day with a favour owed and a slightly worse position than you started with.
The failure was not the approval. Approvals stall all the time and that is normal. The failure was that nobody was counting the wait. The step went quiet, and quiet read as fine right up until quiet became late. This post is about why that happens on almost every sign-off chain, and how measuring the wait turns the crisis into a reminder you send on day four instead of day eleven.
A sign-off chain is a queue of people, each holding one step. The problem is that a queue has no clock unless someone builds one. An email sent to an approver looks identical on day one and day nine. It sits in a sent folder, marked done from the sender's side, pending from the receiver's side, and measured by no one. The person who sent it assumes silence means progress. The person holding it assumes it is not urgent because nothing said otherwise.
This is not carelessness. It is the natural state of any handoff where the deadline lives in one person's head and the pending step lives in another's inbox. The deadline holder cannot see the wait. The step holder cannot see the deadline. The two facts that would produce an early nudge are held by two different people who are not talking, because from each side there is nothing yet to talk about. We wrote more about how these chains are structured, and why each approver needs their own brief, in the deal sign-off chain.
Every team that gets caught by a late escalation resolves to fix it. The usual fix is a status meeting or a shared tracker. Both decay within a month. A weekly status meeting catches a stall that has already been sitting for six days, which is often too late. A shared tracker only works if every person updates their own row, and the person who is sitting on a step is precisely the person least likely to log that they are sitting on it.
The deeper reason it persists is that the promise on the calendar was often made before the approval chain was even mapped. The signature date gets committed in a plan, then procurement inherits the job of hitting it through a chain nobody measured. That mismatch is a cousin of the problem we covered in the plan was finished before procurement saw it. When the timeline is fixed and the chain is unmeasured, the only signal you ever get is the deadline itself, and by then the nudge is an emergency.
The fix is not more meetings. It is a clock on every pending step. The AI analyst tracks each step in a sign-off chain against how long that kind of step usually takes, and flags the moment a step runs past its expected duration. The flag arrives while there is still slack before the deadline, which is the whole point. A reminder on day four is a routine nudge. The same reminder on day eleven is an escalation. Same message, different world, and the only difference is when the wait got measured.
This runs quietly in the background rather than waiting for you to ask. The analyst desk carries six specialist agents and ten inbox agents, with thirty background jobs running against your records, and one of those jobs is watching pending steps age. You do not have to remember to check. The check happens, and you hear about a step only when it starts to drift. If you want the mechanics of how these agents work on your side of the table, we laid it out in the vendor's AI already knows your price.
An early flag does more than save the date. It changes who owns the problem. When a stall surfaces on day four, the person holding the step still has room to act without anyone escalating over their head. Nobody has to loop in a manager, nobody has to call in a favour, and the working relationship stays intact. The escalation, when it is needed at all, becomes a calm and predictable step rather than a public alarm.
It also protects your leverage. Many of the deadlines in a sign-off chain exist because of the counterparty's own calendar, and signing late often means signing at a worse number. Understanding those windows is its own discipline, which we covered in timing is leverage. A stall that gets caught early keeps you inside the window where the discount actually moves. A stall caught late hands the timing advantage back to the other side of the table.
The analyst can tell you a step has been sitting for nine days when it usually takes three. It cannot tell you why. The approver may be blocked on a genuine question, may be waiting on a fact from you, or may simply be underwater this week. The flag points you at the stall. The conversation that clears it is still yours to have, and sometimes that conversation reveals the real blocker is a term nobody agreed to yet, which is a different job entirely.
It also cannot invent time you never had. If a signature deadline is three days away and a step genuinely needs a week, an early flag turns an ambush into a known problem, but it does not conjure the missing days. And the expected duration is a benchmark, not a law. A step running slightly long may be perfectly fine. The tool gives you visibility and a head start. Judgement about whether a given stall matters, and how hard to push a given person, stays a human call, which is exactly the balance we argue for in humans are still more accurate than AI. What you get back is the one thing the old process never gave you: the chance to act while acting is still cheap.
Fredrik has spent more than twenty years in enterprise software, with time at Oracle, IBM, SAP, and Salesforce before moving to the buy side. He structured and priced the kind of large agreements most buyers only see once or twice in a career, which taught him where the leverage sits and how far a vendor will actually move. He started VendorBenchmark to hand that knowledge to every sourcing team.