A product manager needs a $1,400 annual license for a usability testing tool. She fills in the form, emails her manager, or posts in the finance channel, depending on how purchasing works at her company this quarter. Then nothing happens. Four days later she asks her manager, who says he approved it. Finance says they never saw it. IT says it needs a security review that nobody told her about. On day nine, she pays for it on her own card and files an expense claim.

That sequence plays out thousands of times a day in companies that would describe their purchasing as "under control." It is the view from the requestor's side, and it is the view almost nobody designs for. Procurement articles are written for procurement teams. Finance articles are written for controllers. The employee who started the whole thing, and who will decide whether to use the process next time, is treated as an input.

This article is about that employee. It covers what a purchase request feels like from the inside, why requests go silent, what the silence costs, and what a request should be able to tell its requestor at any moment. It closes with a test you can run on your own process this week.

Key takeaways

  • From the requestor's side, a purchase request has three questions: has anyone approved this, who owns it now, and when will it be bought? A process that cannot answer all three on demand will be bypassed.
  • Requests go quiet for structural reasons, not lazy approvers. The usual ones are that nobody is named as the current owner, the approval route is invisible to the requestor, and purchases need three separate yeses (manager, finance, and IT or legal) that live in three systems.
  • The cost shows up as chasing and as bypass. 56% of workers say the only way to get information they need is to ask someone or schedule a meeting, and fewer than half of procurement leaders believe employees follow their purchasing policies.
  • Adding approvers makes it worse. Perceptyx lists "multi-layer purchase approvals for routine expenses" among the bureaucracy complaints that drag engagement down, and Gartner's view is that leaving end users to navigate complex workflows alone leads to more noncompliance, not less.
  • The fix is a single front door where the requestor already works, with the approval route computed and shown at submission, one status that stays true across every review, and a place to see your own requests without asking anyone.

What a purchase request looks like from the requestor's side

A purchase request is an employee asking the company to spend money on something they need to do their job: software, a laptop, a contractor, a conference ticket, a service renewal. In most companies under 1,000 people, this is almost all indirect spend, and the requestor is not a buyer by trade. They are a marketer, an engineer, or an office manager who needs a thing and would like to get back to work.

That framing matters because the requestor measures the process by one standard: how much of my attention does it take between asking and receiving. Everything procurement cares about (policy, preferred vendors, budget lines, cost centers) is invisible to them unless the process makes it visible. What they see instead is a form, then a gap.

The gap is where the three questions live.

Has anyone approved this yet? The requestor does not know whether their manager saw it, whether finance has a queue, or whether the request is sitting in someone's inbox under forty other messages.

Who owns it now? If the manager approved it, is it with finance? If finance approved it, is somebody actually placing the order? In a process built on email and chat, the answer changes with every forward.

When will it be purchased? The requestor usually has a date that depends on this: a project start, a campaign launch, a new hire's first day. The process rarely knows that date, so it cannot say whether it will be met.

Those are not unreasonable questions. They are the same questions you would ask a parcel courier. Yet most purchasing processes cannot answer them without a human going and looking.

Why requests go quiet

It is tempting to blame slow approvers. In practice, requests stall for structural reasons that would stall any approver.

Nobody is the named owner at this moment. An email thread with four people on it has no owner. Each person assumes another will act, and the request waits for whoever feels responsible first. A ticket with an assignee has an owner. That single difference explains most of the delay.

The route is invisible to the person who cares most. The requestor does not know that a request over a certain amount needs a second signature, that new vendors need a security review, or that marketing software is approved by a different budget holder than engineering software. They find out when the request bounces, usually after a week.

One purchase, three yeses, three systems. Software is the clearest case. Lines of business now own 70% of SaaS spend while IT owns 26.1%, according to Zylo's analysis of more than 40 million licenses. So the manager approves the budget in one place, IT reviews security in another, and finance checks the budget line in a third. Each step is sensible on its own. Together they produce a request that is "approved" three times and still not bought.

Procurement cannot staff its way out. The Hackett Group's 2025 Key Issues Study projects procurement workload rising 9.8% against a 1% rise in staff, a gap the report puts at roughly 9%. Whatever queue exists today gets longer unless requestors can serve themselves.

Notice that none of these is a people problem. They are all visibility problems, and visibility is a design choice.

What the silence costs

The first cost is chasing. Atlassian's State of Teams 2025 survey of 12,000 knowledge workers found that 56% often find the only way to get the information they need is to ask someone or schedule a meeting, and that teams spend about a quarter of the workweek searching for information. A purchase request with no status is a textbook case: the information exists in someone's inbox, and the only retrieval method is interrupting that person.

The second cost is bypass. Amazon Business's 2024 State of Procurement Report, a survey of more than 3,000 procurement decision makers, found that fewer than half (46%) agree that non-procurement employees follow their policies and procedures. The same respondents, 78% of them, said streamlining purchasing for people outside procurement was very important. They know where the leak is.

Bypass is rarely malicious. The academic literature on maverick buying, going back to Karjalainen, Kemppainen, and van Raaij's 2009 study, describes a spectrum that runs from unintentional to deliberate, with most of it sitting at the unintentional and well-meaning end. The product manager in the opening did not set out to break policy. She had a deadline and a process that had gone dark.

The third cost is slower and harder to see. Perceptyx reports that the statement "my company does a good job minimizing or eliminating unnecessary bureaucracy" is the lowest-scoring item in its global benchmark, at 48% favorable, and names "multi-layer purchase approvals for routine expenses" as one of the friction points employees cite. At one large customer in that analysis, engagement ran at 81% among employees who felt bureaucracy was under control and 31% among those who did not. Marketing teams, who request tools and contractors constantly, scored lowest of any function at 30% favorable.

A purchasing process is one of the few places where every employee meets the company's bureaucracy directly. It shapes how they feel about working there.

Why more approvers make it worse

The reflex when spend feels out of control is to add a signature. Payhawk's 2024 survey of finance leaders found that half require all spend to be approved before it happens, while only 28% let employees spend within a policy without pre-approval.

Pre-approval is not wrong. It is the right control for most indirect spend. The problem is that each added signature, in a process with no visible route and no named owner, adds another place for the request to disappear. Gartner's 2025 Hype Cycle for Procurement and Sourcing Solutions puts it plainly: "Without intake management solutions, end users manage their procurement journey independently through complex procurement workflows. This could lead to increased noncompliance, and negatively impact end-user experience."

The benchmark numbers show how long the journey takes even with dedicated software. Procurify's 2026 benchmark, drawn from more than $30 billion in customer transactions, puts the median requisition-to-PO cycle at 55 hours in 2025, up from 51 the year before. That is more than two working days for companies that already run a procurement system. The companies approving purchases over email do not appear in any benchmark, because nobody can measure them.

So the goal is not fewer controls. It is controls the requestor can see. A two-day wait with a visible owner and a predictable route is tolerable. A two-day wait in the dark is where bypass begins.

What a request should be able to tell you

Here is the standard we hold our own intake process to. At any moment, without asking anyone, a requestor should be able to answer the three questions from the opening. That requires five things from the process.

One front door. The request starts in one place, whether the requestor is a Jira user or not. A service portal does this well because it already handles the "I need something" interaction for IT and HR, and people know where it is. Email and chat are fine for discussing a purchase, but a request that only exists in a thread has no status.

The route shown at submission. When the requestor picks a department, a budget, and the items they need, the process should compute who has to approve it and show those names, with their approval limits, on the request itself before it is submitted. This is the single change that kills "I didn't know it needed a second signature." Routing rules based on amount, department, budget, product category, and cross-functional review (legal, security, IT) exist so that the rules run, and the requestor sees the output.

One status that stays true. When a request needs a security review and a budget check and a manager's signature, the requestor should see one state, not three. Every approver attaches to the same record, each vote is visible on it, and the record moves to approved only when the last vote lands. If any reviewer says no, it moves to rejected, and the requestor sees which vote did it. Locking the request from edits once it is submitted keeps that status trustworthy, because approvers are voting on a version that cannot change under them.

A place to see your own requests. Not a report somebody runs for you. A view, in the portal, that lists the requests you have raised and what state each is in. Team members see their own; approvers see what is waiting on them; finance sees everything. Nobody has to ask.

Structured items, not free text. When a requestor can pick a product from a catalog with the supplier, unit price, and tax already attached, the request arrives complete. Free-text items are still allowed, because the catalog will never contain everything, but the default should produce a request finance can act on without a clarifying email.

None of these requires a procurement platform. They require a record with an owner, a computed route, and a view the requestor can open. That is a workflow design problem, and most companies already own a tool that can solve it.

Put the front door where people already work

The Hackett Group's advice to procurement leaders in 2025 is to "orient your procurement operating model to meet the needs of end-user stakeholders" and to provide self-service options. The practical reading of that advice: do not make requestors learn a new system to ask for a laptop.

There is also a tool-sprawl argument. ORO Labs' 2025 survey of enterprise procurement executives found 64% already run 10 or more procurement tools and only 8% say most of them deliver the expected return. Another standalone system, with its own login and its own notification stream, is a cost before it is a benefit.

For companies that run on Atlassian, the front door already exists. Jira Service Management is where employees ask for access, equipment, and help. A purchase request is the same shape of interaction: a form, a queue, approvers, a status, a resolution. Atlassian's own enterprise service management guidance names procurement as a team that can use the portal to "guide employees to the right purchasing process, collect complete request details, coordinate approvals". We have written elsewhere about why procurement fits inside Jira Service Management and the lessons from five years of building it there, so this article will not repeat the argument. The point for the requestor is narrower: the status of a purchase request should be checkable in the same place they check the status of their laptop ticket.

A test you can run this week

Pick the last five purchase requests that went through your company. For each one, try to answer the three questions as they stood 48 hours after submission, using only what the requestor could see at the time.

  1. Could the requestor tell, without asking anyone, whether it had been approved?
  2. Could they name the person it was waiting on?
  3. Did they know the expected order date, or at least the next step?

Then ask the requestors one more question: did you buy anything in the last quarter without going through the process, and why?

If the answers are mostly no and the reasons are mostly "it was faster," you do not have an approver problem. You have a visibility problem, and the next section is about what to do with it.

Deciding in practice

If your company has fewer than about 30 people and one person approves everything, a shared inbox and a card policy will do. The three questions have the same answer every time: ask that one person.

Past that size, the questions multiply faster than the headcount. The requestor needs a record they can open, the approver needs a queue that names them, and finance needs to see what has been committed before the invoice arrives. If your teams already live in Jira or Jira Service Management, that record can be a ticket, with the approval route computed from your own rules and the status visible in the portal. On our own intake flow, the average request-to-PO cycle is 29 hours, against the 55-hour industry median above. The number matters less than the fact that every requestor can see where their request is for all 29 of them.

That is what Raley Procurement for Jira and JSM is built to do. If the five requests you tested came back with more questions than answers, book a short walkthrough and bring one of them with you.

Worth asking
What is a purchase request?
A purchase request is a formal ask by an employee for the company to buy something they need for their work, such as software, equipment, a contractor, or a service. It is the first step of the procure-to-pay process and precedes the purchase order, which is the company's commitment to a supplier. A purchase requisition is the same thing by a more formal name.

How long should a purchase request take to approve?

Procurify's 2026 benchmark puts the median requisition-to-PO cycle at 55 hours for companies that already run procurement software. A realistic target for routine indirect spend is one to two working days, with the requestor able to see the status throughout. Speed matters less than predictability; a visible three-day wait is tolerated, an invisible one is bypassed.

Why do employees bypass the purchasing process?

Most bypass is unintentional or well-meaning rather than deliberate. The usual triggers are a request that has gone silent, an approval route the employee did not know about, and a deadline that cannot wait. Fewer than half of procurement leaders in Amazon Business's 2024 survey believed employees followed their policies, and 78% said streamlining purchasing for non-procurement staff was very important.

What should a purchase request tracking system show the requestor?

At minimum: the current status, the person or role the request is waiting on, the full approval route with each approver's decision, and a list of the requestor's own requests in one place. A process that can only answer these questions by having someone look is not tracking; it is searching.

Can you track purchase requests in Jira Service Management?

Yes. A purchase request maps onto a JSM request type: a form on the portal, a ticket with an assignee and status, approvers attached to the ticket, and a resolution. Approval routing by amount, department, budget, and product, plus purchase order generation and budget tracking, come from Marketplace apps built for that purpose rather than from JSM itself.