TL;DR
- Email-based approvals average 72 hours across enterprise clients. The culprit is inbox delay, misrouting, and zero escalation logic.
- SPFx forms + Power Automate approval flows bring that down to under 4 hours, with a Teams card the approver never has to leave their app to action.
- Built-in escalation logic cut stalled approvals from 23% to under 2%.
- Full audit trail from day one. Zero paper printed per quarter.
It's Monday morning. Someone submits an approval request by email. It goes to a manager who is back-to-back in meetings until noon. By the time they surface, there are 47 unread emails. The approval request is somewhere in the middle, subject line "FWD: Re: Purchase Request — Rajesh." It gets skimmed. Marked as unread to come back to later. It doesn't get come back to.
Thursday afternoon, the requestor follows up. The manager forwards it to someone else, who isn't the right person either. By the time it actually lands with the correct approver and gets actioned, it's been 72 hours. Three working days. For a decision that took 30 seconds to make.
This isn't an edge case. It's the median across our enterprise clients before we build anything for them.
The Real Cost of Waiting
The 72-hour number is real. We track it across clients during the discovery phase before any build starts. We ask: pull 50 approval requests from the last quarter, measure from submission to final decision. The average comes back between 68 and 78 hours every single time.
Here is where that time actually goes:
- Manager inbox delay: average 18 hours before the email is even properly read. This isn't laziness — managers receive between 120 and 200 emails per day at enterprise scale.
- Back-and-forth clarification: 12 hours on average. The request is missing context, or the approver has a question, so they reply asking for more information. That reply goes to a different inbox. Waits there.
- Sent to the wrong person: this happens in 34% of cases. Someone hits "Reply All" to an old email chain and accidentally routes the request to someone with no authority to approve it. Now it starts over.
- Physical signature: some processes still require a wet signature. That means printing, finding the manager physically, waiting for them to be available, scanning it back in.
- Filing: someone has to save the email chain, the attachment, and the reply somewhere logical. Most don't. When someone asks "was that approved?" six months later, nobody can find it.
The typical paper-based approval journey — from submission to decision across three working days
What We Built Instead
The solution is not a better email. The solution is removing email from the process entirely.
We build an SPFx web part that lives on the SharePoint intranet homepage. It's visible the moment an employee opens their intranet. The form captures everything needed for the approval: request type (purchase, travel, exception, access), amount or scope, a short justification, and supporting documents. Those documents attach directly to the SharePoint item — they're not floating in someone's email attachments, unretrievable when the mailbox is full.
When the employee hits Submit, the request lands in a SharePoint list. It gets a unique reference number immediately. Nothing is sent by email. The request doesn't live in anyone's inbox. It lives in SharePoint, where it cannot be deleted, buried, or lost.
Power Automate triggers the instant the SharePoint list item is created. What happens next is entirely determined by rules — no human touches the routing.
SPFx web parts deploy inside SharePoint, so they inherit your M365 authentication, your existing permissions structure, and your Entra ID user profiles. No separate login. No third-party tool. The form just appears on the intranet the employee already uses every day.
The Power Automate Flow — How It Works
Here is the exact logic we build. No black boxes.
Trigger: SPFx form submits to SharePoint list
Power Automate watches the SharePoint list for new items. The trigger fires within 60 seconds of submission. No polling delay, no manual check.
Condition: Amount threshold routing
If the request value is above the configured threshold (typically £5,000 or your equivalent), it routes to Senior Manager. Below threshold, it routes to Line Manager. The routing logic pulls approver details from the Entra ID profile of the requestor's reporting line — no hardcoded names, so it works even when org structures change.
Parallel branch: Finance notification
For requests above a secondary threshold, a parallel branch notifies Finance simultaneously with the approval request. Finance doesn't approve — they're informed and can flag concerns. This runs in parallel, not sequentially, so it adds zero time to the approval cycle.
Teams Adaptive Card sent to approver
The approver receives a Teams card showing: requester name, request type, amount, justification summary, and a link to the full supporting documents in SharePoint. Two buttons: Approve and Reject. One click. No need to open SharePoint, navigate anywhere, or reply to an email.
SharePoint record updated, requestor notified, audit entry created
The approval decision is written back to the SharePoint list item immediately. The requestor receives a Teams notification with the outcome and any comments the approver added. The audit log records: who approved, at what timestamp, from which device. This runs automatically. Zero human involvement.
The Part Everyone Forgets: Escalation
Building the approval flow is the obvious part. The part most teams miss is what happens when the approver goes quiet.
Without escalation logic, the digital process has the same problem as the email process. The approver is on annual leave, or swamped, or they saw the Teams card and thought "I'll look at the document later." Later never comes. The request stalls.
Here is what we build into every approval flow:
- If no response within 8 hours, automatic escalation to the approver's manager. Both receive a Teams card — the original approver gets a reminder, their manager gets the full request.
- If still no response after 16 hours, escalates to the department head. The requestor is also notified that escalation has occurred, so they're not left wondering.
- Every escalation step is logged in the SharePoint audit trail with a timestamp.
Before we introduced this logic, 23% of approval requests stalled for more than 48 hours after initial routing. After go-live, that number dropped to under 2%. That single change — escalation timers — delivered more impact than any other part of the build.
Most teams build the "happy path" — submit, approve, done. They don't build the unhappy path. A 15-minute addition to the Power Automate flow that handles escalation prevents the most common post-go-live complaint: "the digital system is just as slow as the paper one."
What Changed After Go-Live
These numbers are from a real deployment at a 600-person organisation, measured over the first quarter post go-live.
The speed improvement was expected. What surprised the team was the audit coverage. For the first time, they could answer "how many purchase approvals were processed last quarter, and what was the average value?" in about 30 seconds. Before, that question would have taken someone half a day of inbox searching.
Key Takeaways
Email-based approvals don't fail because people are lazy. They fail because there's no structure — no routing logic, no SLA, no escalation. The inbox is not an approval system.
SPFx forms + Power Automate Adaptive Cards give approvers everything they need in a single Teams card. One click. No navigation required. Approval time drops because the friction drops.
Escalation logic is not optional. Build it from the start. It's the difference between a digital process that works and one that stalls in a different application instead of the inbox.