Service Request Management

4 min read

Handle predictable requests fast, consistently, and without turning support into a dispatcher queue.

Service Request Management

Service Request Management in ITSMote exists to remove chaos from predictable work.

If people keep asking the same things in Slack, email, or DMs, and delivery speed depends on who you ping - you do not have a request process.

This practice is not about control. It is about making common requests boring, fast, and safe.

Definition

A service request is a predefined, low-risk, repeatable request for something already supported by the service.

Examples:
- access requests
- configuration changes with known patterns
- environment provisioning
- report exports
- routine operational actions

If the outcome and risk are known in advance, it is a request - not an incident or change.

Not a service request (usually)

  • unplanned outages or degradation (incident)
  • exploratory “can you look into…”
  • new functionality or product changes
  • high-risk or one-off actions

Rule:

If execution requires investigation or risk assessment, it is not a request.

Goal

  • Fast and predictable fulfillment
  • Minimal back-and-forth
  • Clear ownership and expectations
  • No hidden work in chats

Relationship to other practices

  • Requests do not fix broken services - incidents do
  • Requests do not introduce risk - changes do
  • Requests do not analyze causes - problems do

Misclassification is the fastest way to break ITSM.

Request catalog

Requests must be explicitly defined to exist.

Each request type must include:
- clear description
- eligibility rules
- required inputs
- expected outcome
- fulfillment time target (SLA or SLO)
- automation level (manual / partial / full)

If it is not in the catalog, it defaults to triage.

Roles

Request Owner (mandatory)

Accountable for the request type:

The Request Owner owns the request type (catalog item), not every individual ticket.

  • defines the request
  • owns fulfillment steps
  • keeps automation and docs up to date
  • reviews performance

Not a dispatcher role.

Fulfillers

People or systems executing the request.

Lifecycle (ITSMote)

1) Submit

Goal: collect everything needed upfront.

Rules:
- request must be submitted via the defined entry point
- forms beat free text
- missing data blocks execution

Do:
- user selects request type
- user provides required inputs
- system auto-assigns owner

Status:
- Submitted

2) Validate

Goal: confirm this is a real request and is eligible.

Checklist:
- request type matches the ask
- requester meets eligibility rules
- inputs are complete and valid

Outcomes:
- Accepted
- Rejected (with reason and redirection)

Status:
- Accepted / Rejected

3) Fulfill

Goal: deliver the request safely and consistently.

Rules:
- follow the defined steps
- no scope creep
- deviations require re-triage

Do:
- execute fulfillment
- record execution time
- note exceptions if any

Status:
- In Progress

4) Complete

Goal: confirm delivery.

Do:
- verify outcome
- notify requester
- attach evidence if applicable

Status:
- Completed

5) Close

Goal: lock the record.

Close when:
- request is completed or rejected
- outcome is documented
- SLA status is recorded

Final status:
- Closed

Approvals (minimal)

Approvals exist only if they reduce risk.

Examples:
- access to sensitive systems
- cost-impacting requests
- privileged actions

Rules:
- single approver
- async
- auto-approve when possible

If approval becomes a bottleneck, the request definition is wrong.

Automation-first

Requests are the best automation candidates.

Prioritize automation when:
- volume is high
- steps are deterministic
- human judgment is minimal

Automation is not optional scale - it is the point.

Metrics (minimum viable)

If you do not measure this, users will route around it.

Track monthly:

  • Request volume by type
  • Fulfillment time vs target
  • % requests auto-fulfilled
  • Rejection rate
  • Backlog age

Documentation standard

Requests must be understandable without tribal knowledge.

Minimum request definition fields:

  • What the request does
  • Who can request it
  • What is required
  • How long it takes
  • What can go wrong

Rule:

If users ask questions after submitting, the request is poorly designed.

Minimal template

Service request definition (copy/paste)

  • Request name:
  • Description:
  • Eligible requesters:
  • Required inputs:
  • Fulfillment steps:
  • Approval (if any):
  • Target time:
  • Automation level:
  • Owner: