A JSM Request Form Makes a Promise Before Anyone Answers It

An employee needs access to an application. The help portal asks which resolver team should receive the request, which approval group applies, and what technical problem caused it. The employee doesn't know. They select plausible options, complete every mandatory field, and submit.

The support team then asks what they were trying to do in the first place.

This hypothetical form has collected answers without collecting the information that would let anyone help. Worse, the guesses now look like facts: they occupy official fields in an official system. A person who simply needed access has been asked to diagnose the organization before it will listen.

In Jira Service Management, a request type is the kind of help someone chooses in the portal. That choice starts a conversation. Its label and questions should let the customer explain a need, rather than test whether they already understand the service team's internal arrangements. [1][2]

The question has to fit what the employee knows

The employee can usually name the application, describe the work they need to do, and explain when they need to start. They may not know which group grants permission or which team maintains it. Asking for those details earlier doesn't make them available earlier.

Consider these illustrative alternatives for the same access request:

The second column doesn't remove the need for routing, permissions, or diagnosis. It gives the service better raw material for doing that work. A resolver can distinguish a first-time access request from a broken existing account without asking the employee to choose an internal technical category.

That distinction also helps with misleading data. A mandatory field can turn “I don't know” into an apparently reliable classification. If routing and reporting trust that value, the form has made the record easier to process while making its meaning less trustworthy.

A shorter form can still create a longer conversation

Removing every awkward question would be the opposite mistake. Suppose the team needs to know the application for every request, but the portal asks only “How can we help?” The initial submission is effortless; the next message is predictably “Which application?” Work now waits for an answer that the employee could reasonably have supplied at the start.

I would judge the form by the whole exchange, not by how quickly someone can press Submit. A question earns its place when its answer helps the receiving team begin and the requester can supply it accurately. Information already available elsewhere in the service may not need to be asked again. A diagnosis that emerges during investigation can wait until investigation.

There is a practical way to find the difference: compare what the form collects but nobody uses with what the team repeatedly has to ask afterward. The first group suggests unnecessary burden. The second may reveal a missing question, missing system context, or an unclear handoff. They don't all call for more fields.

The portal should explain the service, not reproduce its configuration

An employee looking for “Access to the reporting application” may encounter several nearly identical labels based on internal team names. Even a well-worded form won't help much if it sits behind a choice they cannot recognize.

The customer-facing request type and the underlying work type have different audiences. Several recognizable services can share an internal workflow; the portal doesn't need a separate lifecycle for every label. Conversely, one apparently simple request may involve conditions that the service must explain before it can promise fulfillment. [2]

The distinction matters when a form is redesigned. Renaming the option can make it easier to find, but it cannot create a service the team has not agreed to provide. The employee should understand what they are requesting, what information is needed from them, and what happens after submission.

A useful trial therefore follows an imperfect request beyond the screen. Does someone who chooses the wrong category get redirected without repeating everything? Does the resolver receive enough context to act? Can the customer understand a request for more information? These moments reveal whether the new wording has improved the exchange.

The employee at the start didn't need to become better at guessing the support organization. They needed a way to describe their work. A good form lets them do that—and leaves the service team with a request it can actually fulfill.