IT Service Request Process

A request asks for a known service or access. An incident reports that something is broken or degraded. The distinction matters because each path needs different urgency, information, approvals, and measurements. A new laptop request should not compete in the same queue as an office-wide outage without clear routing.

• Service request: new user, shared mailbox access, software installation, device order, distribution-list change
• Incident: account lockout, failed application, unavailable network, suspected phishing, lost device
• Security event: suspicious activity that may trigger the incident-response process
• Project request: work with material cost, risk, dependencies, or design effort beyond routine fulfilment

List the requests that occur repeatedly and define each one in plain language. A useful catalogue item states who can request it, required information, approval rules, expected fulfilment time, cost treatment, owner, dependencies, and completion evidence. Start with the ten highest-volume requests rather than documenting everything at once.

• New employee and role change
• Employee departure and access removal
• New device, replacement device, and accessory
• Software licence and application access
• Shared mailbox, group, folder, and SharePoint permission
• Guest, vendor, or contractor access
• Equipment move, return, disposal, or loan
• Standard report, integration, or data export

Give staff one obvious portal, form, or supported email address. Capture enough information to route and fulfil the work without a long exchange. Required fields can include the affected person, business reason, needed-by date, manager, location, device, application, data sensitivity, cost centre, and attachments. Avoid collecting secrets in the ticket.

• Use conditional questions so simple requests stay simple
• Generate a unique ticket number and confirmation
• Show status and expected next step to the requester
• Accept urgent incident reports through a documented emergency channel
• Convert chats and calls into tickets so the work and outcome are recorded

Approval is a control, not a ritual. The direct manager may approve cost and business need, the system owner may approve application access, the data owner may approve sensitive information, and IT may approve technical and security fit. Pre-authorize low-risk standard items to reduce delay.

• Define approval thresholds by request type and cost
• Do not allow a requester to approve their own privileged access
• Set an expiry date for temporary access
• Record the approver, time, scope, and evidence
• Escalate exceptions instead of silently bypassing the workflow

Assign an owner, perform the documented steps, record material changes, test the result, and ask the requester to verify where appropriate. Closure notes should say what changed, when it changed, who completed it, and any action the user must take. Repeatable fulfilment instructions belong in a maintained runbook.

• Use checklists for onboarding, offboarding, devices, and permissions
• Keep credentials and sensitive configuration outside ordinary ticket notes
• Link related requests, assets, users, and change records
• Reverse temporary changes on schedule
• Reopen or create an incident when the delivered service does not work

Useful measures include intake volume by type, approval wait time, fulfilment time, ageing, reopen rate, satisfaction, automation rate, and requests completed within the published target. Review patterns to remove recurring friction. Fast closure is not success if work is incomplete or users bypass the process.