Why this question matters more than it looks

A surprising number of Raley conversations start with the same question: should we run our procurement intake out of a Jira Software project or a Jira Service Management (JSM) service project? While this sounds technical it is actually one of the most consequential design choices a team will make. It affects who can submit requests, how approvals work, what the audit trail looks like, and how much it costs to license. Most teams pick a side on instinct, get six months in, and discover they chose wrong.

This is a guide to choosing deliberately. We will cover what each option actually gives you, the real cost difference, the operational implications, and which choice fits which kind of organization. By the end you will know where your procurement intake should live, and why.

Procurement intake is a strange workload. The submitters are everyone in the company: the marketing manager filing a quarterly software request, the engineering lead asking for a new contractor, the office admin restocking supplies. The approvers are a small group of specialists: procurement, finance, legal, security, IT. The work itself involves structured data (cost, vendor, line items), conversational back and forth, and links to other systems (the supplier, the ERP, the contract repo).

Atlassian gives you two ways to model this:

• Jira (Software) project. Internal-facing, every participant is a Jira licensed user, designed for teams collaborating on work.
• Jira Service Management project. Has a customer portal, supports licensed agents and unlicensed customers or requesters, designed for service workflows.

Both can hold purchase requests. Both support workflows and approvals. Both have automation. But the architecture, the licensing model, and the user experience are genuinely different, and one of them is far better suited to procurement intake for most organizations.

What Jira Software gives you for procurement

A Jira Software project for procurement looks like an internal team's project. The procurement team is the "team," every purchase request becomes a Jira issue (typically of type "Request" or "Purchase Order"), and approvers and contributors interact directly in the issue.

Strengths. The biggest strength is familiarity for procurement. The procurement team's daily work, tracking purchases, managing line items, reporting on status, happens in the same interface they would use for any other Jira project: boards, lists, backlogs, sprints if relevant. The data model is rich. Issue types, custom fields, workflows, screens, components, and versions are all available. Issue links are powerful too. A purchase request can link to a security review issue in the IT project, a contract review issue in the Legal project, a vendor onboarding issue in the Finance project. Each function lives in its own project with its own queues and permissions, and the procurement issue is the spine that ties them together. Reporting is mature: custom JQL queries, dashboards, gadgets, exports. Procurement's own metrics, cycle time, approval bottlenecks, vendor spend distribution, are first-class queryable data.

Weaknesses. Every requester needs a Jira license. In Atlassian Cloud, a Jira Standard user costs roughly $8 per month, Premium closer to $16. For a 500-person company where most employees file maybe one purchase request per quarter, this is a serious overspend, tens of thousands of dollars a year in Jira licenses for users who interact with procurement four times a year. The submission experience is wrong for occasional users too. A first-time requester opens Jira and sees a board full of issue cards they don't understand, navigation built for power users, and an issue-create form with fields designed for someone who lives in Jira. It's not bad software, it's just not designed for the once-a-quarter user, and adoption suffers as a result: spend leaks back into email and credit cards. There's no native customer portal, so the request experience is the same as a developer creating a bug ticket. You can build forms and templates, but you're working against the grain of what Jira Software is for. Permissions get complicated fast, too. Procurement requests often contain sensitive data: supplier negotiations, salary information, confidential contracts. Locking down a Jira Software project so only the right people see the right things requires careful permission-scheme work, and mistakes leak data.

What JSM gives you for procurement

A JSM service project for procurement separates the two audiences cleanly. Agents, meaning procurement, finance, and IT, work in Jira, while customers, meaning employees filing requests, interact with a clean portal. The same purchase request exists in both places, but each audience sees the version designed for them.

Strengths. The portal is the right UX for occasional submitters. A marketing manager who files a purchase request once a quarter sees a friendly form with help text, required fields, and clear status updates after submission, the same experience they already have for IT tickets or HR requests. No Jira power-user navigation, no issue cards, no boards, just a form and a status page. License costs are dramatically lower, because JSM charges per agent (the procurement team and approvers), not per customer. Everyone else in the company submits requests for free. For a 500-person company with a 5-person procurement team, that license-cost difference runs roughly an order of magnitude versus licensing everyone under Jira Software. Approvals are native: JSM has built-in approval functionality with first-class objects, approvers, approval state, escalation, so you don't need an add-on to build a basic approval workflow. SLAs are native too. JSM tracks time-to-first-response, time-to-resolution, and custom SLAs out of the box, so a purchase request sitting unapproved for five days triggers an alert without any custom automation. Permissions are cleaner, because JSM's customer/agent separation handles data sensitivity at the model level: customers see what they submitted and any updates, agents see everything, with no permission-scheme gymnastics required. Cross-functional routing is the use case JSM is built for. A purchase request that needs security review, legal review, and finance approval can spawn linked tickets in each function's queue, with each team working in its own JSM project. This is what Atlassian designed JSM to do for IT support, and it works just as well for procurement intake.

Weaknesses. JSM is more constrained than Jira Software in some places. Issue type schemes, custom fields, and workflows are still configurable, but the customer portal imposes its own UX patterns; you can't make it look exactly like anything you want, it's the JSM portal. For procurement teams who also want a project-management view of their own work, planning sprints, managing backlogs, capacity planning, JSM alone is less powerful than a Jira Software project. You can run both, keeping procurement's internal work in a Jira Software project and intake in JSM, but that adds a system to manage. JSM's own licensing model is worth understanding too: agent costs scale faster than Jira Software per-user costs once you have many agents. For very large procurement teams (say, 50 or more procurement, finance, and approval-related agents), the math starts to swing back the other way, though not by enough to overcome the customer-license savings. And customizing the portal UX has limits: you can't deeply customize its navigation structure or build entirely custom interfaces inside it. The portal looks like the portal.

Is JSM actually cheaper than Jira Software for procurement?

Cost is where this decision usually gets made, so let's make it explicit with a sample scenario: a 500-person company, a 5-person procurement team, 50 occasional approvers across departments, and 100 active requesters per quarter.

That's a roughly 12x cost difference in Atlassian licensing. For procurement intake specifically, JSM wins on cost by an order of magnitude.

The picture changes if the company already has 500 Jira Software licenses for unrelated reasons, for example engineering already runs on Jira Software, so the marginal cost of adding procurement intake there is zero. In that case, Jira Software intake costs nothing additional. This is true for some Raley customers, and it's a legitimate reason to choose Jira Software despite its other limitations.

The user experience comparison

A side-by-side of what each option feels like in practice:

The Jira Software experience is excellent if everyone is already a Jira power user. It's clumsy if half your submitters open Jira once a quarter.

When should you use Jira Software instead of JSM?

Jira Software wins for procurement intake when:

• Your company is small and everyone already has Jira Software licenses for other reasons (engineering-heavy startups under roughly 100 people).
• Your procurement team wants deep project-management-style features for their own work, not just intake.
• Your requesters are technical and Jira-fluent (engineering tools companies, dev shops).
• You're already comfortable building permission schemes and custom workflows.
• Cost is genuinely not a factor.

JSM wins for procurement intake when:

• Your requesters are not Jira power users, which covers most non-engineering teams.
• You want the customer portal experience for occasional submitters.
• Cross-functional approvals are part of your workflow: security review, legal review, finance approval.
• You already run JSM for IT or HR, so procurement becomes one more service workflow.
• License cost matters, which is nearly always true and especially so for larger companies.
• SLA tracking is a requirement.

For Raley's customer, JSM is the right answer more than 90% of the time. The licensing math alone justifies it. The portal UX is the part that makes adoption stick.

Why Raley supports both, but recommends JSM

Raley works inside both Jira Software projects and JSM service projects. The data model, purchase orders, suppliers, budgets, approval matrices, is the same either way. The procurement workflows, PO generation, goods receipt, and committed-spend dashboards, work identically regardless of project type. See how the Raley Procurement product page breaks down what runs on top of either setup.

What differs is the intake experience, and that's where the choice matters. With JSM, requests come in through the customer portal. With Jira Software, requests come in through the Jira create-issue flow. Both produce the same downstream procurement workflow, but the upstream submission experience is meaningfully different.

For organizations with technical, Jira-fluent submitter populations and a small total user base, Jira Software is workable. For everyone else, JSM is the right architecture for procurement intake. We recommend JSM in nearly every new deployment, and the reason has very little to do with Raley specifically; it has to do with what JSM was designed for. For the fuller argument on why intake itself is a service-orchestration problem, see why intake-to-procure belongs in Jira Service Management.

A practical decision framework

If you're choosing today, walk through these five questions in order.

1. Are most of your purchase requesters non-engineering employees? If yes, JSM. If they're all engineers and ops-fluent users, you can consider Jira Software.
2. Do you already have JSM running for IT or HR? If yes, JSM: procurement becomes another service workflow on the same platform.
3. Will procurement requests need to touch other functions, such as security, legal, or finance, for cross-functional review? If yes, JSM: that's exactly what JSM is built to orchestrate across.
4. Is Atlassian licensing cost a real constraint? If yes, JSM: the customer/agent model is dramatically cheaper for procurement intake's user mix.
5. Are you a small team where everyone is already a Jira Software user? If yes, Jira Software is workable. Otherwise, JSM.

In practical terms, this framework points to JSM for the overwhelming majority of organizations evaluating Raley. The exceptions are real, but narrow. For more on how procurement's day-to-day operating patterns play out once intake is settled, see procurement in Jira: 8 lessons from five years in the field.

The deeper point

The Jira-versus-JSM choice for procurement intake isn't really about Jira and JSM. It's about a more fundamental question: is procurement a function used by everyone in the company occasionally, or is it the procurement team's own internal work?

If it's the team's own work, Jira Software's project-management strengths fit. If it's a service the whole company consumes, JSM's customer-portal model fits.

For modern procurement intake, where the goal is to capture all spend by making it easy for any employee to file a request through a familiar portal, the answer is almost always JSM. That's the architectural insight behind intake-to-procure as a category, and it's why Raley's positioning leans into JSM as the natural home for procurement intake inside Atlassian. Ready to see it running on your own instance? See how Raley Procurement works on JSM.

Here are some examples of how to turn the JSM portal into a procurement use case.

What's the actual difference between Jira and Jira Service Management?

Jira Software is built for a team collaborating on its own work, every participant holds a Jira license, and the interface is issue-and-board oriented. Jira Service Management adds a customer portal and a licensed-agent-plus-unlicensed-customer model, so people outside the core team can submit requests through a simple form without a Jira license. Both sit on the same underlying platform and can hold the same kind of structured data; the difference is who is expected to use each one and how they access it.

Is JSM cheaper than Jira Software for procurement intake?

Yes, usually by a wide margin. In our sample scenario, a 500-person company with a 5-person procurement team and roughly 10 cross-functional approvers, licensing everyone under Jira Software runs about $48,000 a year, while running the same setup on JSM (15 licensed agents, with every requester free as a customer) runs about $3,600 a year, roughly a 13x difference. That gap narrows only if the company already has Jira Software licenses for everyone for unrelated reasons, such as an engineering-heavy organization, in which case the marginal cost of Jira Software intake can be zero.

Can non-Jira users submit procurement requests?

Yes, through JSM's customer portal, and this is one of its core advantages for procurement. A requester doesn't need a Jira license or any Jira familiarity: they open a portal link, fill out a form with help text and required fields, and see a simplified status page afterward. In a Jira Software project, by contrast, every requester needs a Jira license and has to navigate the same interface a developer would use to file a bug.

Does Raley Procurement work the same way in both Jira and JSM?

The underlying data model and downstream workflow are identical either way: purchase orders, suppliers, budgets, approval matrices, PO generation, goods receipt, and committed-spend dashboards all work the same. What differs is only the intake step. In JSM, requests arrive through the customer portal; in Jira Software, they arrive through the standard Jira create-issue flow. Everything after that point is the same procurement workflow.

When should procurement use Jira Software instead of JSM?

Mainly when the requester population is small and already Jira-licensed for other reasons, for example an engineering-heavy company under roughly 100 people, or when the procurement team specifically wants deep project-management features, sprints, backlogs, capacity planning, for its own internal work rather than just intake. Outside of those narrower cases, JSM's licensing cost and portal experience make it the better fit for most organizations evaluating Raley.

Raley Procurement runs on both Jira Software and Jira Service Management. See how Raley Procurement works, or read 5 reasons to run your procurement on Jira or JSM for the shorter version of this argument.

What happens in the next five minutes decides everything. Where that need goes, how it gets captured, who sees it, how it gets routed: that is the difference between procurement that is fast and controlled and procurement that is slow and leaky. That front half of the lifecycle is intake-to-procure, and in most companies it is held together with email, good intentions, and luck.

Here is the argument, in one line. Intake-to-procure is a regular service request and orchestration problem, and that is precisely what Jira Service Management was built to solve. So the intake layer of procurement should live in JSM.

What intake-to-procure actually is

Intake-to-procure is the gap between "I need to buy something" and "this is an approved, well-formed request ready to become a purchase order in your ERP." Everything that determines quality and control happens in that gap:

• Capturing the request in a structured way.
• Enriching it with the context procurement needs: cost-centers, GL Accounts, categories, budget, vendor, justification....
• Triaging and routing it to the right reviewers.
• Gathering approvals, often across several functions.
• Handing a clean, approved request off to the ERP system that executes the purchase and tracks invoicing, payments and deliverables.

It is deliberately the front door of the process, separate from the financial execution (PO issuance, receiving, invoicing, payment) that an ERP or AP system owns. Intake is about capturing the business need. Orchestration is about routing it to appropriate approvers. Execution is about the transaction. A lot of procurement tooling goes wrong by trying to be Jack of all trades.

Why intake breaks in most companies

Left to grow on its own, intake spreads across every channel an employee can find: an email to a manager, a Slack DM to finance, a half-filled form, a hallway conversation, a ticket raised to the service team in the wrong project. The symptoms are familiar to anyone who has worked in operations:

No single front door. Requesters do not know where to go, so they go wherever they can. Finance and Procurement teams then spend their day chasing context instead of processing requests.

Garbage in. Free-text requests show up missing the business justification, cost-centers, GL accounts, categories. The first thing procurement does is bounce them back, and the clock resets.

Invisible routing. Approvals happen inside private inboxes. Nobody can see where a request is, who is sitting on it, or how many days it has been stuck. Good luck with the Auditors...

Maverick spend. When the official path hurts, people quietly route around it, and unvetted vendors and purchases slip through.

None of these is a financial problem. They are intake, triage, routing, and visibility problems. That is exactly the category of problem service management already solved well for IT and HR.

Why this is a JSM problem, not a finance-tool problem

The instinct is to buy a procurement suite to fix intake. But looking at what a good intake experience actually requires, and it maps almost one to one onto what JSM already does:

A single portal as the front door. JSM gives requesters one familiar place to ask for what they need, the same portal they already use for IT and HR. One front door is the highest-leverage fix for fragmented intake, full stop.

Structured, validatable request forms. Request types with conditional, validated fields enforce quality at the source, so requests arrive complete instead of getting bounced.

Triage, queues, and SLAs. JSM was built to receive a stream of requests, sort them, route them, and hold them to response times. That is exactly what an intake function needs, and exactly what email can never give you.

Workflow and automation. Jira's workflow engine and automation rules route requests, escalate the stalled ones, and move work through stages without a human shepherding every step.

Cross-functional approvals. Procurement intake almost always needs sign-off from more than one team: budget owner, finance, legal, security. JSM gathers those approvals inside one tracked request, in a defined order.

Visibility by default. Because every request is a ticket, status, ownership, and aging are visible to everyone. That is the transparency inbox-based approvals destroy.

A data backbone in Assets/ERP. Vendors, budgets, departments, and products can live in JSM Assets or ERP and be referenced at intake, so requests are enriched against managed master data instead of typed in by hand.

The last but not the least. We're yet to see an ERP which offers this kind of functionality that regular business users would really be able to use.

There is an adoption argument sitting on top of the technical one, and it might be the most important point in this whole piece. People already submit requests in JSM. Put procurement intake where employees already go, and they actually use the front door instead of walking around it. A process people follow beats a better process they avoid, every time.

What good intake-to-procure looks like in JSM

A mature setup tends to share the same shape:

1. One portal entry point for "I need to buy, I need a new vendor, I need a quote," so requesters never have to know which downstream process applies.
2. Distinct request types behind that door (purchase request, new vendor, price change, quote), each with a form tuned to collect exactly what that process needs.
3. Validation and enrichment at intake, pulling cost centers, budgets, and approved vendors from Assets/ERP so the request is well-formed before a human touches it.
4. Automated triage and routing that sends each request down the right approval path based on amount, cost-center, category, and department.
5. Ordered, cross-functional approvals with notifications that fire in sequence, plus visible status and SLAs the whole way through.
6. A clean handoff of the approved request to the system that executes the purchase (ERP, AP, or a PO engine), with the PO number flowing back onto the ticket for traceability.

One principle runs through all six: own the orchestration in JSM, hand off the transaction to the system built for it. Intake belongs to JSM. The ledger does not.

Where the boundary sits, and where an app helps

Saying intake belongs in JSM is not saying that the whole procurement process belongs there. The financial transaction (three-way matching, invoicing, payment), the procure-to-pay (P2P) half of the lifecycle, Vendor Contracts and lifecycle management belongs in your ERP or AP stack. The value of putting intake in JSM is that the request reaches that boundary already structured, approved, and traceable, instead of arriving as a half-formed email at 4:55 on a Friday.

Stitching the intake layer together natively is real configuration work: request types, Assets-backed enrichment, cross-functional approval matrices, and a clean ERP handoff. You can absolutely build it yourself if you have the Jira capacity and the patience.

This is where a purpose-built app like Raley Procurement earns its place. It delivers structured purchase requests, vendor management, cost-center / cross-functional approvals, and PO generation on top of JSM out of the box, so you are shaping an intake process rather than assembling one from parts. Build or buy comes down to how complex your intake is and how much Jira time you want to spend. Either way, the layer belongs in JSM.

Can Jira Service Management handle procurement intake?

Yes. Procurement intake needs a single request portal, structured and validated forms, triage and queues, SLAs, workflow and automation, cross-functional approvals, and visibility into status and aging. Those are JSM's core capabilities, the same ones that handle IT and HR requests. JSM Assets can also hold vendors, budgets, and cost centers as managed master data that requests reference at intake.

How is intake-to-procure different from procure-to-pay (P2P)?

Intake-to-procure is the front of the process: capturing a need, enriching it, routing it, and gathering approvals until the request is well-formed and ready to become a purchase order. Procure-to-pay (P2P) picks up after the PO and runs through receiving, three-way matching, invoicing, and payment. Intake-to-procure is a service-request and orchestration job, which is why it fits Jira Service Management; procure-to-pay is a financial transaction, which is why it belongs in your ERP or AP system.

Should procurement intake live in JSM or in my ERP?

Split it by job. Intake and orchestration (capture, enrichment, routing, approvals, visibility) belong in JSM, because they are service-request problems. The financial transaction (three-way matching, invoicing, payment) belongs in your ERP or AP stack. The point of putting intake in JSM is that the request arrives at the ERP boundary already structured, approved, and traceable.

Why does procurement intake break without a tool like this?

Because it fragments across email, Slack, half-filled forms, and tickets raised in the wrong place. That produces four recurring symptoms: no single front door, low-quality free-text requests, approvals hidden inside inboxes, and maverick spend when people route around a painful process. These are intake, triage, routing, and visibility failures, not accounting failures.

Do I need an app, or can I build intake in JSM myself?

You can build it yourself with request types, Assets-backed enrichment, approval matrices, and an ERP handoff, if you have the Jira capacity. A purpose-built app like Raley Procurement delivers structured purchase requests, vendor management, budget-aware approvals, and PO generation on top of JSM out of the box. The decision comes down to how complex your intake is and how much Jira configuration time you want to spend.

What stays in the ERP or AP system?

The financial execution: purchase-order issuance against the ledger, receiving, three-way matching, invoicing, and payment. JSM owns the request and its approval trail. The ERP owns the money. The PO number flows back onto the JSM ticket so the request stays traceable end to end.

The bottom line

Intake-to-procure is not an accounting function bolted onto the front of procurement. It is a request-management and orchestration function, and treating it like one is the unlock. JSM already gives you the single front door, the structured intake, the routing, the cross-functional approvals, and the visibility good intake demands, all inside a portal employees already use.

Put intake-to-procure in JSM. Keep the financial transaction in the systems built for it. You get the rare combination of a fast front end and a controlled one, instead of forever choosing between the two.

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.

• Purchasing was the one process this team ran outside Jira, and it showed: surprise invoices, duplicate tools, approvals no one could find.
• Moving requests into the JSM portal gave every purchase one place to start and an audit trail that built itself.
• Approvals route by amount and department, so a 200 dollar cable and a 40,000 dollar contract no longer take the same path.

Maria runs finance and ops at a 120-person software company. Every Monday she opened a spreadsheet, three Slack threads, and her inbox to answer one question: what did we agree to buy last week?

Her team ran everything else in Jira and JSM. Purchasing was the one process that had wandered off, and it came back as surprise invoices, two people expensing the same tool, and approvals nobody could find. Here is how a team in that spot moved buying back to where the work already happens, with Raley Procurement for Jira and JSM.

The challenge: spend with no home

The company was growing, and so was its spend: new laptops, contractor invoices, a dozen SaaS renewals a month. The data was fine. Budgets, departments, and vendors were all known. The process around them was not. No single place to raise a request, no agreed path for who signs off, no current record of what had been committed. The spreadsheet was a source of truth, just never a current one.

The old way of approving a purchase

Before Raley Procurement, one purchase took a familiar detour:

• Ask around. Ping a manager on Slack about budget, then guess who else needs to approve.
• Email the sign-off. Approval lived in a reply-all thread finance was sometimes copied on.
• Update the sheet, eventually. A row got added when someone remembered, so the tracker always ran a few days behind.
• Reconcile at month end. Finance pieced it together from invoices after the money was gone.

Every step worked alone. Together they cost Maria an afternoon of detective work every Monday.

The solution: Raley Procurement for Jira and JSM

The team installed Raley Procurement and added "Raise a purchase request" to their existing JSM portal. Requests now start where every other request does, and move through an approval workflow the team set up to match how it actually buys. Nothing left Jira, and the audit trail built itself as a request moved from raised to approved to ordered.

What the team turned on

1. Requests in the JSM portal. A form in the portal people already use, with a known product and supplier catalog. No new login.
2. Routing by rule. Each request goes to the right approver by product, budget, department, and tier, so a 200 dollar cable and a 40,000 dollar contract take different paths.
3. Multi-currency. Vendors bill in different currencies, and the app handles it without a side calculation.
4. Order tracking from the ticket. Approved requests become orders: what is ordered, what is received, what is still outstanding.
5. POs and dashboards. A formatted PDF purchase order for the supplier, plus a live dashboard of committed spend finance can export to CSV.

"A request that used to drift for two or three days across Slack and email now clears the same day, in one system, with a record attached."

The results

Within the first week, the day-to-day changed:

• One place to request and approve. People stopped asking around. They opened the portal, submitted, and the right person was notified.
• Approvals that match the amount. Small buys cleared fast; large commitments got the extra sign-off, because routing ran by rule instead of by memory.
• A current record. The dashboard moved with the requests, so finance stopped rebuilding the month from invoices.

The shift in one view:

These show the shape of the change, not measured figures from a named customer. The point holds: a request that used to drift for days now clears the same day, with a record attached.

Why keeping it inside Jira and JSM mattered

The real win was not the features. It was that finance and ops got them without running a separate procurement platform. Maria's team already trusted Jira and JSM with its work, so adding purchase orders and approvals there meant no extra tool to administer, no data to sync, and no retraining. The app is Cloud Fortified and Partner Supported, so the tool running the spend meets the same bar as the work going through it.

• Five years building procurement on Jira and JSM produced eight lessons that cost us the most to learn.
• JSM beats the alternatives, custom workflows are the whole point, and purchase data belongs in JSM Assets, not custom fields.
• The biggest mistake: handling multiple line items with sub-tasks. Get the approval order right instead.

Five years ago, a client asked us a deceptively simple question: could they run their company's purchasing through Jira? We said yes, because we knew the platform could do almost anything. We did not yet know how much "almost" was carrying in that sentence.

Since then we have built procurement on Jira and Jira Service Management for a lot of companies, and we have made most of the mistakes so you do not have to. Here are the eight lessons that cost us the most to learn, written down so they cost you nothing. We build Raley Procurement & Quotation, so this is the view from inside the workshop.

1. JSM beats the alternatives for procurement

Of the Atlassian options, we prefer Jira Service Management for procurement. Any Jira-type platform can technically run purchasing, but JSM wins on two counts.

First, the portal is simpler. Jira's flexibility comes with interface complexity, and the JSM portal hides most of it behind a clean request form that non-technical buyers can actually use.

Second, familiarity. Plenty of companies already use JSM to talk to IT and HR, so the people raising purchase requests have used the portal before. Less training, faster adoption. Jira Work Management and the others tend to stay inside IT, which makes them a harder sell to a finance or operations team.

2. Customizable workflows are the whole point

Most purchasing systems ship with a fixed workflow and a few cosmetic options. You can add or skip an auxiliary step, but the core logic belongs to the vendor. The trouble is that every company approves money differently, and "differently" is exactly what fixed workflows cannot handle.

This is where Jira earns its place. Custom workflows, transitions, and post-functions are the backbone of the platform, and you can shape them to match how your company actually buys. One example we use often:

A purchase request is created, filled in, and sent for approval. Before any of that, management adds a preliminary verification step that catches obvious errors early, so fewer requests bounce back from approvers.

That single tweak means fewer rejected requests, faster approvals, and less time wasted overall.

3. Request types map cleanly to business processes

Finance needs precise data, and getting clean data out of busy people is its own discipline. The right information has to land in the right field, which is hard when a form has conditional logic or a vague free-text box doing too much work.

The JSM portal handles this well, because you can combine multiple request types with customizable, validated forms. A few things separate request forms can do:

• Onboard a new vendor with its own fields and approval path.
• Request a change to a purchase request that is currently locked.
• Add a discount or rebate to an already-approved request.
• Request a price change in the product registry, with a lookup and a justification.

Each of these is really its own process, so it makes sense to give each its own request type. Users still pick from one place: the JSM portal.

4. Purchase request forms are harder than they look

A good purchase request form is much harder to build than people expect. Stock Jira and JSM forms are fine for the simplest buying, because they are static. Even many third-party "smart" forms fall short, because they do not know the buyer's limits, budget, or approval logic.

There are two ways through this:

1. Build a custom form with integrations that look up users, budgets, vendors, products, and departments, plus custom approval routing. A good one lets you pick departments and vendors, expose your product registry, add multiple order lines (each with its own cost center), enforce policies like legal or security review for new products, and calculate taxes and totals to assign the right approvals.
2. Use a specialized app like Raley Procurement & Quotation that does all of the above out of the box.

One thing we learned the hard way: do not try to support multiple line items through sub-tasks. JSM does not support it, and even where it works, keeping child issues in sync with parent totals and approvals is a daily headache you will come to resent.

5. Track budgets, vendors, and products in JSM Assets

A purchase request cannot stand alone. It has to connect to departments, budgets, vendors, and products, and deciding where that data lives takes some thought.

Our first instinct, like everyone's, was Jira custom fields. It does not scale. Departments cannot link to users without custom work, vendors carry too much metadata for a field, and putting thousands of products into custom-field options is a genuinely bad day for whoever uses the form.

JSM Assets is the better home. It keeps purchase-related data organized, and because it has a REST API, syncing cached data with your master data is more manageable. Two cautions from experience:

• Store the minimum you need. Adding a field to Assets is easy; maintaining it forever is not.
• Let your ERP calculate totals and aggregates, not Jira. Duplicating data is bad. Duplicating behavior is worse.

Once a purchase is executed, JSM Assets also works nicely for tracking the goods and services you received. At that point it is doing exactly what the name says.

6. External PO numbers need their own process

Every purchase order needs a unique number, and how you generate it depends on the process you are replacing.

If a company has no formal numbering yet, the simplest move is to use the Jira ticket number as the PO number. It is clean and it tracks easily downstream.

Most companies moving to Jira already have a numbering system, often from an ERP like NetSuite. There, the external number has to be assigned to the Jira ticket, which a custom PO-number field set via a Jira Automation hook handles well. It also helps to let finance overwrite that number manually on the issue screen, and to print the PO number on any PDF sent to the vendor so everyone shares one reference.

7. Build in flexibility, because mistakes are certain

No matter how good your validation is, procurement mistakes will happen. Typos, miscalculations, a number that is an order of magnitude too big. The question is not whether, it is how painful the fix is.

The worst case is a mistake discovered after a request has cleared a long approval chain and gotten the C-suite's blessing. Most companies would much rather edit the request than cancel and restart, so a finance role that can intervene on a locked request saves real executive time.

Flexibility also covers the human stuff: an approver who is off sick, a ticket that slips through the cracks. Permissions to modify a locked PO, shortcuts to approve or reject, and reminder notifications all reduce the friction. The non-negotiable is accountability: any change to a locked PO should be auditable, so you can see who changed what, and the data is preserved automatically.

8. Get the approval types in the right order

Approvals are the heart of procurement, and the order matters more than people expect. Across our customers, the common approval types are:

• New vendor
• New product or service
• Department
• Budget or project
• Program (for spend over a set threshold)
• Gross-amount approvals

Some companies use all of them, some use one or two. When several apply, the order that usually works best is: new vendor, new product, department, budget, program, then gross-amount approvals in ascending order. Gross-amount approvals climb the hierarchy until they reach a level that can sign off the total.

Notifications should follow the same order as the approvals. For gross-amount approvals especially, send them up the chain in sequence: a CFO and VP approve before the request ever reaches the CEO's inbox.

If you are weighing the move, start with 5 reasons to run your procurement on Jira or JSM, or see how the same engine powers sales quoting in JSM.

• Raley Bookman adds a "Book a meeting room" button to the Jira Service Management portal, so people book where they already raise requests.
• Each reservation links to the room asset in the JSM Assets CMDB, so capacity, location, and equipment stay attached to the booking.
• A room can hold only one reservation per time slot, so double-bookings are blocked at the source rather than discovered at 1:59 p.m.
• Facilities stopped hand-managing calendars, and the company got a clean record of how its rooms actually get used.

Three teams. One conference room. One 2 p.m. slot. Someone is about to present a quarterly review to an empty chair and a very confused cleaner.

If that sounds familiar, you already understand the problem Raley Bookman was built to solve. Here is how one team moved room booking out of their inbox and into the Jira Service Management portal, where it belonged all along.

This is an illustrative scenario, not a named customer. The headaches, however, are entirely real.

What Raley Bookman does, in one paragraph

Raley Bookman adds a "Book a meeting room" button to the Jira Service Management portal. Employees see live availability, pick a slot, and the reservation links straight to the room asset in the JSM Assets CMDB. Because a room can hold only one reservation per time slot, the double-booking problem stops at the source instead of being discovered at 1:59 p.m.

The problem: booking a room should not need a committee

Jack runs Jira at a company that, like most, asked everyone back to the office part-time. Demand for meeting rooms went up. The way people booked those rooms did not keep pace.

All the room data already lived in the JSM Assets CMDB: capacity, location, whether the projector worked this week. None of it was doing any good, because the actual booking happened like this:

• The email ask. Someone emailed the facilities team to find out if a room was free.
• The manual check. An agent cross-referenced the CMDB against a calendar by hand, like a librarian who has lost the card catalog.
• The collision. Two teams booked the same room anyway, met in the doorway, and quietly resented each other for the rest of the quarter.

Jack's manager, Toby, asked for one thing: let people book a room through the portal themselves, without facilities playing switchboard.

The fix: a booking button inside the portal

Jack installed Raley Bookman and added a "Book a meeting room" button to the JSM portal. The booking flow went from an email thread to three clicks: open the portal, see what is free, claim a slot.

No new tool to learn. No second login. The thing employees already use for IT and HR requests now books rooms too.

"The booking flow went from an email thread to three clicks: open the portal, see what is free, claim a slot."

What the team set up

Four pieces did the work:

1. Portal booking. Employees click "Book a meeting room" and see a calendar of open slots straight away.
2. Asset-linked reservations. Each booking is tied to the specific room asset in the CMDB, so details like "seats 10" or "has a projector" stay attached to the reservation.
3. A real-time room view. The "Meeting room view" shows what is occupied right now, so people stop requesting rooms that are clearly taken.
4. Conflict handling. Once a room is reserved for a slot, Bookman will not hand the same slot to anyone else.

What changed

The booking process moved from inbox to portal, and a few things followed:

• Overlaps are blocked by design. Bookman will not accept a second reservation for a room that is already taken in that slot, so the doorway standoff stops happening.
• No more availability emails. People can see what is free and claim it themselves, instead of asking and waiting.
• Lighter load on facilities. The team stopped hand-managing calendars and got their day back for work that actually needs a human.
• A clean record. Because every booking is tied to a JSM asset, the company has a complete record of how its rooms get used, which is genuinely useful when someone asks whether the third-floor room is worth keeping.

No miracle, no buzzwords. Just the booking living where the work already lives.

• A manual purchase order can cost up to $506.52 to process (APQC), once delays, errors, and chasing are counted.
• You can run the full purchasing process, request to approval to vendor PDF, inside Jira or JSM with an app like Raley Procurement & Quotation.
• Your team keeps the interface they know, finance gets live budget reporting, and approvers can act straight from email.

A manual purchase order can cost up to $506.52 to process, according to APQC research, once you count the delays, errors, and chasing. That is a remarkable amount to spend on the privilege of buying something.

Good procurement does the opposite: the right things arrive on time, approvals move, and operations run under budget. The catch is the tooling. Here are five reasons to run procurement on software your team already uses, Jira or Jira Service Management, instead of bolting on another ERP.

The short version: you can run a full purchasing process, from request to approval to vendor PDF, inside Jira or JSM with an app like Raley Procurement & Quotation. Your team keeps the interface they know, finance gets live budget reporting, and approvers can act straight from their email.

1. Your team already knows the tool

The biggest cost of new software is the learning. Jira is trusted by a large global base of organizations, including names like NASA and Tesla, per Atlassian's customer list. Your team already uses it for IT and project work, so a purchase request is just another familiar form, not a new system to dread.

Requesters submit purchase orders through the Jira or JSM interface they use every day. The learning curve is short because there is barely a curve.

2. The workflow bends to your process

Most purchasing tools make you adapt to their workflow. Jira lets the workflow adapt to you. With Raley Procurement & Quotation, almost any purchasing process is possible: products, services, inventory, supplies, raw materials, each with the steps and rules your company actually follows.

Because purchase orders follow your Jira project workflow, you customize them the same way you customize everything else in Jira.

3. Approvals fit your real approval matrix

Approval rules are where generic tools fall down. Raley Procurement & Quotation lets you approve by budget, by department, and along your specific corporate approval matrix, including separate approvals for new products or vendors.

Approvers get an email when their decision is needed, and can approve or reject each request right from that email. That improves oversight and shortens the wait, because nobody has to log in to keep a purchase moving.

4. It connects to your other systems

Procurement does not live alone, so the app comes with an API to connect to your other tools. Your systems can update products and services in the registry dynamically, which lets you track the full life cycle of inventory, requests, and orders without re-keying data between systems.

5. Finance sees spend in real time

Leaders should not have to guess at the numbers. With live reports, finance and approval managers can see current budget status from inside Jira, across departments, budgets, and suppliers. Approved requests generate a PDF purchase order, attach it to the ticket, and can send a copy to the vendor automatically.

Who does what

The app fits the roles already in your procurement process:

• Employees submit purchase requests as Jira users or JSM customers; the procurement team validates and approves them.
• Vendors receive approved POs automatically, as a generated PDF emailed to the right supplier.
• Management oversees finance and purchasing, with budgets and inventory updating dynamically.
• Admins set up, deploy, and maintain the app, including company structure, users, and permissions.

For the longer view, read 8 lessons from five years building procurement in Jira.

• Shared resources like rooms, laptops, and vehicles are easy to own and hard to share, and spreadsheets break the moment two people want the same one.
• Raley Bookman adds self-service booking to the JSM portal on top of JSM Assets, so people reserve from the Help Center they already use.
• Each reservation becomes a Jira ticket linked to the asset, so a slot can only be held once and the audit trail builds itself.

Somewhere in your company right now, a laptop is "definitely booked," a meeting room is hosting two teams who both have it in writing, and a spreadsheet called bookings_FINAL_v3.xlsx is quietly lying to everyone.

Shared resources are easy to own and hard to share. Raley Bookman fixes the sharing part by putting reservations where your team already works: the Jira Service Management portal. It adds self-service booking on top of the assets you already track in JSM Assets. People open the portal, see what is free on a timeline, pick a slot, and get a confirmation. Each reservation becomes a Jira ticket linked to the asset, so a room, a loaner laptop, or a fleet vehicle can only be held by one person at a time.

The real cost of booking by spreadsheet

Most companies still book internal resources with some mix of spreadsheets, a shared calendar, and a hopeful email to whoever "looks after" the thing. That works until two people want the same resource at the same time, which is to say it works until lunchtime. Three things go wrong, every time:

• Downtime. Two bookings collide, someone loses, and a meeting starts ten minutes late while people find another room.
• Wasted spend. Nobody can see what is actually free, so teams buy a sixth loaner laptop while five sit in a drawer.
• Annoyed people. Booking a desk should not require knowing which colleague secretly controls the calendar.

How Bookman works

Bookman sits between your JSM Assets database and the service portal. Your assets already live in JSM Assets, with their capacity, location, and details. Bookman makes those assets bookable, so people reserve them from the same Help Center they already use to raise IT and HR requests. No new tool, no second login.

What you get

Four things do the work:

1. A real-time timeline. People see availability at a glance, pick a slot, and get an automatic confirmation, all inside the portal.
2. Asset-linked reservations. Every booking ties to a specific asset in JSM Assets, so details like "seats 10" or "has a projector" stay attached to the reservation.
3. Conflict prevention by design. Once an asset is held for a slot, Bookman will not hand the same slot to anyone else. Double-bookings stop being possible rather than being discovered.
4. Booking rules you set. Define booking windows (say, 8am to 5pm) and maximum durations so one person cannot reserve the demo room for a fortnight.

Every reservation also creates a Jira ticket, which gives you a searchable record of who booked what and when. That record is genuinely useful later, when someone asks whether the third-floor room is worth keeping.

Where teams use it

Bookman handles any asset you track in JSM Assets, not only meeting rooms:

• IT: loaner laptops, test devices, VR headsets, anything that gets checked out and (eventually) returned.
• Facilities: meeting rooms, hot desks, parking spaces.
• Operations: pool vehicles and shared equipment for off-site events.

It runs on your existing Jira, so going from five rooms to five thousand devices is a matter of adding assets, not adding infrastructure. You can also read how one team used Raley Bookman to end meeting-room double-bookings.

• Jira is powerful but unfriendly to non-technical users, so requests often arrive as messy emails instead.
• Raley Intake Forms builds branded, dynamic forms that create clean Jira tickets, embeddable on any site or Confluence page, with no license needed to submit.
• Conditional fields and field mapping mean what lands in Jira is already structured, so you skip the manual cleanup.
  

Managing incoming requests in Jira should not feel like a second job. A bug report here, a marketing ask there, an HR ticket that arrives as three separate emails and a screenshot of a screenshot. The standard Jira issue screen is either too much for the person filling it in, or too little for the data you actually need back.

Data collection should be the easy part. That is why we built Raley Intake Forms for Jira: branded, dynamic forms that turn messy requests into clean, structured tickets. You build the form, embed it anywhere (your website, a Confluence page, or a portal), and the data maps straight to your project's schema. Submitters do not need a Jira license, and fields adapt to their answers, so what lands in Jira is already clean.

The problem: Jira is powerful, not friendly

Jira is excellent at project management and intimidating at first contact. Non-technical users open the default issue screen and meet a wall of fields, jargon, and a layout that feels heavy. Many just give up and send an email instead, which is how you end up back where you started.

The native Jira Issue Collector helps, but it is short on styling and the dynamic logic you need to get good data the first time.

Dynamic fields that hide what doesn't apply

Why ask for a browser version when someone is reporting a billing problem? With conditional logic, Raley Intake Forms shows or hides fields based on earlier answers. Forms stay short and relevant, which is also the quickest way to get more of them finished.

Forms that match your brand

Your brand should not stop at the edge of your website. Intake Forms gives you control over colors, fonts, and layout, so moving from your site to the form feels like one continuous experience rather than a jarring handoff to "the Jira bit."

Drop a form into Confluence

Using the dedicated Confluence macro, you can turn any Confluence page into an intake portal. It is a tidy way to centralize internal requests without sending your team off to navigate away from the documentation they are already reading.

Build it without code

You do not need a developer to build a solid form. The what-you-see-is-what-you-get editor lets you drag and drop standard and custom Jira fields, set validations, and generate an embed code in minutes.

Clean data, mapped to your fields

Intake Forms supports Jira field types as first-class citizens. Checkboxes, date pickers, dependent dropdowns: whatever the user submits maps to your project schema, so you skip the manual data entry and cleanup that usually follows a form submission.

Better together: the Raley ecosystem

If you already run Raley Email Notifications, Intake Forms is the front half of the same loop. A form creates a ticket, and a custom-styled notification keeps the reporter updated as it moves, so the person who raised the request never has to email to ask "any news?"

• Jira's built-in notifications get noisy fast: too many, too vague, or missing the one field that mattered.
• A custom solution gives you branded emails, only the fields you choose, real attachments, and localized messages.
• Consolidated digests and reminders cut the inbox flood and keep the issues that matter from slipping.

How long did you spend this week hunting for the one email with the detail you needed? The built-in notifications in Jira and JSM are fine until they are not: too many, too vague, or missing the one field that mattered. That is time you could have spent on the actual work.

A custom notification solution makes Jira's communication clearer and more deliberate. Here are five benefits you get from one, with Raley Email Notifications as the example throughout.

1. Keep customers informed

Customers often want to follow an issue that affects them, and a custom notification keeps them in the loop as it progresses.

It also fixes a small daily annoyance: attachments. Instead of sending a link that drags the customer back to a portal they will need to remember a password for, you can send the real attachment, so they never have to leave their inbox. And when your customers speak different languages, the notifications can go out in each customer's preferred language. You decide what gets sent, how, and when.

2. Brand and customize the message

When you write to a customer, you want control over what they see. A custom solution lets you share only specific fields, add your logo so the email clearly comes from you, adjust the layout, and localize the content.

Is the next step on the customer's side? A custom notification can spell out what is needed and how urgent it is. Best of all, you do not need a developer to set any of this up. A Jira or project administrator can do it.

3. Cut the flood of Jira emails

You know the feeling. The team wraps a planning meeting, and your inbox fills with one notification per change, which you open one after another like a slot machine that only pays out in admin.

Consolidating those into a single digest cuts the clutter, saves you the click-through, and leaves you with one email to read instead of twenty. If you are a manager, picture a single summary of just the changes you care about, at the granularity you choose, waiting for you on Monday morning.

4. Set reminders so nothing slips

Some issues you simply cannot afford to forget, like the ones a customer needs resolved before a delivery date. A reminder keeps you connected to those issues and makes sure they are updated before the next meeting, instead of surfacing the morning after the deadline.

5. Stay informed with scheduled digests

An issue changed, a task was created, a status moved. Scheduled digest notifications, daily or weekly, can land in your inbox or a Slack or Microsoft Teams channel, so you and the team stay current without watching every ticket. Regular, structured updates are what let you make decisions and keep work on track.

To meet this demand, we are proud to introduce Raley Bookman, the premier asset reservation solution built specifically for the Jira Service Management (JSM) ecosystem.

The Challenge: The Cost of Resource Friction

Many enterprises still rely on fragmented systems—spreadsheets, legacy calendars, or manual email chains—to manage internal assets. These decentralized methods often lead to:

• Operational Downtime: Productivity losses due to double-bookings or missing equipment.
• Underutilized Assets: Lack of visibility leads to unnecessary procurement of resources that are already available.
• Employee Frustration: Complex booking processes detract from core high-value work.

The Solution: Raley Bookman

Raley Bookman bridges the gap between your Asset Management database (JSM Assets) and your Service Desk, providing a unified, self-service portal for resource scheduling. By integrating directly into the JSM Help Center, Bookman allows your workforce to reserve what they need, exactly when they need it, within the tools they already use.

Strategic Business Benefits

1. Maximized Asset ROI

Gain a clear, real-time view of resource utilization. By centralizing all reservations within Jira, management can identify high-demand assets versus underutilized ones, enabling data-driven decisions on procurement and decommissioning.

2. Seamless Employee Experience (EX)

Employee satisfaction is tied to the quality of internal tools. Raley Bookman offers a modern, intuitive "single-window" booking interface. Employees can view real-time availability on a timeline, select their desired slots, and receive automated confirmation—all without leaving the company’s service portal.

3. Automated Governance and Conflict Prevention

Eliminate the risk of human error. Raley Bookman enforces your business rules automatically:

• Collision Prevention: Intelligent logic prevents double-bookings.
• Scheduling Compliance: Set specific booking windows (e.g., 8:00 AM – 5:00 PM) and maximum durations to ensure fair access for all team members.
• Audit Readiness: Every reservation generates a Jira ticket, creating a permanent, searchable audit trail of asset usage and history.

4. Low Overhead, High Scalability

As a cloud-native Atlassian partner solution, Raley Bookman requires minimal setup and leverages your existing Jira infrastructure. Whether you are managing five meeting rooms or five thousand IT devices, the system scales with your organization without adding technical debt.

Versatile Use Cases Across the Enterprise

• IT Operations: Streamline the checkout of loaner laptops, VR headsets, or mobile testing devices.
• Facility Management: Manage conference rooms, hot desks, or parking permit allocations.
• Corporate Services: Coordinate shared company vehicles or specialized equipment for off-site events.

Conclusion: Future-Proof Your Resource Management

Raley Bookman is more than a booking tool; it is a catalyst for operational excellence. By removing the friction from asset reservation, you empower your teams to focus on growth while ensuring your corporate resources are utilized to their fullest potential.