Request Fulfilment

Request fulfilment is the procedure for handling user requests for standard IT services, access, information, or equipment. Unlike incidents (which restore disrupted service) or changes (which modify the production environment), service requests follow pre-defined paths with known outcomes and pre-approved delivery methods. This procedure covers the complete lifecycle from request submission through fulfilment verification, enabling you to process requests consistently while maintaining appropriate controls.

Prerequisites

Before processing service requests, confirm these conditions are met:

You need access to the ITSM platform with permissions to view, assign, and update request records. For requests requiring procurement, you need visibility into the procurement workflow status. For requests involving access provisioning, you need either direct provisioning capability or an established handoff to identity management teams.

Gather the service catalogue showing requestable items, the approval matrix defining who authorises each request type, and contact details for fulfilment teams responsible for each service category. If your organisation uses automated fulfilment for standard requests, confirm the automation endpoints are operational by submitting a test request to a non-production workflow.

Procedure

Receiving and validating requests

When a request arrives through any channel (self-service portal, email, phone, chat, or walk-up), your first task is capturing it in the ITSM system with sufficient information to enable fulfilment without further clarification.

1. Create a request record in your ITSM tool. If the request arrived through the self-service portal, the record exists; locate it by the confirmation number provided to the requester. For requests from other channels, create a new record manually:

   Request ID: [Auto-generated]
   Requester: [Name and employee ID]
   Contact method: [Email/Phone/Portal]
   Requested item: [Catalogue item name]
   Requested for: [Same as requester OR different beneficiary]
   Business justification: [Requester's stated reason]
   Urgency: [Low/Medium/High]
   Received timestamp: [Current date-time]

2. Validate the request contains minimum required information. Each catalogue item defines mandatory fields; a request for software installation requires the software name, version, device identifier, and business justification. A request for access requires the system name, access level, and duration. If mandatory fields are missing, return to the requester within 2 hours with specific questions:

   Subject: Additional information needed - Request [REQ0012345]

   Your request for [item] requires the following information before we can proceed:
   - [Specific missing field 1]
   - [Specific missing field 2]

   Please reply to this message or update your request at [portal URL].

3. Verify the requester is entitled to request the item. The service catalogue defines eligibility for each item: some items are available to all staff, others restricted by department, role, or location. Check the requester’s attributes against the eligibility criteria. If ineligible, reject the request with an explanation:

   Status: Rejected
   Resolution code: Not entitled
   Resolution notes: Software [X] is restricted to Finance department.
   Requester department: Operations. Contact your manager to request
   an exception through the IT governance process.

4. Confirm the request is not a duplicate of an existing open request. Search for the requester’s name combined with the catalogue item; if an identical request exists from the same requester within the past 30 days, contact the requester to determine whether this is a duplicate or a distinct need.

Categorising and routing requests

Accurate categorisation determines routing, approval requirements, and fulfilment method. The request category identifies the service domain (hardware, software, access, information), while the catalogue item identifies the specific deliverable.

1. Assign the request to the appropriate category based on the requested item. Use the catalogue item’s pre-defined category; do not reclassify based on your interpretation:

   +-------------------------------------------------------------------+
   |                    REQUEST CATEGORISATION                         |
   +-------------------------------------------------------------------+
   |                                                                   |
   |  Hardware                Software              Access             |
   |  +----------------+     +----------------+    +----------------+  |
   |  | New equipment  |     | Installation   |    | System access  |  |
   |  | Replacement    |     | Upgrade        |    | File share     |  |
   |  | Peripheral     |     | Licence        |    | Distribution   |  |
   |  | Mobile device  |     | Removal        |    | Mailbox        |  |
   |  +----------------+     +----------------+    +----------------+  |
   |                                                                   |
   |  Information            Account              Service              |
   |  +----------------+     +----------------+    +----------------+  |
   |  | Report         |     | Password reset |    | Training       |  |
   |  | Data extract   |     | New account    |    | Consultation   |  |
   |  | Documentation  |     | Account unlock |    | Support        |  |
   |  +----------------+     +----------------+    +----------------+  |
   +-------------------------------------------------------------------+

Figure 1: Request categorisation taxonomy

2. Determine the fulfilment path. Each catalogue item specifies whether it follows automated fulfilment, standard manual fulfilment, or requires assessment. The fulfilment model field on the catalogue item indicates the path:

   Fulfilment model	Description	Typical items
   Automated	System completes without human intervention	Password reset, group membership, software from approved list
   Standard	Defined procedure, no assessment needed	Hardware from standard catalogue, access to standard systems
   Assessment	Requires evaluation before approval	Non-standard software, elevated privileges, exceptions

3. Route the request to the appropriate queue. Automated requests route to the automation engine. Standard requests route to the fulfilment team for that category. Assessment requests route to the technical assessor queue. Set the assignment group based on catalogue item configuration:

   Assignment group: [From catalogue item]
   Assigned to: [Leave blank for queue-based assignment]
   State: Awaiting Approval OR In Progress (if no approval required)

Processing approvals

Service requests require approval when they involve cost, access to sensitive resources, or deviation from standard offerings. The approval workflow depends on the request type, value, and requester’s organisational position.

1. Identify required approvers from the approval matrix. The matrix specifies approval requirements by catalogue item and thresholds:

+-------------------------------------------------------------+
|                  APPROVAL ROUTING WORKFLOW                  |
+-------------------------------------------------------------+
|                                                             |
|   1. INTAKE                                                 |
|      Service Request Received                               |
|             |                                               |
|             v                                               |
|      +--------------+                                       |
|      | PRE-APPROVED?| Check Catalogue Policy                |
|      +--------------+                                       |
|             |                                               |
|      +------+------+                                        |
|      |             |                                        |
|     YES            NO                                       |
|      |             |                                        |
|      v             v                                        |
|  +--------+   +--------------+                              |
|  | AUTO-  |   |  COST CHECK  |                              |
|  | APPROVE|   +--------------+                              |
|  +--------+          |                                      |
|      |        +------+------+                               |
|      |        |             |                               |
|      |      < £500       >= £500                            |
|      |        |             |                               |
|      |        v             v                               |
|      |   +---------+   +------------+                       |
|      |   | MANAGER |   |  MANAGER   |                       |
|      |   | APPROVAL|   |     +      |                       |
|      |   +---------+   | BUDGET HLD |                       |
|      |        |        +------------+                       |
|      |        |             |                               |
|      +--------+-------------+                               |
|               |                                             |
|               v                                             |
|        +--------------+                                     |
|        |  FULFILMENT  |                                     |
|        +--------------+                                     |
|                                                             |
+-------------------------------------------------------------+

Figure 2: Approval routing decision tree

2. Initiate the approval workflow. For requests requiring single approval, send directly to the approver. For multi-level approval, approvals proceed sequentially:

   Approval request sent to: [Approver name]
   Approval type: [Manager/Budget holder/Technical/Security]
   Approval due by: [Current date + SLA hours]

   Email to approver:
   Subject: Approval required - [REQ0012345] [Catalogue item]

   [Requester name] has requested [catalogue item].
   Estimated cost: [Amount or "No cost"]
   Business justification: [From request]

   Approve: [Approval link]
   Reject: [Rejection link]
   View details: [Request link]

   This request will auto-escalate if not actioned within [X] hours.

3. Monitor approval progress. Approvals have defined SLAs (24 hours for standard requests, 4 hours for urgent requests). If approval is not received within 80% of the SLA, send a reminder. At 100% of SLA, escalate to the approver’s manager:

   Reminder (at 80% SLA):
   Subject: Reminder - Approval pending - [REQ0012345]

   Escalation (at 100% SLA):
   Subject: Escalated - Approval overdue - [REQ0012345]
   To: [Approver's manager]
   CC: [Original approver]

4. Process the approval decision. If approved, update the request state and proceed to fulfilment. If rejected, notify the requester with the rejection reason and close the request:

   Approved:
   State: Approved
   Approved by: [Approver]
   Approved timestamp: [Date-time]
   Next state: In Progress

   Rejected:
   State: Rejected
   Rejected by: [Approver]
   Rejection reason: [Approver's comments]
   Resolution code: Rejected by approver

Fulfilling requests

Fulfilment is the execution of the work required to deliver the requested item. The fulfilment method depends on the catalogue item’s configuration and your organisation’s automation capability.

Automated fulfilment

Automated fulfilment applies to standard requests where the delivery can be completed by systems without human intervention. Common examples include password resets, software installation from approved catalogues, and membership in standard access groups.

1. Verify the request meets automation criteria. The automation engine validates:

   • Requester identity confirmed
   • All approvals obtained (if required)
   • Requested item in automation-eligible catalogue
   • No conflicting conditions (e.g., user already has access)

2. Trigger the automation workflow. The ITSM platform invokes the appropriate automation endpoint:

   Automation endpoint: /api/v1/fulfil/software-install
   Payload:
   {
     "request_id": "REQ0012345",
     "catalogue_item": "SW-OFFICE365",
     "target_user": "jane.smith@example.org",
     "target_device": "LAPTOP-JS-001",
     "parameters": {
       "licence_type": "E3",
       "apps": ["Word", "Excel", "Outlook", "Teams"]
     }
   }

3. Monitor automation completion. The automation engine updates the request with progress and outcome:

   Automation status: Completed
   Completion timestamp: [Date-time]
   Result: Software installed successfully
   Verification: User can launch applications from Start menu

4. Handle automation failures. If automation fails, the request routes to manual fulfilment with the error details:

   Automation status: Failed
   Error code: DEVICE_OFFLINE
   Error message: Target device not reachable
   Fallback action: Route to manual fulfilment queue

Manual fulfilment

Manual fulfilment applies to requests requiring human action: physical equipment delivery, complex configuration, or items not covered by automation.

1. Accept the request from your assignment queue. Review the request details and confirm you have the skills and access to fulfil it. If not, reassign to the appropriate team within 30 minutes:

   State: In Progress
   Assigned to: [Your name]
   Work start timestamp: [Current date-time]

2. Execute the fulfilment procedure. Each catalogue item has an associated procedure document or knowledge article. Follow the documented steps exactly. For a laptop deployment request:

   Fulfilment steps for: New Laptop Deployment

   a. Retrieve device from inventory
      Asset tag: [Record from inventory]
      Serial number: [Record from device]

   b. Image device with standard build
      Build version: WIN11-STD-2024.03
      Duration: 45 minutes

   c. Configure user profile
      Join to domain: example.org
      Primary user: [Requester username]

   d. Install additional software per request
      [List specific applications]

   e. Register in asset management
      Update owner: [Requester]
      Update location: [Requester's office]

   f. Prepare for delivery
      Include: Power adapter, quick start guide
      Delivery method: [Desk drop/Collection/Shipping]

3. Document work completed in the request record. Include specific details that enable verification and support future troubleshooting:

   Work notes:
   [Timestamp] Device LAPTOP-001234 retrieved from stock
   [Timestamp] Imaging completed - build WIN11-STD-2024.03
   [Timestamp] Domain join successful - computer object in OU=Laptops
   [Timestamp] Installed: VS Code 1.85, Python 3.12, Git 2.43
   [Timestamp] Asset record updated - owner Jane Smith
   [Timestamp] Device delivered to desk 3-401

4. Coordinate with other teams when fulfilment spans multiple groups. Use the request’s task feature to create and assign sub-tasks:

   Parent request: REQ0012345

   Task 1: Prepare hardware
   Assignment: Desktop Team
   Status: Complete

   Task 2: Configure network access
   Assignment: Network Team
   Status: Complete

   Task 3: Grant application access
   Assignment: Applications Team
   Status: In Progress

Communicating with requesters

Requesters receive automated notifications at state transitions: request received, pending approval, approved, in progress, completed. Beyond automated notifications, proactive communication maintains satisfaction and manages expectations.

Send proactive updates when:

• Fulfilment will take longer than the standard SLA (notify before SLA breach)
• You need additional information or clarification
• Dependencies on other teams create delays
• The requested item is unavailable or backordered

Proactive update template:

Subject: Update on your request [REQ0012345]

Hello [Requester name],

Your request for [catalogue item] is in progress.

Current status: [Specific status]
Expected completion: [Date, or explanation of delay]
[If delayed]: We are waiting for [specific dependency].
We will update you within [timeframe].

If you have questions, reply to this message or call the
service desk at [number].

Reference: REQ0012345

For requests with extended fulfilment times (over 5 working days), provide weekly updates even if no status change has occurred.

Closing and verifying requests

Request closure confirms the requester received what they asked for and the delivery meets their needs.

1. Verify fulfilment completion. Confirm all tasks are complete and the delivered item matches the request:

   Verification checklist:
   [ ] All fulfilment tasks complete
   [ ] Delivered item matches catalogue item specification
   [ ] Requester can access/use the delivered item
   [ ] Asset records updated (if applicable)
   [ ] Licence allocated (if applicable)

2. Confirm with the requester. Send a fulfilment notification requesting confirmation:

   Subject: Your request [REQ0012345] has been completed

   Hello [Requester name],

   Your request for [catalogue item] is complete.

   [Specific details of what was delivered]

   Please verify you have received this and it meets your needs.
   If you have any issues, reply to this message within 5 working days.

   If we don't hear from you, we will close this request automatically.

   Reference: REQ0012345

3. Process requester response. If the requester confirms satisfaction, close the request. If the requester reports issues, reopen and address:

   Requester confirms:
   State: Closed
   Resolution code: Fulfilled
   Closure timestamp: [Date-time]
   Satisfaction: [If survey enabled, record result]

   Requester reports issue:
   State: In Progress
   Reopened timestamp: [Date-time]
   Reopen reason: [Requester's feedback]

4. Auto-close if no response. Requests without requester response auto-close after the defined period (typically 5 working days):

   State: Closed
   Resolution code: Fulfilled - auto-closed
   Closure notes: No response from requester after fulfilment
   notification sent [date]. Auto-closed per policy.

Request models and fulfilment paths

Different request types follow different paths through the fulfilment process. Understanding these models helps you route requests correctly and set appropriate expectations. +-------------------------------------------------------------+ | END-TO-END SERVICE FULFILMENT | +-------------------------------------------------------------+ | | | 1. INTAKE | | Service Request Received | | | | | v | | +--------------+ | | | CATALOGUE | Identify Item Type & Attributes | | | LOOKUP | | | +--------------+ | | | | | +------+--------------+--------------+ | | | | | | | v v v | | [ STANDARD-AUTO ] [ STANDARD-MAN ] [ NON-STANDARD ] | | | | | | | v v v | | +------------+ +------------+ +------------+ | | | PRE- | | APPROVAL | | TECHNICAL | | | | APPROVED? | | ROUTING | | ASSESSMENT | | | +------------+ +------------+ +------------+ | | | | | | | +—+---+ +------+------+ | | | | | | | | | | YES NO < £500 >= £500 | | | | | | | | | | v v v v v | | +----+ +------+ +--------+ +--------+ +--------+ | | |AUTO| |COST | | MANAGER| | MGR + | | CUSTOM | | | |APPV| |CHECK | | APPV | | BUDGET | | WORKFL | | | +----+ +------+ +--------+ +--------+ +--------+ | | | | | | | | | | +----------+-------------+ | | | | | | | | v v v | | +------------+ +------------+ +------------+ | | | AUTOMATION | | MANUAL | | FULFILMENT | | | | ENGINE | | FULFILMENT | | WORKFLOW | | | +------------+ +------------+ +------------+ | | | | | | | +----------+----------+--------------+ | | | | | v | | +--------------+ | | | VERIFICATION | | | | & CLOSURE | | | +--------------+ | | | +-------------------------------------------------------------+

Figure 3: Fulfilment path selection based on catalogue item type

Standard automated requests include password resets (average fulfilment: 2 minutes), software from the approved catalogue (average fulfilment: 15 minutes), and standard group membership (average fulfilment: 5 minutes). These requests bypass manual queues entirely unless automation fails.

Standard manual requests include hardware from the standard catalogue (average fulfilment: 3 working days), office moves (average fulfilment: 2 working days), and new user provisioning (average fulfilment: 1 working day). These follow defined procedures with predictable outcomes.

Non-standard requests include software not in the approved catalogue (assessment: 5 working days), hardware not in the standard catalogue (assessment: 10 working days), and exception requests (assessment: varies). These require technical assessment before approval and may result in rejection if the organisation cannot support the requested item.

Worked example: software installation request

A user submits a request for Visual Studio Code installation on their laptop.

Request details:

Request ID: REQ0067891
Requester: Sarah Chen (employee ID: E12345)
Catalogue item: Software Installation - Developer Tools
Requested item: Visual Studio Code
Version: Latest stable
Target device: LAPTOP-SC-001
Business justification: Required for Python development project

Processing sequence:

1. Validation (elapsed time: 0-5 minutes)

   • Requester verified as active employee
   • VS Code is on approved software list
   • Target device is assigned to requester
   • All mandatory fields populated

2. Categorisation and routing

   • Category: Software > Installation
   • Fulfilment model: Automated
   • Approval required: No (no cost, approved software)
   • Routed to: Automation engine

3. Automated fulfilment (elapsed time: 5-20 minutes)

   • Automation validates device online
   • Installation package deployed via software distribution
   • Installation verified complete
   • Application appears in user’s Start menu

4. Closure (elapsed time: 20-25 minutes)

   • Automation updates request: Fulfilled
   • Notification sent to requester
   • Request closed with resolution code: Fulfilled - Automated

Total elapsed time: 25 minutes

Worked example: non-standard hardware request

A user submits a request for a graphics tablet not in the standard catalogue.

Request details:

Request ID: REQ0067892
Requester: Tom Bradley (employee ID: E23456)
Catalogue item: Hardware Request - Non-Standard
Requested item: Wacom Intuos Pro (Medium)
Business justification: Required for design work on communications materials
Estimated cost: £350

Processing sequence:

1. Validation (elapsed time: 0-2 hours)

   • Requester verified as active employee
   • Item not in standard catalogue (flagged for assessment)
   • Business justification reviewed (design role confirmed)

2. Technical assessment (elapsed time: 2-48 hours)

   • Desktop team assesses compatibility: Compatible with standard build
   • Driver availability: Vendor-supplied, supported on Windows 11
   • Security review: No elevated privileges required
   • Support implications: Desktop team can support

3. Approval (elapsed time: 48-72 hours)

   • Manager approval: Required (non-standard equipment)
   • Budget holder approval: Required (cost over £250 threshold)
   • IT approval: Required (non-standard)
   • All approvals obtained

4. Procurement (elapsed time: 72 hours - 10 days)

   • Purchase order raised
   • Item ordered from approved supplier
   • Delivery received and booked into inventory

5. Fulfilment (elapsed time: 10-11 days)

   • Device configured with standard drivers
   • Delivered to requester’s desk
   • Basic functionality verified with requester

6. Closure (elapsed time: 11-12 days)

   • Confirmation requested from user
   • Request closed after user confirms working

Total elapsed time: 12 working days

Verification

After completing a batch of requests, verify the process is functioning correctly:

Check request completion accuracy by reviewing a sample of closed requests:

-- Sample verification query for completed requests
SELECT
  request_id,
  catalogue_item,
  resolution_code,
  DATEDIFF(hour, created, closed) as hours_to_close,
  satisfaction_score
FROM requests
WHERE closed_date >= DATEADD(day, -7, GETDATE())
  AND state = 'Closed'
ORDER BY hours_to_close DESC
LIMIT 20;

Expected results:

• Resolution code is “Fulfilled” for at least 95% of requests
• Hours to close is within SLA for at least 90% of requests
• Satisfaction score (if collected) averages 4.0 or higher on 5-point scale

Verify automation is functioning by checking the automation success rate:

SELECT
  DATE(created) as date,
  COUNT(*) as total_automated,
  SUM(CASE WHEN automation_status = 'Completed' THEN 1 ELSE 0 END) as successful,
  SUM(CASE WHEN automation_status = 'Failed' THEN 1 ELSE 0 END) as failed
FROM requests
WHERE fulfilment_model = 'Automated'
  AND created >= DATEADD(day, -7, GETDATE())
GROUP BY DATE(created);

Expected results:

• Automation success rate above 95%
• Failed automations have documented error codes
• Failed automations routed to manual fulfilment within 30 minutes

Verify approvals are processing correctly:

SELECT
  approval_type,
  AVG(DATEDIFF(hour, sent, actioned)) as avg_hours_to_action,
  COUNT(CASE WHEN escalated = 1 THEN 1 END) as escalated_count,
  COUNT(*) as total_approvals
FROM approvals
WHERE sent >= DATEADD(day, -7, GETDATE())
GROUP BY approval_type;

Expected results:

• Average hours to action is within 80% of approval SLA
• Escalated count is less than 10% of total approvals
• No approvals pending beyond SLA without escalation

Troubleshooting

See also

• Service Catalogue Management
• Service Desk Operations
• User Onboarding
• Incident Management
• Knowledge Management