Most published ROI figures skip straight to a headline percentage because the real math varies too much by organization to market cleanly. The math itself is short enough to run yourself. Read this article to understand more about intake automation.
TL;DR
- Three numbers: monthly email-based request volume, manual processing time per request, and the fully loaded hourly cost of the people processing them.
- Multiply them and you get the figure a vendor’s generic percentage was approximating for you, specific to your own request volume.
- APQC benchmarking data shows organizations spend between roughly 14 and 54 dollars processing a single purchase order, a gap APQC attributes to how procurement work is structured and executed.
- Published figures like “50 percent faster” or “20 to 30 percent lower cost” are real but are averages across very different starting points, use them as a sanity check, not your actual number.
- The estimate breaks down fastest when request volume is undercounted, which happens whenever a channel outside a shared inbox, texts, hallway asks, side-channel Slack messages, gets left out of the count.
- Run your own numbers instead of estimating from a benchmark. Try the ROI calculator →
Three numbers: monthly email-based request volume, manual processing time per request, and the fully loaded hourly cost of the people processing them. Multiply them and you get the figure a vendor’s generic percentage was approximating for you, specific to your own request volume rather than an industry average that may not reflect how your team actually operates.
Most published ROI numbers skip straight to a headline percentage because the real math varies too much by organization to market cleanly. A company processing 200 requests a month has a very different number than one processing 2,000, even if automation cuts processing time by the same share for both, and a percentage alone cannot tell you which situation you are actually in.
What three numbers do you need?
Monthly volume of requests currently arriving by email or informal channel, not the ones already flowing through a structured system, since those are not the requests automation is going to save time on. Average manual processing time per request, from the moment it lands in an inbox to the point it is routed, categorized, and matched to an approver, which is almost always longer than people estimate because it is spread across many small interruptions throughout a day rather than one continuous block anyone would notice and time.
Fully loaded hourly cost of the people doing that processing, salary plus benefits, taxes, and overhead, not just base pay. The most recent U.S. Bureau of Labor Statistics data puts wages and salaries at just under 70 percent of total private-sector employer compensation costs, with the remainder in benefits and payroll taxes, meaning base pay alone will understate the real cost of the people processing a request. Getting this number close enough matters more than getting it exact. A rough estimate run consistently beats a precise-looking number built on an unstated assumption nobody can defend later.
How do you count email-based requests accurately?
Undercounting is the most common error here. Requests that arrive as a reply buried in an unrelated email thread, a Slack message to an individual rather than a shared channel, or a hallway conversation followed by “can you just submit that for me” rarely make it into anyone’s tracked volume, because there is no single place they all land for someone to count them.
A two-week manual audit of every inbox and informal channel that currently receives procurement requests, not just the official one, gives a far more accurate baseline than an assumption based on ticket volume alone. Most teams that run this audit find their real request volume is meaningfully higher than what any existing system reports, sometimes by a wide enough margin to change which savings estimate looks realistic.
What does manual intake actually cost per request?
APQC benchmarking data shows organizations spend anywhere from about 14 to more than 54 dollars processing a single purchase order, a gap the research attributes to how procurement work is structured and executed, not to any single factor in isolation.
That range is wide enough to matter. An organization at the high end of that spread is not paying more because its people work slower, it is paying more because more of the process runs through manual re-entry and email back-and-forth rather than structured capture. For an organization processing even a modest volume of requests a month, that gap compounds into a real annual figure, often enough to fund the automation project outright.
How does the math change once it’s automated?
The three-number formula does not disappear after automation, the middle number shrinks. Processing time per request drops because categorization, routing, and policy checks happen at submission instead of in a follow-up email chain, which is the specific mechanism that produces most of the savings, not a vague “efficiency gain” that is hard to trace back to an actual cause.
Request volume is the number worth watching most carefully after automation, because it rarely stays flat. A channel that is faster and less frustrating to use tends to absorb requests that were previously handled outside the system entirely, verbal asks, favors, workarounds, which is a real behavior change worth tracking separately from the time-per-request savings, since it affects the volume side of the formula rather than the time side.
How does Merlin Intake change the per-request time, specifically?
A request submitted through Merlin Intake inside Microsoft Teams or Slack is parsed, categorized, and routed in the same step it is submitted, rather than sitting in an inbox until someone manually reads, classifies, and forwards it. That collapses the specific line item, manual triage time, that the three-number formula is most sensitive to, since it is usually the largest single component of processing time per request, larger than the approval step itself in most manual workflows.
Aggregate customer benchmarks show a 20 percent improvement in spend under management in Merlin Intake deployments, a downstream effect of the same reduction in per-request handling time: fewer requests slip through unmanaged channels when the managed channel is no slower than the alternative.
McKinsey research found that 40 percent of procurement functions have already implemented or piloted generative AI. That figure is about adoption broadly, not this specific calculation, but it means the estimate a reader runs today is a comparison against what peers are already doing, not a hypothetical.
What do published ROI percentages actually assume?
A figure like “up to 50 percent faster processing” is an average across organizations with very different starting baselines, a company already running semi-structured intake sees a smaller percentage gain than one still running entirely on email, even if both land on a similar absolute number of hours saved. The percentage depends heavily on where an organization started, which is precisely the variable a generic published number cannot account for.
Deloitte’s 2025 Global Chief Procurement Officer Survey found that organizations combining technology and talent investment, what the survey calls Digital Masters, met or exceeded cost-savings targets 96 percent of the time, against 80 percent for organizations that had not. That is a broader finding about digital investment generally, not intake automation specifically, but it is consistent with the number mattering less than actually running the estimate and acting on it.
Treat published percentages as a plausibility check on your own math, not a substitute for it: if your three-number estimate lands wildly outside the published range, that is a signal to double-check your inputs, most often the processing-time estimate, since that is the number people guess at rather than measure, not a reason to prefer the published number over your own.
Where does this estimate break down?
The formula assumes processing time and request volume stay constant, which understates savings once a channel gets easier to use. Structured intake through Merlin Intake as part of the Merlin Agentic AI Platform tends to surface latent demand, requests that people previously avoided submitting because email intake was slow enough to not be worth the effort. That additional volume is real value, but it will not show up in a savings estimate built purely on today’s request count.
Frequently asked questions
Q1. What three numbers do I need to estimate intake automation ROI?
Monthly volume of email-based or informal requests, average manual processing time per request, and the fully loaded hourly cost of the people processing them. Multiplying the three gives a specific, defensible estimate rather than a generic percentage.
Q2. Why do published ROI percentages vary so much between vendors?
They are averages across organizations with very different starting points. A company already running semi-structured intake will show a smaller percentage improvement than one still running entirely on email, even with a similar absolute time saved.
Q3. How much does it cost to process a purchase order manually?
APQC benchmarking data puts the range between roughly 14 and 54 dollars per purchase order, with the spread attributed to how procurement work is structured and executed, not to any single cause.
Q4. What is the most common mistake when estimating email request volume?
Undercounting. Requests buried in unrelated email threads, direct Slack messages, or informal hallway asks rarely get tracked, which understates the real volume a structured intake system would actually handle.
Q5. Does intake automation reduce request volume or processing time?
Primarily processing time per request, by moving categorization and routing to the point of submission. Total volume often rises rather than falls, since easier submission tends to surface requests people previously avoided sending.
Q6. How is fully loaded hourly cost different from salary?
Fully loaded cost includes benefits, payroll taxes, and overhead on top of base salary. Bureau of Labor Statistics data puts wages and salaries at just under 70 percent of total private-sector employer compensation costs, so using base salary alone will understate the real cost per request.
Q7. Should I trust a vendor’s published ROI percentage?
Use it as a plausibility check rather than your actual estimate. If your own three-number calculation lands far outside the published range, that is a reason to re-check your inputs, not to default to the vendor’s number instead.
Q8. Is there a tool to calculate this automatically?
Zycus provides a Procurement Quick Wins ROI and Savings Calculator that walks through this estimate using your own inputs rather than an industry average.
