IT Service Request Fulfilment Checklist Template

The request type and the fulfiller are recorded on the first task. The request type decides which tasks appear in Phases 3, 4 and 5.

• Log the request against its catalogue item — request type, requester, the date it is needed by and the item’s fulfilment target
• Confirm it is a service request, not an incident or a change — something broken goes to the incident queue, something outside the catalogue to change enablement
• Check the request form is complete — device name, licence edition, mailbox or group name, access level or delivery address, whatever the item asks for
• Check for a duplicate or an open request for the same thing — two tickets for one laptop end in two laptops
• Acknowledge the request with the catalogue target date — a date the requester can plan around, not “as soon as possible”

The approval route, approver and budget holder are recorded on the first task. Pre-approved items show neither approval. Each approval halts the checklist until it is recorded as Approved or Not approved.

• Check entitlement and record the approval route — the catalogue item says whether it is pre-approved; role, team and contract type decide who is entitled
• Check the licence or stock position before asking anyone to approve — an approval for an item nobody can supply is an approval for a wait
• Approver records the decision — the line manager, or the owner of the mailbox or application for access requests, records Approved or Not approved
• Budget holder approves the cost — cost centre and amount, for items outside the role’s standard allowance
• Tell the requester the outcome — a refusal goes back with the reason and the nearest item they are entitled to

The licence task appears only for software installs, the stock task only for equipment, and the group task only for access and permission changes. The change task stays visible for every request, because any of them can turn out to be non-standard.

• Find a free licence or reclaim an unused one — check the pool before buying; a seat unused for 90 days is a common reclaim rule
• Allocate a device from stock or raise the order — stock built to the current standard first; an order gets a purchase order and a delivery date the requester is told
• Identify the group that grants the access and its owner — access is given through a group the owner controls, not a one-off permission
• Agree a time with the requester when fulfilment needs them — installs that force a restart, a device handover, or a first sign-in to new access
• Raise a change record if the work falls outside the documented procedure — a server change, a new group or a new integration is not a standard request

One fulfilment task appears for the request type, between the procedure task and the record task that every request gets.

• Follow the catalogue item’s documented procedure — the written steps, not the version the fulfiller remembers
• Install the software from the approved package and assign the licence — through device management where possible, recorded against the person
• Add the requester to the group with the access level asked for — read, send as and full access to a mailbox are three different requests
• Prepare and hand over the device — built to the current standard, asset tag recorded against the person, delivered or collected
• Make the permission change and record the before and after — including access the person no longer needs in their new role
• Update the fulfilment record with what changed — licence, asset tag, group or permission, with the date

The device receipt task appears only for equipment requests.

• Ask the requester to confirm it works — they sign in, open it or use it; a request is fulfilled when the requester can use what they asked for
• Check the access granted is no wider than the request — the right mailbox with the right rights, not a broader group that was quicker to find
• Send a short note on how to use it and where to get help — including any licence terms or handling rules that come with it
• Record who received the device and the asset acknowledgement — the signature that makes the device recoverable when they leave
• Apply your rule when confirmation does not arrive — for example two reminders over three working days, then close as fulfilled but unconfirmed

These tasks give the quarterly catalogue review its data. The flag on the last task is what the review sorts by.

• Close the request with the fulfilment record — what was delivered, by whom, when and under which approval
• Record the fulfilment time against the catalogue target — with time spent waiting for approval kept separate from time spent working
• Record why a request was refused or could not be fulfilled — repeated refusals usually mean the catalogue describes entitlement wrongly
• Note any step in the procedure that was wrong or missing — fix it once in the procedure rather than working around it every time
• Flag the item for the catalogue review — a candidate to pre-approve, automate, change the form or retire