Incident or Service Request? Getting the First Decision Right
NXT AIS, Inc. Editorial ·
Treat an unplanned service disruption or reduction in quality as an incident; treat a request for an agreed service, access or information through the appropriate service-request process. Start with what happened and what the user needs, not the label they selected. Urgency and authorization still need separate assessment.
Ask whether a service failed or something is being requested
Atlassian distinguishes service requests from unplanned service disruptions, and its product documentation separates ordinary incidents from major incidents. These definitions are useful starting points, not a reason to treat every incident as an emergency or every request as automatically approved. Atlassian: service request management versus incident management. Atlassian Support: work categories and incidents.
A short intake conversation should establish the expected service, what actually happened, the affected users and the business impact. The organization's service catalogue, priority rules and access policies then determine the handling path. The examples below are our editorial guidance rather than a prescribed vendor configuration.
Classify the situation, not just the wording
| Hypothetical report | Initial handling to investigate |
|---|---|
| A new employee needs their first application access | Service request: establish the approved access and required authorization. |
| An authorized team suddenly cannot open an application | Incident: investigate unexpected loss of the existing service. |
| A user asks for a report that the service normally provides | Service request: confirm the offering and fulfillment conditions. |
| A user reports missing access but their entitlement is unclear | Clarify expected access and context before deciding; do not grant access solely to close the ticket. |
A reported access problem can have more than one cause. A revoked entitlement, a forgotten password and a wider identity-service failure are not interchangeable. A provisional classification should help the team investigate rather than prevent correction when new evidence appears.
Keep priority separate from category
An incident affecting one low-impact function may need a different response from an outage affecting a critical team. A planned service request can also be time-sensitive. Assess impact and urgency through the established priority process rather than allowing a ticket type to set the response automatically.
Similarly, classification does not replace authorization. If incident recovery requires a controlled production change, retain the applicable change process. If fulfilling a request grants sensitive access, retain its approval requirements. Calling work routine does not make those boundaries disappear.
Improve the first response without making users experts
- Use plain-language intake choices and allow people to describe the problem.
- Confirm the affected service, expected behavior, actual symptoms and start time.
- Assign a triage owner who can correct category and explain the next step.
- Link related incident, request or change records when that helps continuity, rather than creating disconnected duplicates.
- Review repeat misrouting and missing information with the teams receiving the work.
The purpose of the first decision is to get the right work to the right owner with enough context to act. Measure whether the user reaches useful help, not merely whether every ticket carries a tidy label.
References & further reading
Company editorial prepared with AI assistance. Sources and technical checks do not constitute independent expert review.