Why procurement belongs in Jira Service Management, the tool your team already uses

Most procurement teams can tell you their spend under management to the percentage point, and for many of the teams I have worked with, it sits somewhere between 30 and 60 percent. The rest leaks out as card spend, expense claims, vendor invoices that show up with no purchase order attached, and the timeless "I just emailed the supplier."

For the last decade, every new generation of procurement software has tried to fix that the same way: build a better dedicated tool and trust that people will use it. Better intake forms. Cleaner approval flows. Friendlier dashboards. More AI. The results, to be charitable, have been mixed. If you have spent six or seven figures on intake-to-procure software and half your company spend still goes around it, the problem is not the feature list. It is the address.

The adoption problem is a location problem

Procurement is the rare enterprise function whose software is used most heavily by people who are not procurement professionals. A CFO opens the finance system every day. An engineer lives in the code repository. A salesperson never leaves the CRM. Those tools earn their adoption because they are indispensable to the daily work of their main users.

A purchase request is different. A marketing manager files one once a quarter. An engineering lead, maybe twice a year. A department head does it occasionally, and reluctantly. These are exactly the people procurement needs to capture, and they have the least reason in the world to learn a new system for it. So they take the path of least resistance: a Slack message, an email to the vendor, a corporate card, a forwarded invoice. The procurement tool sits there, beautifully designed and mostly empty. That is the real problem with intake-to-procure, and it has very little to do with which vendor has the better feature grid.

The "front door" idea has a logical conclusion

The intake-to-procure category has correctly diagnosed the symptom: procurement needs an easy, friendly, and obvious front door. Modern tools have poured real effort into consumer-grade interfaces, conversational AI assistants, Slack and Teams bots, and mobile-first design, all to lower the friction of filing a request. Those are genuine improvements.

But they share one quiet assumption: that the answer is still a better dedicated procurement tool, one the requester has to remember exists, navigate to, and learn. There is another option, and most teams have not seriously weighed it: put procurement inside the tool the requester already opens every day for everything else. Follow the front-door logic all the way down, and you do not end up at a nicer door. You end up not needing a separate building.

What "everything else" actually looks like

In most mid-market and enterprise organizations, there is already one system where employees file requests, get them routed for approval, track status, and see them resolved. It is where they ask IT for a laptop, request HR onboarding, raise a facilities ticket, and send a question to legal. In a growing number of these companies, that system is Atlassian's Jira Service Management.

JSM is no longer just an IT service desk. Over the past several years, Atlassian has broadened it into a general-purpose internal service platform: HR portals, legal intake, facilities, employee experience, and, in some cases, finance operations all run through customized JSM projects. A very large base of organizations has made that investment, and a great many employees now treat filing a JSM request as a basic workplace skill, the way they treat sending an email. For those companies, the question changes shape. It stops being "which procurement tool should we buy?" and becomes "why are we asking our people to learn a different system for procurement when they already know how to file a request?"

The architectural argument

There is a clean architectural reason this works, separate from the user experience. Almost every requirement of an intake-to-procure platform- request forms, multi-level approvals, dynamic routing, queues, SLAs, audit trails, cross-functional collaboration, status visibility, and integrations- is something Atlassian's platform was built to do from the start. JSM did not invent the intake-and-approval pattern. It industrialized it.

When procurement runs inside Atlassian, the plumbing comes with the building. Approval routing, comment threads, attachments, status tracking, audit history, permissions, SSO, mobile access, and cross-team collaboration are all inherited from a platform with a decade of investment behind them. What still has to be built is the procurement layer itself: purchase order generation, vendor master data, multi-currency, budget controls, supplier risk screening, spend analytics, and the link to finance systems. Those are real features and real work, but they sit on top of an orchestration engine that already exists. Here is the same comparison, side by side.

A standalone tool has to build the whole orchestration layer: forms, routing, approvals, queues, audit log, permissions, mobile, identity, and then the procurement layer on top. That is years of engineering to reach the baseline an Atlassian customer already has running today.

Cross-functional approval, where Atlassian quietly wins

The hardest part of modern procurement is not approval inside the procurement team. It is coordinating everyone else who has to weigh in on a purchase: IT security, legal, finance, privacy, compliance, and department heads. This is where procurement software tends to break down, and where procurement projects stall. A SaaS purchase needs a security questionnaire. A new vendor needs a data protection review. A contract needs legal sign-off. A large purchase needs the CFO. Each of those reviews lives with a different team, on a different SLA, in a different tool.

Atlassian has spent ten years making that kind of work easy. Issues link to other issues across projects. Each team keeps its own queue and its own workflow. The requester sees one unified status across every linked review, and approvers see only the requests that concern them rather than a flood from other functions. Audit history records every action, comment, and decision on its own. That is the exact substrate cross-functional procurement approval needs, and Atlassian customers already have it in production.

Where this leaves the procurement software category

None of this is an argument against procurement software as a category. The features that have emerged over the past five years- supplier risk screening, AI-assisted intake triage, contract metadata extraction, spend analytics, and vendor onboarding- are genuinely useful, and most JSM customers do not have them yet. The argument is about where those features should live.

If your company has already standardized on Atlassian as its internal service platform, the better answer is probably not a separate procurement tool that talks to Atlassian over an API. It is a procurement layer that runs inside Atlassian, uses its native building blocks, and inherits its adoption. If you are not on Atlassian, the math is different, and a standalone intake-to-procure tool may well be the right call. But for the growing group of mid-market and enterprise teams running JSM as a serious business platform, the honest question is worth sitting with: if your people already know how to file a request, why are you asking them to learn another system? The best procurement software is the kind that does not feel like procurement software at all. It feels like the way work already gets done.

To answer some questions

Can you actually run procurement in Jira Service Management?
Yes. With an app such as Raley Procurement for Jira & JSM, you can run the full purchasing process, from request to approval to a vendor purchase order, inside Jira or Jira Service Management, using the forms and workflows your team already knows.

Why does procurement software adoption stay so low? 
Because most of the people who file purchase requests are not procurement professionals and only buy something a few times a year. They have little reason to learn a separate system, so they default to email, Slack, or a corporate card. Putting procurement where they already work removes that reason to go around it.

What does JSM provide that a standalone procurement tool has to build?
The orchestration layer: request forms, multi-level approvals, routing, queues, SLAs, audit trails, permissions, SSO, mobile access, and cross-team collaboration. A standalone tool has to build all of that before it can add the purchasing layer on top.

How does procurement in JSM handle cross-functional reviews like security and legal? 
Each function keeps its own queue and workflow, issues link across projects, the requester sees one combined status, and approvers see only their own requests. The audit history captures every action automatically, which is what cross-functional purchase approval needs.

When does a standalone procurement tool still make more sense? 
When your organization is not standardized on Atlassian. If your people do not already live in Jira or JSM, the adoption advantage disappears, and a dedicated intake-to-procure platform may be the better fit.

Run procurement where your team already works ?
Yes, you do not need another platform to learn. Run purchasing through Jira or JSM with a customizable approval matrix, automatic purchase order PDFs for vendors, live budget reporting for finance, and approvals people can action from their inbox. You can get a free trial of Raley Procurement for Jira & JSM on Atlassian Marketplace today.