The form is a request type
JSM fields exist so an agent can route a ticket. They do not collect the current process, the people, or the outcome that would make a software change worth doing.
JSM software intake
Why Jira Service Management is the wrong software intake
This article is the workflow story, not a feature chart. Jira Service Management is the wrong software intake when a portal form creates a ticket and the requestor’s people, constraints, and owner die in that work item. Walk the failure steps. Leave the product matrix for the comparison page.
For IT and PMO partners who already run Jira Service Management and keep finding system-change work filed as portal tickets.
A software request that starts in JSM usually loses
- Who is affected and what happens today
- A reachable owner who is not the ticket reporter
- Constraints that never fit a request-type field
A service portal trains people to file software change as a ticket
Employees already know the JSM portal. When that is the only door, a new system or a meaningful change arrives as a request type. An agent assigns it. Comments become the spec. Later QA—if anyone invites them—tests the ticket. Software intake needed a story, an owner, and a decision. It received a queue.
The SLA is the wrong clock
First-response targets reward speed. A software request needs completeness and a paired estimate, not a two-hour acknowledgement.
The ticket becomes the spec
Agents paraphrase. Requestors add comments. Testers open the work item. The original software ask is gone.
JSM Software Intake Method: Stop Turning Software Requests Into Service Tickets
Keep the service desk for service work. Give software change a different door: a complete request, a review, and a recorded decision. Do not add another JSM request type and call it intake.
The service desk is the wrong door. Put the software ask on software project intake so reviewers see a complete request instead of a portal ticket.
Once the story is understandable, requirements gathering software turns it into reviewed answers—without pasting the JSM description into a spec.
If the only path today is a request type, start the replacement with software project intake and leave JSM for incidents and access.
- 1
Name the two doors
Write down what belongs in JSM and what does not. Incidents, access, and catalog items stay. New systems and meaningful software changes leave.
If the employee needs help with something that already exists, it is a ticket. If they are asking to change or replace software, it is a software request. One sentence on the portal prevents most misfiles.
- 2
Collect a complete software request
Ask what happens today, who is affected, the outcome that would make the change worth doing, a reachable owner, and known constraints.
Those answers are the intake. A summary line, a priority, and a preferred vendor are not. If the requestor cannot name who hurts, send it back—do not open a ticket to ‘get it moving.’
- 3
Review for a story, not for an SLA
A reviewer checks whether a stranger can understand the ask. Completeness beats first-response time.
Ready enough means problem, people, outcome, owner, and limits are present. Missing solution design is expected. Missing who is affected is not. JSM’s clock does not apply.
- 4
Estimate both sides before anyone assigns an agent
Size training and adoption next to the build. A ticket assignee is not an investment decision.
If only the technical hours exist, the case is a development quote. Write the business estimate on the same record. Then leaders can say yes, no, or not yet.
- 5
Keep delivery on the request, not on the portal issue
Requirements, stories, testing, and release stay on the Foundry thread. JSM does not become the backlog.
If engineering already lives in Jira Software, point the work item at the living request. Do not paste the portal ticket into an epic description and call that the spec.
Visual proof
What a JSM ticket erases before the epic exists
A portal form creates a work item. Foundry keeps the requestor’s people, constraints, and owner on the thread that later becomes requirements, a sprint, and QA.
Foundry submission
Jira-ready epic
Jira-ready sprint epic
Client Intake Portal
Pointer to the Foundry thread—not a paste of the intake form into a Jira description.
- Epic name
- Client Intake Portal
- System of record
- Foundry request (living thread)
- Outcome
- Measure first-six-month intake outcomes
- First-release boundary
- Approved services only; public status out
- Estimates
- Business effort and technical effort recorded before sprint planning
- Child work
- Stories derived from reviewed requirements
If engineering must sprint in Jira, create the epic as a pointer to this record. Do not copy the intake into Description.
What the Jira epic should inherit—not retype
This is the integration layer. Foundry holds the living request. The work item only needs a stable pointer plus the fields engineering already reports on.
| Foundry field | Jira epic field | What survives |
|---|---|---|
| Proposal name and requestor | Epic summary and reporter | The person closest to the problem stays visible |
| Business problem and first-release outcome | Epic description as a pointer, not a rewrite | QA can open the original words |
| Business and technical estimates | Sprint commitment only after the recorded yes | Training and adoption are not dropped at the paste |
| Named exclusions and constraints | Linked acceptance / definition of done | Out-of-scope work does not appear as new tickets |
| Reviewed business and functional requirements | Child stories and tasks | Stories are derived from the thread, not paraphrased |
Practical template
Software-or-service checklist
Use this at the portal and at triage. If the row points at software change, do not open a JSM ticket as the system of record. Examples are fictional.
| Signal | Why it matters | What to do |
|---|---|---|
| Something that already exists is broken | That is an incident or a defect against a running service. | The badge reader fails on the east door. File it in JSM. |
| Someone needs access or a catalog item | That is a service request with an SLA. | Provision a laptop or reset a mailbox. Keep it in JSM. |
| They want a new system or a meaningful change | That is software demand. A ticket will erase the story. | Replace volunteer scheduling email with software. Open a software request. |
| They named a vendor or a feature list first | A solution-first portal field hides the current process. | Send back: what happens today, who is affected, what better looks like. |
| There is no reachable business owner | Follow-up questions need a name. A reporter is not an owner. | Return the request until an operations lead will answer. |
| The only clock is an SLA | Speed rewards incomplete software asks. | Pause the SLA. Review completeness. Then estimate both sides. |
| Comments are becoming the spec | The ticket has already replaced the request. | Move the living answers onto one request thread. Stop adding spec to the issue. |
Worked example
What happens when a software ask starts as a JSM ticket
A facilities lead files “need a scheduling tool” through the portal. An agent assigns it. Three months later QA tests the ticket summary.
| Check | What we recorded |
|---|---|
| Request type | “Software / other” in the employee portal |
| What the form captured | Summary, urgency, preferred vendor name |
| What it missed | Today’s spreadsheet process, who is blocked, and a business owner |
| What the agent did | Assigned an analyst and started the SLA clock |
| What QA opened | The ticket description and the last twenty comments |
| What would have been enough | A complete software request, both estimates, and a recorded yes |
The portal did its job: it created a ticket. That is why it is the wrong software intake. Service desks resolve tickets. Software change needs a request that can survive review, estimates, and QA.
What JSM collects vs. what software intake needs
| JSM portal ticket | Software request |
|---|---|
| Request type, urgency, and a summary line | What happens today, in the requestor’s words |
| Reporter and an assigned agent | A reachable business owner for follow-up questions |
| An SLA clock and a queue | A completeness review, then dual estimates |
| Comments that become the live spec | One thread testers can still open at release |
What not to do with JSM and software requests
Adding a “project intake” request type
A new form that still creates a ticket keeps the same failure. The object is wrong, not the field list.
Using the SLA as a completeness check
Acknowledging a software ask in two hours does not make it reviewable. Pause the clock or take it off the desk.
Pasting the ticket into a Jira Software epic
That is a third document. The portal issue, the epic, and the original ask will disagree.
Inviting QA only to the ticket
Testers will verify the paraphrase. Give them the living request or accept that you are testing the handoff.
In Precision Foundry
How the same data thread stops the JSM failure
The method above is operational: two doors, a complete story, a completeness review, then estimates before anyone assigns an agent. Precision Foundry stores that same data thread so the QA tester opens what the business user wrote—not what an agent typed into a ticket.
- The requestor’s words stay on the record the reviewer, estimator, and tester open
- Completeness is checked before anyone starts an SLA clock
- An agent is not assigned until both sides of the change are sized
- QA opens that same data thread instead of the portal ticket
Common questions
Questions about jsm software intake
Why is Jira Service Management the wrong software intake?+
Because a portal form creates a service ticket. Software intake needs a complete request—current process, people, owner, constraints—and a decision. Ticket fields, SLAs, and agent comments replace that story.
Can we keep JSM if we stop using it for software requests?+
Yes. Keep JSM for incidents, access, and catalog items. Use a software-request path for new systems and meaningful changes. The two doors can sit next to each other.
Isn’t a JSM form just intake with required fields?+
Required fields still create a work item. Completeness for software change is a reviewable story, not a populated ticket. If QA later opens the issue, you already lost the request.
What should employees click instead of the portal?+
A software-request path that collects the current situation, the people, the outcome, an owner, and constraints. Precision Foundry is built for that submission. The portal can link to it and still handle tickets.
How is this different from copying intake into a Jira backlog?+
Same failure, different Atlassian product. JSM starts the paraphrase at the portal. Jira Software starts it at the work item. In both cases the tester never sees the original request.
Where is the Precision Foundry vs Jira Service Management feature chart?+
On the comparison page. This article stays on the operational failure: what happens when a software ask is filed as a portal ticket, comment by comment, until QA tests the paraphrase.
Try Why Jira Service Management is the wrong software intake on one real request
Precision Foundry keeps this guide attached to the request so the template does not live in a forgotten doc.
Join the private alpha waitlist