Why do approvals stall in email?
Email can carry an approval request, but an email chain is a poor place to track the decision. Quotes and purchase orders stall when the request is hidden, incomplete or owned by nobody.
Approvals stall in email because the request is easy to miss and often arrives without everything needed for a decision. Sending a reminder repeats the same problem in the same crowded place. A better approval workflow gives each request one visible status, sends it to the right person with only the information they need, and records the answer against the original quote or purchase order. Routine requests can follow rules set by the business, including automatic approval below an agreed level. Higher-value or unusual decisions stay with a person. The aim is not to remove human judgement. It is to stop that judgement being buried under inbox noise, missing figures and repeated chasing.
Many approval delays start before anyone can make the decision. The request is hard to spot or missing key information. Another email repeats the problem.
Why does the request disappear?
Email treats an approval like any other message. It arrives beside supplier updates, meeting invitations, copied conversations and newsletters. The subject line may not say what is waiting, how urgent it is or what stops until somebody answers.
Over more than a decade as an in-house internal auditor, long before this business existed, I saw inboxes with thousands of unread messages. The people behind them were not ignoring their work. They were carrying too much of it through one channel. Senior people attract more email precisely because more decisions depend on them.
That creates a quiet mismatch. The person raising a purchase order believes the request is now with the approver. The approver does not know it exists. Nobody can see that difference because the only status is an email marked as sent.
A chase puts another message into the same queue. The process still depends on two people checking the right thread at the right time.
What information is missing?
Seeing the request is only the first hurdle. The approver also needs enough information to say yes or no without starting an investigation.
For a purchase order, that could mean the supplier, total value, budget, reason for buying, last price paid and expected delivery date. For a quote, it might be the measurements, quantities, current material prices, labour needed, delivery window, margin and any exception to the usual terms.
Different approvers need different parts. The person responsible for delivery wants to know whether the right people and materials will be available. Finance wants the price, margin and budget. The person who owns the customer relationship may care about scope, timing and any unusual promise.
Sending the whole document to all of them looks thorough. It actually moves the work. Each approver now has to search for the few facts they own, work out whether the figures are current and decide whether somebody else has checked the rest.
An approval request should arrive as a small decision pack. It contains the question, the evidence that person needs and the consequence of answering yes or no. If a missing figure would cause a reply asking for more detail, the pack was not ready to be sent.
Will inbox rules fix the problem?
They can fix part of it, and that is worth doing before buying or building anything.
Give approval emails a standard subject line. Route them into a dedicated folder. Add a visible label. Use the same short request format every time. Those changes reduce the chance that a live decision sits beside ordinary correspondence unnoticed.
Take the approval people chase most. List every question the approver usually asks before saying yes. Make those answers mandatory in the original request.
Inbox rules cannot create ownership or show the wider team what is holding things up. They cannot tell whether a quote needs a margin check or a purchase order is missing a budget code. Better folders organise messages. They do not manage decisions.
What should replace the email chain?
One shared record should replace it. The notification can still appear in Microsoft Teams, Slack or email, but the message is only the door. Behind it sits the request, evidence, named approver and current status. The requester can see what is missing. Finance can see committed spending, and a manager can see every quote waiting for sign-off.
The routing can also match the decision. Some requests need the first authorised person to respond. Others need everyone to agree, or must move through a fixed sequence. Microsoft’s approval tools support all three patterns, which shows that the logic itself is not exotic. The difficult part is deciding which rule fits the business.
The tool should follow your approval rules, not become them. Buying a large approvals package before writing those rules only moves the confusion into a new box. A business that owns its rules can change tools later without redesigning who may approve what.
| In an email chain | In an approval workflow |
|---|---|
| Sent | Waiting with a named person |
| Full attachment for everyone | Relevant facts for each approver |
| Chased from memory | Reminder triggered by elapsed time |
| Rejection buried in a reply | Reason returned to the requester |
| History split across inboxes | Decision recorded with the request |
This is distinct from automating the quote itself. Our article on why quotes take so long covers gathering prices, labour and specifications. Approval starts when those facts reach the people who can authorise the result. For purchase orders, approval happens before the commitment. Matching the later supplier invoice is another control, covered in invoice validation and routing.
Approval records contain sensitive commercial information and may include names or contact details. Supplier prices, margins, customer terms and spending authority should not be visible to everyone. Give each person only what they need and restrict access to the full record. Where personal data is involved, the Information Commissioner’s Office says it should be limited to what is necessary. Fixed rules handle most of the routing without any AI at all. Where a model is used to read a long document or write a summary, send it only the fields it needs, use a business service with a written no-training promise, keep processing in the United Kingdom or Europe, and for anything that should never leave the business, run the model on your own server.
When can approval be automatic?
Automatic approval is reasonable when the business can state the rule clearly and accept the risk behind it.
A purchase from an approved supplier, raised by an authorised person, below an agreed value and within the available budget may not need another person to look at it. The system can check each condition and produce the approved purchase order. If one condition fails, it goes to a person instead.
The threshold is not a software setting chosen during the build. It is a business control. The person responsible for the money decides which combinations of value, supplier, category and requester are safe. Whoever designs the workflow should explain what could go wrong at each level before that decision is made.
The same idea can apply to straightforward quotes using standard prices and terms. But a low value does not always mean low risk. A small quote with an unusual promise, a new customer condition or uncertain measurements can still need careful review.
Rules earn trust when exceptions are visible. An approval system that quietly guesses when a condition is unclear is not saving time. It is hiding risk.
Where should the final decision sit?
With a person whenever the judgement cannot be reduced to a rule the business is willing to own.
For a complex quote, somebody still confirms the measurements, quantities and specifics of the job. The system can collect current prices, identify the people needed, check availability and assemble the information. It cannot know whether a promise feels sensible for this customer unless that judgement has been made explicit.
For purchase orders, the final human check applies above the agreed threshold and whenever the supplier, budget or request falls outside the normal pattern. The approver should not repeat every calculation. They should see the exception, the supporting facts and the decision waiting for them.
The approver was never the problem. They did not see the request, or could not answer it. Fix those two things and the control stops being a click in an inbox. It becomes the business knowing what was decided, by whom and on which facts.
- Approvals usually stall because the request is unseen or incomplete, not because the approver is deliberately slow.
- Inbox rules are a useful first fix, but they cannot provide ownership, live status or a complete decision record.
- Each approver should receive only the facts needed for their part of the decision.
- Automatic approval can handle cases inside rules the business has chosen. Exceptions and higher-risk decisions go to a person.
- Every request should leave one visible record of the evidence, decision and reason.
Drafted by Otto, the Perkins SmartOps AI assistant. Reviewed, edited and published by David Perkins, the human.
