TL;DR
- Processing a single purchase order costs between about $14 and more than $54, and email intake sits at the expensive end of that range.
- Twelve failure modes group into four cost families: information loss, routing loss, control loss, and visibility loss.
- About a third of the cost is visible in operating expense. The rest leaks as foregone value that appears in no account.
- Structured intake moves the work to the point of entry rather than shifting friction to the requester.
- See how Merlin Intake handles procurement requests. Request a demo.
Email purchase requests cost more than the time they appear to save, and the cost is measurable rather than anecdotal.
That spread of roughly four times is driven largely by how procurement work is structured, not by how hard the team works. Requests that arrive as email enter at the expensive end of it, because every missing field, forked thread, and unrecorded approval adds handling before an order exists. This piece inventories twelve failure modes in email-based intake and names the cost mechanism attached to each one. Figure 1 shows the range.
It is written for procurement operations leaders where email still carries a material share of incoming request volume. It quantifies the current state rather than modeling a future one.
Why does email still handle so many purchase requests?
Because for the requester, it is the cheapest option available. A marketing manager who needs a contractor onboarded knows how to write an email. She may not know which of four systems to open, which form matches her category, or which fields are mandatory. Email asks nothing of her except a sentence.
That calculation is rational, and worth stating plainly. Every failure mode below is a cost the procurement function absorbs so the requester does not have to. The costs are displaced, not created, by the requester. Any fix that ignores this moves friction back onto the person raising the request, which is why portal projects so often see adoption collapse in month four.
The useful question is not why people use email. It is what the organization pays for the convenience. Figure 2 shows where that work sits.
What are the twelve failure modes, and what does each one cost?
The twelve group into four families. Each family attaches to a different cost mechanism, and the mechanisms compound rather than sit side by side.
Information loss covers requests that arrive incomplete. A missing cost center or general ledger code means the request cannot be coded without a return trip. An absent or unusable specification means the category manager rebuilds the requirement from scratch. No budget reference means someone checks manually before anything moves. The cost mechanism here is rework, and rework is the most expensive kind of procurement labor because it is performed by people hired to do sourcing. One incomplete request costs little. The same gap across several thousand a year is a headcount question.
Routing loss covers requests that reach the wrong place. A request addressed to an individual rather than a function stalls entirely when that person is on leave. A thread that forks into parallel conversations produces two versions of the same request moving at different speeds. An approval chain assembled ad hoc means the sequence depends on who the requester happened to copy. The cost mechanism is elapsed time, and elapsed time is what stakeholders remember when they decide whether to use the process next time. Routing loss is also self-reinforcing, because slow requests teach requesters to escalate informally, which generates more off-channel traffic.
Control loss covers requests where the commercial decision is already made. A supplier chosen before procurement sees the request removes competitive leverage before negotiation can begin. Policy thresholds applied after a verbal commitment turn governance into an argument. Skipped contract and risk checks surface later as exposure rather than as a gate. The cost mechanism is foregone value, and it does not appear in any operating expense line. This family is the most expensive and the least visible, because nothing was spent incorrectly. The savings never materialized.
Visibility loss covers requests the organization cannot see. No timestamp on any step means cycle time cannot be measured, so it cannot be improved. No queue means no prioritization, so urgency is decided by whoever follows up hardest. Receipt and match data never captured at intake becomes an invoice exception weeks later. The cost mechanism is compounding, because each of these makes the other eleven harder to detect, as Figure 3 shows.
Which of these costs show up in your numbers, and which do not?
Four of the twelve produce hard cost that a finance team can already see. Rework, elapsed handling, exception resolution, and duplicate processing all land in procurement operating expense, which is why the APQC range above is the right starting benchmark.
The other eight leak. Foregone negotiation leverage, unmanaged supplier risk, and policy exceptions that were never recorded do not sit in any account. They reduce the savings a procurement function reports without ever appearing as a cost it incurred. This asymmetry is why intake problems are consistently underestimated in business cases: the visible third gets counted and the invisible two-thirds gets described as a process irritation.
The Hackett Group’s 2025 Digital World Class Procurement research found that top-performing procurement organizations reduced maverick buying and contract noncompliance, resulting in 60% less savings lost.
Hackett studied top-quartile procurement performance broadly rather than intake channels specifically. The connection to email intake is an inference drawn here, not a Hackett finding: maverick buying and contract noncompliance are precisely the two outcomes that control loss produces, and control loss is a property of how a request enters the process.
What changes structurally when requests arrive already structured?
Structured intake does not make requesters work harder. It moves the structuring work to the point of entry and performs most of it automatically, so fields, routing, and policy checks apply before a human reads anything.
Merlin Intake operates as the front door for procurement requests and works inside Microsoft Teams and Slack, which means the requester writes a sentence in a channel she already uses while the request arrives coded, routed, and policy-checked on the procurement side. The convenience that made email attractive stays with the requester. The twelve costs move off the procurement function.
The measurable effect shows up on both sides of that exchange. Across Zycus deployments where Merlin Intake is in place, customer benchmark data records 40% growth in procurement net promoter score alongside a 20% improvement in spend under management, which is the requester experience and the control outcome moving together rather than trading against each other.
Gartner is describing an adoption trajectory across the category rather than any single vendor roadmap. The practical implication for a procurement team is a narrowing window: the comparison in two years will not be email against a portal, but a structured front door against an assisted one.
Where does this cost estimate break down?
This inventory assumes meaningful request volume. Below a few hundred requests a year, the twelve modes still occur but the aggregate cost rarely justifies a platform decision on its own. Bespoke categories such as capital projects and complex professional services also resist structuring, and forcing them through a standard form produces worse data, not better.
The figures here quantify the current state. Estimating what automation would return is a different calculation, and it needs three numbers from your own environment rather than a benchmark range.
Frequently asked questions
Q1. What is intake management in procurement?
Intake management is the process of capturing, validating, and routing purchase requests before they enter the formal buying process. It functions as a single entry point where a requester submits a need and the request is coded, checked against policy, and directed to the right approvers. Without it, requests arrive through scattered channels in inconsistent formats. Intake is where request data is either captured or permanently lost.
Q2. Why is email bad for purchase requests?
Email captures no structured data, enforces no policy, and creates no audit trail. A request sent by email arrives without a cost center, budget reference, or specification unless the requester happens to include them, and there is no mechanism to require them. It also routes to a person rather than a function, so it stalls when that person is unavailable. The resulting rework and delay are absorbed by the procurement team.
Q3. How much does it cost to process a purchase order?
APQC benchmarking data shows organizations spend from about $14 to more than $54 to process a single purchase order. The variation reflects how the process is structured rather than how efficiently individuals work. Organizations at the high end typically handle more manual data entry, more rework from incomplete requests, and more exception resolution. For an organization issuing tens of thousands of purchase orders annually, the gap between the two ends is substantial.
Q4. What is maverick spend and how does email cause it?
Maverick spend is purchasing that happens outside approved channels, suppliers, or contracts. Email intake enables it because there is no policy gate between the request and the commitment. A requester can select a supplier, agree terms, and only then inform procurement, at which point the commercial decision is already made. The spend is recorded, but the leverage and contract coverage are gone.
Q5. How do you measure procurement intake cycle time?
Intake cycle time measures the elapsed hours between request submission and an approved requisition or purchase order. It requires a timestamp at each step, which email-based intake does not produce. Organizations that cannot measure it usually estimate it from memory, which understates the tail of slow requests. Establishing structured intake is typically the prerequisite for measuring the metric at all.
Q6. Does structured intake slow requesters down?
It should not, and if it does the implementation is wrong. Structured intake designed well asks the requester for less than a form does, because it infers category, coding, and routing from a plain description rather than requiring the requester to know them. The structuring work moves to the system. Adoption failures usually trace to intake designed around the data needs of procurement rather than the experience of the requester.
Q7. What is the difference between intake and a ticketing system?
A ticketing system tracks a request through to closure but does not understand what is being bought. Procurement intake captures commercial attributes such as category, supplier, budget, and contract status, then applies policy against them and routes accordingly. Ticketing tells you a request exists and where it sits. Intake determines what happens to it and enforces the rules that govern the purchase.
Q8. When is email actually fine for a purchase request?
For genuinely one-off, low-value, low-risk purchases where no contract, supplier onboarding, or policy threshold applies, email costs little. The problem is that no one can tell which requests those are until after they are processed. Organizations that permit an email path usually find it absorbs requests it was never scoped for, because it remains the easiest route available.
