The Equipment Request Workflow From Form to Fulfilment

Tuesday, 10:40, at Ashgrove Housing. Dev runs a desk of three and in the last twenty minutes has received four requests for equipment by four different routes. A chat message from a housing officer: "any chance of a second monitor?" An e-mail from a team leader: "new starter on Monday, needs the usual." A walk-up from finance holding a mouse whose scroll wheel has given up, and a ticket, an actual ticket, from a surveyor asking for "a laptop like Priya's". Dev has the only key to the stock cupboard in his pocket and no idea what "the usual" means for that team. He strongly suspects that Priya's laptop is the one the organisation stopped buying last spring. None of the four requests is unreasonable. All four are about to be handled differently, and two of them will not be written down anywhere.

An equipment request is a ticket asking the desk to supply a physical thing. That could be a monitor, a dock, a keyboard, a mouse, a headset, a cable, a charger, a webcam, or a whole kit for a new starter. It is not a broken thing being mended, which is a fault, and it is not a program being installed, which is a software request. The equipment request workflow is the fixed path every such request takes from the ask to the thing on the desk. It has one form at the front and a short list of standard items in the middle. Approval happens only where a decision is genuinely needed. A note at the end says what went to whom. This article is part of our Peripherals & Equipment Requests series. The series covers the standards, the stock, the docks and cables, home-office kit, and the friction that builds up around all of it.

It covers what an equipment request is and what it is not, the form and its five questions, and the standard catalogue with its two lanes. Next come approval only for the non-standard, fulfilment from stock or by order, and the note that records what went to whom. Then it covers the turnaround promise and closing the ticket. It finishes with a short war story and the equipment request form to copy.

What an Equipment Request Is, and Its Three Neighbours

The first job of the workflow is to recognise the request when it arrives, because equipment requests have three neighbours that look similar and go down different paths. A mouse with a dead scroll wheel is a fault until the technician decides it is not worth mending. At that point it becomes an equipment request for a replacement. The fault side of that line belongs to The Diagnostic Order, which owns laptops and desktops and the question of whether to swap, repair or retire. A request for "the design program" is a software request and belongs to its own workflow. A request for a new starter's kit is an onboarding ticket with an equipment task inside it. What is left, once those three are sent on their way, is the plain request: a person needs a thing, and the thing exists to be had.

Plain requests arrive looking like anything but. "My monitor is too small" is a request for a bigger monitor. "I keep getting neck ache" is a request that needs the ergonomic path, which the second article in this series handles kindly. "Can I have whatever Jess has" is a request for a specific item the requester cannot name. The triager's job is to translate each of them into the one sentence the form needs: "this person needs this item for this reason by this date". The triager must resist diagnosing on the way. A request is not a puzzle. It is an order, with a yes or no attached, and most of the time the answer is yes from a shelf.

Recognising a request also means recognising who is really asking. "The usual for a new starter" is a request from a team leader on behalf of someone who does not yet have an account. The ticket must say so. The thing will be issued to the starter and recorded against the starter, not the team leader. A manager asking for three monitors for the team is three requests with three recipients. Get the recipient right at intake and the record at the end takes care of itself. Get it wrong and the stock sheet will insist, for a year, that the team leader personally owns four mice.

The Form: Five Questions and No More

Every equipment request, whatever door it came through, is captured on one form with five questions. The form exists so that the triager asks nothing twice. The five start with what item, picked from a list. Next is for whom, which is a person's name, not a team. Then comes why, in one line. Next is where it should go, which is a desk number, a site, or a home address already on record. Last is by when, with a sensible default. That is the whole form. A sixth question is a question the desk has to answer itself before it can fulfil anything. And a seventh is the point at which people stop filling it in and send a chat message instead.

The "what" question is a pick-list, not a free text box. And the list is the standard catalogue, with one last entry that says "something not on this list". The pick-list does three things at once. It tells the requester what the organisation issues and saves the triager from decoding "the big screen". It also decides the lane the request goes down before anyone has read it. The desk's tool may have a form per department, as QuerySolv and many tools do. In that case, an equipment form with its own mailbox behind it puts e-mail and form requests in the same queue with the same fields. The chat message and the walk-up then get typed into the same form by the technician who took them. One door is a luxury. One form behind every door is the minimum.

The "why" line deserves a word, because requesters resent it and triagers skip it. It is not there to interrogate anyone. A second monitor "for comparing two drawings side by side" and a second monitor "because the person opposite has one" are both reasonable things to write. The first will be fulfilled from stock and the second may be too, depending on the standard. The line is there so that the person deciding the non-standard requests has something to decide on. It is also there so that the pattern across fifty requests can be read later. "Why" is the question that turns a pile of tickets into evidence. Twelve people asking for a second monitor "for the new case system" is a finding, and a form without the line will never produce it.

The form should carry two fields quietly, filled by the desk rather than the requester. One is the asset tag of the item being replaced, if there is one. The other is the cost code, if the organisation runs on them. The replaced item matters because it has to go somewhere, back to stock, to the test bin, or to the retirement pile. And the ticket is where that is written. The cost code matters only where finance insists. The honest advice is to ask finance once whether they want it on every mouse, and to be surprised how often the answer is no.

The Standard Catalogue and the Two Lanes

The standard catalogue is the short list of items the organisation has decided it issues. It includes one or two choices of monitor, one dock, one keyboard, one or two mice, and one or two headsets. It also includes the cables and chargers that go with them, and whatever else the desk has agreed to keep on a shelf. It is the pick-list on the form and the contents of the stock cupboard. And the two must match, or one of them is lying. How to choose the items on it, and how to end the argument about which monitor, is the subject of Equipment Standards That End the Monitor Debate. The broader idea of a catalogue of what the desk offers lives in The Service Catalog Idea. This article needs only the fact that the list exists and that it draws a line.

The line creates two lanes. A request for a catalogue item, for a person who does not already have one, goes down the standard lane. It needs no approval and is fulfilled from stock, usually the same or next working day. A request for anything else goes down the non-standard lane, which has a decision in it. That includes a second of something, an item not on the list, or a larger quantity than one person needs. The lane is decided by the pick-list at the moment the form is submitted. That means the triager does not decide it, the requester's manager does not decide it, and nobody has to argue. The form decides, and the form was agreed in advance by people who were not in a hurry.

The standard lane is where most of the volume should be, and if it is not, something upstream is wrong. On a desk where half the equipment requests need a decision, one of three things is happening. The catalogue is too short for the jobs people do. Or the stock is empty and every request becomes an order. Or someone has decided that every mouse needs a manager's signature. The share of requests that need nobody's approval is the first number worth watching in this workflow. And a healthy desk sees most of its requests walk straight past the approver's desk without stopping. The approver, if asked, will not miss them.

Approval Only for the Non-Standard

Approval exists to take a decision that the catalogue could not take in advance, and that is the only reason it exists. The decision is usually one of three. Is this cost justified (the manager's question)? Will this work with what the person already has (the desk's question)? Or does this change the standard for everyone (the question for whoever owns the standard, which is often the desk lead)? Each question has one owner, and a request needs the answer from the owner of the question it raises, not from everyone in the chain. A request for a second standard monitor raises only the manager's question. A request for a monitor not on the list raises the desk's and possibly the standard's. A request for a standard headset, for someone who has none, raises no question at all, and must not wait for anyone to say so.

Most small-team help desks have no approval engine, and the convention that works without one is the approver's reply on the ticket. The technician puts the ticket into a waiting state and sends the approver a short message. The message has the item, the person, the one-line reason and a date by which silence will be read as a no. The approver replies yes or no. The reply lands on the ticket, the ticket leaves the waiting state, and the record is complete. The convention in full, including what to do when the approver is on leave, is in Approvals Without a Workflow Engine. Here it is enough to say that the chase is part of the workflow, not an embarrassment. An approval with no deadline is a ticket with no end.

The deadline needs saying once, in the message, and then keeping. Five working days is a reasonable wait on most desks: long enough for a manager to get back from leave, short enough that the requester has not bought their own. When the deadline passes with no answer, the ticket closes as "no decision received". The requester is then told who did not decide, and the request can be raised again when the approver is back. That outcome is what causes the fuss, and it is what makes approvers answer. Approvers who are told their silence is a no become remarkably prompt.

Fulfilment From Stock or by Order

Fulfilment is the part where the thing moves. It has two versions, from the shelf and from a supplier, which differ mostly in how long the requester waits. From stock, the workflow is a walk. The technician takes the item from the cupboard and writes the issue on the stock sheet. They carry it to the desk or leave it at the collection point, and write the note on the ticket. The walk should be the same day for anything on the shelf. And the stock exists so that it can be. How to keep the shelf stocked, and the three numbers per item that make it so, is the subject of Peripheral Stock Management for a Small Desk.

By order, the workflow is a wait, and the desk's job is to make the wait visible. The ticket goes into a waiting-on-vendor state with the order reference and the supplier's promised date on it. The requester is told the date and told again if it moves. The ticket is looked at on the promised date whether or not the parcel arrived. The waiting state is not a cupboard to put the ticket in and forget; it is a list the desk reads every morning. A desk that cannot say, by lunchtime, which equipment orders are overdue has a waiting state that is doing the work of a bin.

Handover is the moment both versions share, and it is where the workflow most often goes quiet. The item arrives, the technician is busy, and the box sits by the printer for two days. And the requester, who was told "it's in", goes looking. Decide where handover happens and write it on the ticket. The item could be delivered to the desk by a technician or collected from a shelf at the help desk. Or it could be shipped to the home address on record with the tracking reference on the ticket. Collection is cheapest and works for a mouse. Delivery is right for a monitor that needs setting up. Shipping is its own small process, covered in the home-office article in this series. Whichever it is, the ticket says which, and the requester never has to ask where the thing is.

The Note That Records What Went to Whom

The note at the end of the ticket is the most valuable thing the workflow produces. And it is the part skipped most often, because the requester is happy and the technician has nine other tickets. The note says what was issued, with its model and its serial or asset tag. It names the recipient and gives the date and the technician. It also says what happened to the item it replaced, if any. Five facts, one line each, thirty seconds to write. Without them the organisation owns equipment it cannot find, and the next request from the same person cannot be answered with "you already have one". With them, the ticket history is the inventory, or near enough for a desk of three.

Most small-team help desks have no asset module. And the practical substitute is an asset tag field on the equipment form and a plain inventory sheet. That way, the tag typed into the ticket at issue can be found again at the stock count, at offboarding and at the next request. The method, including the naming convention and the lookup at first touch, is in Linking Devices Without an Asset System. The point for this workflow is simpler. The note on the ticket and the row on the sheet are written at the same moment, by the same hand. Otherwise, one of them will be wrong by Friday.

The replaced item's fate is the fact most often left blank, and it is the one that empties cupboards. A mouse with a dead wheel goes in the bin, and the note says so. A monitor swapped for a bigger one goes back to stock, tested, and the note says so and the stock sheet gains a unit. A dock that "stopped working" goes in the test bin, not back on the shelf, and the note says that too. The next technician to open the cupboard cannot tell a tested dock from an untested one by looking. Every item the desk takes back has three destinations, stock, test, or retire, and the ticket names one. The cupboard that nobody writes down becomes, within a year, a cupboard nobody trusts.

The Turnaround Promise

The workflow should promise a turnaround, in working days, by lane. And the promise should be one the desk can keep on an ordinary week rather than a heroic one. At Ashgrove, once Dev had written the workflow down, the promise was set. Standard items from stock would arrive by the end of the next working day. Approved non-standard items from stock would arrive the working day after approval. Ordered items would arrive on the supplier's promised date plus one working day for handover. Starter kits would be ready the working day before the start date, provided the request arrived ten working days ahead. Those are one desk's figures and other desks will set their own. The shape is what matters. Each lane has a number. Each number is counted from a moment the requester can see, and nothing is promised that depends on a supplier keeping a promise of its own.

The promise is also a filter for the request that should not wait. A broken headset for someone who takes calls all day is a fault with a request inside it. And the request is urgent in the plain sense: the person cannot work. The workflow should let the technician on the fault issue the replacement from stock without a form. The technician should then write the form and mark the ticket so the stock sheet still gets its row. Urgency is a reason to skip the queue, not the record. The desk's service-level targets may be set per priority, as they are in many tools. In that case, the equipment request sits at the ordinary priority and the fault that stops someone working sits higher. That is the only distinction the promise needs.

Closing the Ticket

The ticket closes when the requester has the thing and it works, not when the thing left the cupboard. For a mouse the two moments are the same. For a monitor on a new dock they are not. The resolving message should say what was issued and ask the requester to reply if anything is missing. "Your second monitor is on your desk, connected to the dock on the left-hand port; the old one has gone back to stock. If the picture is not right when you sign in, reply to this and we will come back." Short, specific, and it gives the requester a thing to do if the thing is wrong. The art of that message, and of not closing in silence, belongs to Closing Tickets Properly.

The reply that says "it arrived but the cable is the wrong one" should reopen the same ticket rather than start a new one. The history of the request, the approval and the issue note are all on the first ticket. The wrong cable is part of the same story. In QuerySolv a requester's reply reopens a resolved ticket from any channel, and many tools behave the same way. Where yours does not, the technician links the new ticket to the old one by hand so that the record stays whole. A request that took three tickets to fulfil is not three requests. It is one request and two mistakes, and the record should show which.

A Short War Story: The Monitor That Went to Three People at Redbrook Engineering

Redbrook Engineering ran equipment requests out of a cupboard with no sheet. Felix, a draughtsman, was given a second monitor one afternoon by a technician who was passing, no ticket, no note. Two months later a stock count came up two monitors short. A project manager asked for the monitor she had "been promised in March". Nobody on the desk of two could say who had either. The desk lead, Hana, spent a day and a half walking the floor with a clipboard counting monitors under desks. She found both and found a third bought the previous quarter to replace one of the two she was now looking at. Redbrook had purchased three monitors it already owned, and spent about twelve hours of technician time discovering it. The note that records what went to whom is the whole workflow, Hana told the desk afterwards; everything else is walking.

The Equipment Request Form

The form below is the one Dev built after the Tuesday with four doors. It is designed to be filled in by the requester on the portal. Or it can be typed in by a technician who took the request by chat, phone or walk-up. Either way it is the same five questions. Section A is the requester's part. Section B is the desk's, filled at triage and at issue. It is where the lane, the decision, the tag and the fate of the replaced item live. The pick-list in A is your standard catalogue, so write your own items in. The last entry on it is always "something not on this list", and that entry is the one that goes to an approver.

EQUIPMENT REQUEST FORM — ONE PAGE
Ticket: ____________   Date raised: ____________   Channel: form / e-mail / chat / phone / walk-up

A. THE REQUEST (requester)
   Item needed (pick one):
     [ ] Monitor, standard          [ ] Dock, standard
     [ ] Keyboard, standard         [ ] Mouse, standard wired / wireless
     [ ] Headset, standard          [ ] Laptop charger
     [ ] Cable: laptop-to-dock / video / network
     [ ] Starter kit for role: ______________________
     [ ] Something not on this list: ______________________
   For whom (one person's name): ______________________
   Why, in one line: ____________________________________________
   Deliver to:  desk ______ / site ______ / home address on record
   Needed by (default: next working day for stock items): ____________

B. THE DESK (filled at triage and at issue)
   Lane:  standard / non-standard / assessed / onboarding / fault-first
   Replaces an existing item?  no / yes, tag: ______________
   Decision needed?  none / cost (manager) / fit (desk) / standard (owner)
   Decision requested from: ______________  on: ________  answer by: ________
   Decision: approved / declined / no decision received   on: ________
   Fulfilled from:  stock / order ref ______________  promised date: ________
   Handover:  delivered to desk / collected / shipped, tracking: ______________

   ISSUE NOTE (one line each)
   Issued: item ______________  model ______________  tag/serial ______________
   To: ______________   On: ________   By: ______________
   Replaced item went to:  stock / test bin / retired   (tag: ______________)
   Stock sheet updated: [ ]    Requester confirmed working: [ ]

Dev typed the four Tuesday requests into the form that afternoon, which took about eight minutes in total. The second monitor was standard and went out from stock on Wednesday morning. "The usual" turned out to be the housing officer kit from the role profile, which the team leader confirmed in one line. The mouse was replaced on the spot and the form filled in afterwards, as the fault-first lane allows. The surveyor who wanted a laptop like Priya's was offered the current standard, which was better, and took it. Four requests, four lanes, one record. The key to the cupboard now hangs on a hook where all three technicians can reach it. Dev describes that as the biggest process improvement of the year.

Frequently Asked Questions