An equipment request looks like the simplest kind of internal form. Somebody needs a second monitor, a headset, a laptop for a new starter, a projector for a Thursday workshop. Four fields and a submit button should cover it.
Then the item arrives, and the questions start. Which cost centre was that against. Who approved it, because the thread where the approval happened is in somebody's direct messages. Is the loan projector still with the person who borrowed it in March. And when a leaver hands back a laptop, whether the docking station that went with it was ever recorded as issued at all.
The form is not the hard part of equipment requests. Custody is. What follows is the field list, and the handling that turns a pile of submissions into a record of who asked, who approved and who is holding the item now.
The three things a request has to settle
What exactly is wanted. Free text produces "a monitor" and then a conversation about size, connector and stand. A fixed list of the items actually supplied, with the specification attached to each, removes that conversation entirely. It also reveals the second most useful thing about equipment requests: most of them are for one of about fifteen items.
Who approves the spend, and against what. Approval is the step that gets done informally and then cannot be found. A named approver and a cost centre on the record are what make the purchase defensible three months later, when finance asks about a line on a statement.
Who ends up holding the item. The requester is not always the holder. A manager requests a laptop for a new starter, a team lead requests a camera that lives in a shared cupboard, an office coordinator requests a monitor for whoever sits at desk fourteen. If the form only captures the requester, the custody record is wrong the day the item is delivered.
A form that answers those three, and keeps its answers somewhere readable, is worth more than a beautifully laid out document that gets filed after signature.
The fields that matter
The item, from a list
Build the list from what has actually been supplied over the past year. Laptop, monitor, dock, keyboard, mouse, headset, webcam, phone, phone case, adapter set, chair, desk riser, printer, projector, portable screen, software licence. Put the standard specification next to each option so nobody asks. Keep an other field, and treat a rising count of other answers as a sign that the list needs an addition rather than that requesters are being awkward.
Ask for quantity as a separate number field. Requests for five of something are a different approval conversation from requests for one, and a quantity buried in a text answer gets missed.
Why, in one line the approver can act on
Two options work better than an open box. Either a short list of reasons, which covers almost every case, or a required one line explanation. The list version: new starter, replacement for a fault, replacement at end of life, additional to what is already held, home working setup, one off for an event, returning from leave. The reason drives the approval route, because a replacement for a broken item usually needs no approval at all while an additional item does.
Whether this is a purchase, from stock, or a loan
This is the field most equipment forms leave out, and it changes everything downstream. A purchase needs budget approval and a lead time. An issue from stock needs a stock check and nothing else. A loan needs a return date and a condition note. One multiple choice question routes all three, and the follow up questions differ from there.
Cost centre, budget and approver
Cost centre as a fixed list. Approver as a name, defaulted from the requester's team where the tool allows it. An approximate cost where the requester has any basis for one, clearly marked as their estimate so nobody later reads it as a quote.
Delivery, timing and the holder
Where the item should go, when it is needed, what fixes that date, and who will hold it once delivered. The last one is a separate field from the requester and it is the field that keeps the asset list accurate. For loans, add the return date as a required field.
Acknowledgement on handover
For anything worth recording as an asset, a short acknowledgement that the item was received, in the condition described, and that the holder is responsible for it while they have it. This does not need a signature platform. A dated entry on the record, sent to the holder by email and kept with the request, covers the practical purpose.
The template, written out
Rebuild this in any form tool, with conditional questions where noted. Around sixteen questions is the ceiling, and most submissions will see fewer.
Requester
- Name. Short text. Required.
- Email. Email. Required.
- Team or department. Multiple choice. Required.
- Approving manager. Short text. Required.
What is needed
- Item. Multiple choice from the supplied list, with an other box. Required.
- Quantity. Number. Required.
- Specification or model, if a particular one is needed. Short text.
- Purchase, from stock, or a loan. Multiple choice. Required.
- Reason. Multiple choice: new starter, fault replacement, end of life replacement, additional, home working, event, other. Required.
- What is currently used for this, if anything. Short text.
Money
- Cost centre. Multiple choice. Required.
- Estimated cost, if known. Short text.
- Has the spend been discussed with the approver. Yes or no. Required.
Delivery and custody
- Who will hold the item. Short text. Required.
- Delivery location. Multiple choice: office, home address, site, collect in person. Required.
- Needed by. Date. Required.
- What fixes that date. Short text.
- Return date. Date. Required when the answer above is a loan.
Attachments
- Quote, link to the item, or a photo of the fault. File upload.
Recorded by the team, not shown to the requester
- Decision and approver, with the date.
- Order reference and supplier.
- Asset tag once issued.
- Date issued and date returned.
- Stage.
- Condition on return.
That last block is the asset record. It is also the reason a form on its own is not enough: five of those six fields are written after the request was submitted, by someone other than the requester, over a period of weeks.
Purchase, stock or loan, handled differently
One form, three routes. The routes differ in what has to happen and in how long the record stays open.
| Route | What has to happen | How long the record stays open | Most common failure |
|---|---|---|---|
| From stock | Check availability, issue, record the asset tag and holder | Days | Item handed over without the holder being recorded, so the asset list drifts |
| Purchase | Approve spend, order, receive, issue, record | Weeks | The requester hears nothing between approval and delivery, then asks three times |
| Loan | Issue, record the return date, chase, receive back, note condition | Until returned, which may be months | No return date on the record, so nothing ever chases it |
| Replacement | Issue the new item, and collect the old one | Days, plus disposal | The old item is never collected and shows as still issued |
Looked at this way, the form is a small part of the job. The three routes need a status that can be read at a glance, a date that can be filtered on, and an owner who is responsible for moving each request along. The handling side is what to check before choosing a tool: a stage per response that can be renamed, an owner, internal fields the requester never sees, and a reply that goes from the record itself.
Approval, and the threshold that avoids it
The fastest improvement available to most equipment processes is to stop requiring approval for things nobody would refuse. A broken keyboard does not need a manager's sign off. Neither does a replacement charger.
Set a stated figure below which any replacement or standard item is issued on request with no approval step, provided it comes from the supplied list and from stock. Above that figure, or for anything additional rather than replacing, route to the named approver. For anything over a second figure, route to whoever holds the budget as well.
Then set the two rules that keep it honest. Every request gets an answer within a stated number of working days, including the ones that are approved automatically, because silence is what drives people to buy things on personal cards and claim them back. And a refusal comes with a reason, because a refused request without a reason is resubmitted within the month.
Custody, which is the part that outlives the request
An equipment request is closed when the item is handed over. The asset record it created is open until the item comes back or is written off, and those are different lifetimes. Three practices keep the second one accurate without a dedicated asset system.
Record the holder, not the requester, at the point of issue. Along with the date and the asset tag. This single habit is the difference between a usable list and a historical archive of purchase requests.
Put the return date on loans and make something look at it. A filter on a date column is enough, checked once a week. Loans without a return date are the single largest source of missing equipment in small organisations, and the fix costs nothing.
Tie the leaver process to the same list. When somebody leaves, the question is what is issued to them, and the answer should be one filter rather than an afternoon of asking around. This is the point at which the discipline of recording the holder pays for itself several times over.
Teams that run equipment requests alongside other internal intake tend to settle on one arrangement for all of them, and the patterns look alike whether the incoming item is an equipment request, a help desk ticket or an application. One list with stages, one place the replies come from.
What two quarters of records show
Once a couple of hundred requests share the same form, the exported records answer questions that are otherwise guesswork.
Spend by team and by item tells you what the standard kit should actually be. Where the same item is requested forty times a year, buying a small stock of it is cheaper and faster than forty individual orders.
Replacement age by item type is the number that sets a refresh cycle. Laptops failing consistently at a certain age is an argument for planned replacement rather than reactive purchase, and the argument only works with dates behind it.
Time from request to delivery, split by route, shows where the delay sits. It is usually the approval step rather than the supplier, which is not what most people expect.
Loans not returned within thirty days of the stated date is a list worth generating monthly. It is short, it is specific, and it is the single report that recovers real money.
What to change first
Add two fields to whatever request route exists now: who will hold the item, and the return date for loans. They cost nothing and they are what make the record usable after delivery. Then give every request a stage and an owner so nobody has to ask where an order stands. If the current form cannot hold either, see what a request that carries its own stage looks like in a tool built for it, such as Halict.
Q1. What is the difference between an equipment request form and a purchase requisition?
An equipment request is the internal ask, and it may be met from stock with no purchase at all. A requisition is the instruction to buy, raised after approval, and it carries supplier, price and cost centre for finance. One form can feed both, provided the approval fields record the cost centre and the approver.
Q2. Does a small organisation need an asset register as well?
Not a separate one at first. If every request records the holder, the asset tag, the issue date and the return date, the request list is the register. A dedicated asset system earns its place when items are tracked through repairs, warranties and disposal.
Q3. Should equipment requests require manager approval every time?
No. Requiring approval for a replacement charger trains people to route around the process. Set a value threshold below which standard replacements are issued on request, and reserve approval for additional items and for spend above the threshold.
Q4. How do you keep track of borrowed equipment?
Make the return date a required field on any request marked as a loan, and check the overdue list weekly. Most losses happen because the item was never given a return date, not because anybody intended to keep it.
Q5. Who should own the equipment request queue?
One named person, with a deputy, and it does not have to be an IT role. What the role needs is the authority to issue from stock, to pass a request to the approver, and to record the holder at handover. Splitting those across three people is how requests stall.