Promising a single turnaround time for every request is the fastest way to break your procurement intake SLA, it will inevitably be breached on complex purchases and wasted on routine renewals. To build a framework that actually works, procurement leaders must divide their intake SLA into two distinct commitments: response time and fulfillment time. While procurement cannot always control external approvers, suppliers, or missing details, it retains total control over initial acknowledgment. By establishing a single response target alongside tiered fulfillment expectations, you eliminate tracking disputes and dramatically improve requester satisfaction.
TL;DR
- Set two targets, not one. Response is how long before the requester hears anything. Fulfillment is how long until they have the outcome.
- Procurement controls response almost entirely, which makes it the only one worth committing to as a hard number.
- Use one response target across all request types and separate fulfillment targets for lookup, standard, and complex requests.
- Write the rules for incomplete requests, approver time, and scope drift before launch rather than after the first breach.
- See how Merlin Intake handles procurement requests. Request a demo.
An intake SLA that promises a single turnaround for every request will be missed on the hard ones and wasted on the easy ones. Set targets by request type, and set two of them rather than one. Both parts of that matter and most organizations do neither.
The two are response and fulfillment. Response is how long before the requester hears anything. Fulfillment is how long until they have what they asked for. Most intake SLAs define only the second, which is the one procurement controls least. That is the wrong way round and it is the source of most SLA disputes.
This is written for procurement operations leaders setting service targets for an intake function, either at launch or after the first round of complaints has made the existing target untenable.
Why do single-target SLAs fail?
Because request difficulty varies more than a single target can absorb, and the variance is not marginal.
What follows is predictable. The SLA gets quietly ignored, or it gets met by classifying difficult requests as out of scope, which is worse because it removes them from measurement rather than from the queue. The requests disappear from the report and not from anybody’s desk.
Figure 1: One target cannot serve a renewal and a specialized purchase.
Forrester measured satisfaction with providers rather than internal service targets. The connection drawn here is that dissatisfaction of that scale is rarely about the eventual outcome and frequently about the experience of getting there, which is what a response target governs.
Download A Free Ebook – A 7 Step Guide to Strategic Sourcing
What should you actually measure?
Two targets, and they behave differently enough that reporting them as one average hides both.
- Response time is how long before the requester learns anything: that the request was received, understood, and assigned. Procurement controls this almost entirely, which makes it a fair commitment and the only one worth stating as a hard number. It also requires no cooperation from anyone outside the function.
- Fulfillment time is how long until the requester has the outcome. Procurement controls this partially at best, because it depends on approvers, suppliers, and sometimes the requester answering a question they have not seen yet.
Committing hard to the first and setting expectations on the second is more honest than a single number, and it maps to how requesters actually experience the process. Perceived responsiveness tracks acknowledgment far more closely than it tracks completion, which is why time to first response predicts requester satisfaction better than total cycle time does. A slow request that communicates is tolerated. A fast one that goes silent is not.
Watch Webinar – AI Rising 2026: The State of Procurement AI
APQC measured productivity in aggregate rather than by request type. Its bearing here is that spreads of this size across whole organizations imply much wider spreads between individual request types, which is the argument against a single target.
How do you set targets by request type?
Lookup requests need no sourcing: renewals within contract, catalog items, additions to existing agreements. Standard requests need routine sourcing against known suppliers in a known category. Complex requests need a sourcing event, a new supplier, or an exception to policy. The boundaries will be argued about, and the argument is worth having once rather than per request.
Set one response target across all three, as Figure 2 shows, because acknowledgment does not get harder as the work does. Set fulfillment targets that differ substantially between them, by multiples rather than by margins.
The classification has to be automatic. An SLA that depends on someone manually categorizing each request adds a step before the clock starts, which is a delay dressed as measurement and a reliable way to make attainment look better than the experience actually was.
Figure 2 sets out the structure: one response target across all tiers, with fulfillment targets that differ substantially between them.
Figure 2: One response target across all tiers, fulfillment by tier.
What breaks an SLA that looked reasonable?
Three things, and only one is capacity.
- Incomplete requests. A request returned for missing information has no clean answer to whether the clock pauses. If it does not, the target is unmeetable through no fault of the team. If it does, the requester experiences a delay the SLA does not record, which makes the metric diverge from the experience it exists to describe. The honest treatment is to pause the fulfillment clock and report return-trip rate alongside SLA attainment, so the number cannot be improved by sending things back. Reporting either one alone invites the behavior the other would expose.
- Approver time. Approval waiting is usually the largest single component of fulfillment and it sits outside procurement entirely. Either exclude it and say so, or include it and hold approvers to their own targets. Including it without approver targets makes procurement accountable for other people’s calendars.
- Scope drift. Requests that change after submission. Without a rule about whether a materially changed request restarts the clock, this becomes the loophole everything difficult passes through, and it is invoked most on exactly the requests the SLA existed to govern, which is how a target survives contact with reality without ever being met.
How do you make an SLA stick?
Publish attainment, including the misses, and pair every target with the metric that would expose gaming.
An SLA nobody reports on is a statement of intent. Publishing it monthly, with attainment by tier, return-trip rate, and approval waiting shown separately, makes it a management tool, because it shows where the misses come from rather than only that they happened.
Then review the targets annually against actual distribution. Targets set at launch are guesses, however carefully argued. After two quarters you have real data, and the useful question is not whether you hit the target but whether the target described the work. A target beaten by a wide margin every month is as uninformative as one missed every month, and it is more comfortable, which is why it survives longer.
Merlin Intake captures request attributes at submission, which is what makes automatic tier classification possible and keeps the clock starting when the requester submits rather than when someone triages. Whichever platform you run, an SLA measured from triage rather than submission is measuring the part of the process that was already working.
Figure 3: Where the clock starts, and what it excludes.
Gartner studied buying team dynamics rather than service targets. It is included because an SLA covering only fulfillment makes procurement accountable for time consumed by exactly this kind of internal disagreement, which is the case for separating the two clocks.
Download A Free Ebook – The Quintessential BFSI P2P Transformation Guide
Conclusion
A successful procurement intake SLA is not about promising impossibly fast completion dates; it is about setting honest, predictable expectations that reflect how work actually gets done. By separating response time from fulfillment time, defining expectations across lookup, standard, and complex request tiers, and measuring the clock from submission rather than triage, you build a service model grounded in true transparency. Paired with periodic reviews and secondary metrics like return-trip rates, a well-structured intake SLA transforms procurement operations from a perceived black hole into an accountable, high-performing enterprise function.
Frequently asked questions
Q1. What is an intake SLA?
An intake SLA is a service commitment covering how quickly procurement responds to and fulfills requests. Useful ones define two separate targets: response time, meaning how long before the requester hears anything, and fulfillment time, meaning how long until they have the outcome. The two behave differently and procurement controls them to different degrees.
Q2. What is a reasonable response time for procurement requests?
Response should be fast enough that a requester does not wonder whether the request was received, which in most organizations means hours rather than days, and the same target should apply regardless of complexity. Acknowledgment does not get harder as requests get harder, so varying it by tier is difficult to justify.
Q3. Should intake SLAs differ by request type?
Fulfillment targets should, because a renewal within an existing contract and a first-time purchase of specialized equipment require fundamentally different work. Response targets should not. Three tiers, covering lookup, standard, and complex requests, cover most organizations without becoming unmanageable.
Q4. Should approval time count toward an intake SLA?
Either exclude it explicitly or include it and hold approvers to their own targets. Including approval waiting without approver commitments makes procurement accountable for other people’s calendars, which produces a metric the team cannot influence and will eventually stop taking seriously.
Q5. What happens to the SLA clock when a request is incomplete?
The fulfillment clock should pause while awaiting information from the requester, and return-trip rate should be reported alongside SLA attainment. Reporting them together is what prevents the target being met by sending requests back, which is otherwise the easiest way to improve the number without improving anything.
Q6. How do you stop an intake SLA being gamed?
Pair each target with the metric that would reveal gaming. Report return-trip rate with fulfillment attainment, report the proportion of requests classified as out of scope, and report attainment by tier rather than in aggregate. Gaming usually shows up as a category growing rather than as a target being missed.
Q7. When should intake SLA targets be reviewed?
Annually at minimum, and after the first two quarters of real data, since targets set at launch are estimates. The question worth asking at review is not whether you hit the target but whether the target described the work accurately, because a target consistently beaten by a wide margin is as uninformative as one consistently missed.
Q8. Where should the SLA clock start?
At submission, not at triage, as Figure 3 sets out. A clock starting when someone picks the request up excludes the queue time before that point, which is frequently the largest single component of the wait and the part the requester notices most.
