IT Hardware Request & Procurement Process

What Is a Hardware Request?

A hardware request is the formal record that an employee needs a physical IT asset — a laptop, a monitor, a phone, a docking station, a replacement part — and that someone with budget authority has agreed to pay for it. It is the first stage of the hardware asset lifecycle, and it is the only stage where the asset does not yet exist. Everything downstream inherits the quality of what is captured here.

The distinction that matters most is between a request and an order. A request is a business statement of need, owned by the requester and their manager. An order is a commercial commitment to a supplier, owned by procurement. Collapsing the two — letting a manager email a supplier directly, or letting a helpdesk ticket become a purchase order without a cost-centre check — is where most unplanned hardware spend originates.

Procurement itself is the second stage of the asset lifecycle. If you are looking for which stage of the asset lifecycle includes the procurement of assets: request comes first, procurement second, then deployment, maintenance, and retirement.

The Request Workflow and Its Statuses

The request lifecycle status workflow is a small state machine. Keeping it small is the point — every extra status is another place a request can stall unobserved.

The stock check step is the one most organizations omit and the one that pays for itself fastest. Checking available stock before releasing a request to procurement is what stops the classic pattern of buying new laptops while identical machines sit in a cupboard. It also gives you a natural home for assets returned by leavers — see onboarding and offboarding for how those returns feed back into stock.

These statuses are request statuses, not asset statuses. They stop the moment the asset record is created. From that point the asset follows its own state machine, documented in the hardware asset data model. Keeping the two separate avoids the common mess where a device is somehow both "On Order" and "Deployed".

Authorisation: Who Approves What

Hardware request authorisation works best as two independent checks rather than one long approval chain. The first asks whether the need is legitimate; the second asks whether the money exists. They are different questions and usually different people.

• Line manager — business need. Confirms the person exists, the role justifies the equipment, and the timing is real. Fast, and should be the only approval for standard catalogue items under the threshold.
• Cost-centre owner — budget. Confirms the charge lands on a budget that can absorb it. Required whenever the charge is not the requester's own cost centre.
• IT standards — exception only. Triggered when the request is off-catalogue: a non-standard model, unusual specification, or a device class the organization does not normally issue.
• Security — exception only. Triggered by devices that will hold regulated data, connect to restricted networks, or leave the country.
• Finance — threshold only. Triggered above the capitalization threshold, because the purchase creates a capital record rather than an expense. The depreciation guide covers where that line sits and why.

A standard laptop for a confirmed new starter should clear with one approval in under a day. If your process routes that through four approvers, people will route around it, and the assets they acquire that way are the ones that never reach the register.

The Procurement Process, Stage by Stage

Once a request is released, the IT asset procurement process runs through six stages. Each produces a document, and each document is evidence an auditor will later ask for — see the audit methodology guide for how these are sampled.

1. Specification. Turn the request into a purchasable configuration: exact model, memory, storage, warranty term, accessories. Standard catalogue items skip straight through; bespoke requests stop here for IT standards review.
2. Sourcing and quotation. Obtain quotes from approved suppliers, or draw from an existing framework or contract price. Record which supplier and which price, because the price paid becomes the asset's capital value.
3. Purchase order. The commercial commitment. The PO number is the single most useful field to carry all the way into the asset record — it is what lets finance tie a device on someone's desk back to a line on an invoice.
4. Order and lead time tracking. Supplier confirms, gives an expected date, and the requester is told. Most request-process complaints are not about speed but about silence during this stage.
5. Goods receipt. Physical arrival. Serial numbers are captured against the PO, quantities are checked, and discrepancies are raised before the invoice is approved. This is the moment the asset record is created and the asset tag is applied.
6. Invoice matching and capitalization. Three-way match between PO, goods receipt, and invoice. The asset is capitalized or expensed, and depreciation begins according to policy.

Serial-number capture at goods receipt is the step with the highest downstream value and the highest skip rate. A device received without its serial recorded against the PO is a device that will not reconcile in the first audit, and it is far cheaper to scan it once on the loading dock than to hunt for it later.

Lease purchases follow the same six stages but end differently: the asset is not owned, the end-of-term return date becomes a tracked field, and the lease maturity date drives the refresh decision instead of the depreciation schedule. Mixing leased and owned devices in one register without a clear ownership flag is a reliable way to be surprised by a return penalty.

Replacement and Change Requests

Not every hardware request is for a new person. The hardware replacement process for existing end users has different triggers and deserves a different route.

The distinction between a planned refresh and an emergency replacement is a budget distinction as much as a process one. Organizations that let every replacement arrive as an unplanned request pay a premium on every unit and lose the ability to forecast. Moving that volume into a scheduled cycle is the core argument of a hardware refresh policy.

An asset change request — a memory upgrade, a drive swap, a reassignment to a different user or cost centre — is not a procurement event but still needs a record, because it changes the asset's value, its custodian, or both. Route these through the same form with a different type, and let them update the existing asset record rather than create a new one.

Return Requests and Stock Reuse

A return hardware request is the mirror image of a fulfilment: a device coming back into IT custody from a leaver, a role change, or a project ending. It closes a custody chain, and it is the cheapest source of hardware you have.

1. Raise the return. Triggered automatically by an offboarding event or manually for a change of role. Records which asset, which user, and the expected return date.
2. Recover the device. Physical handover, or a shipping kit for remote staff. The asset moves to In Transit so it is never invisible.
3. Receive and triage. On arrival, check condition and remaining useful life. Devices with meaningful life left go to refurbishment; the rest go to disposal.
4. Wipe and rebuild. Sanitize the drive, reimage, and return to stock as Available. A device is not back in stock until it is genuinely reissuable.
5. Or dispose. Devices past their useful life move to Pending Disposal and follow the ITAD procedure, ending in a certificate of destruction.

The stock check in the request workflow is what makes this loop pay. Without it, refurbished devices accumulate, age out, and get disposed of having never been reissued — all the cost of recovery with none of the benefit.

Metrics for Request and Procurement

• Request-to-fulfilment time. Calendar days from submission to the user having the device. Track the median and the 90th percentile; the tail is what people complain about.
• Approval cycle time. Time spent waiting for approvers, separated from supplier lead time. If approvals exceed lead time, the problem is internal.
• Stock fulfilment rate. Percentage of requests satisfied from existing stock rather than new purchase. Rising is good; it means the return loop is working.
• Off-catalogue rate. Percentage of requests for non-standard configurations. High rates inflate spare-parts holdings and support cost.
• Unplanned replacement share. Replacements arriving as emergencies rather than scheduled refresh. The number a refresh policy is designed to reduce.
• PO-to-asset-record completeness. Percentage of received devices whose asset record carries a valid PO number and serial. Target 100%; anything less becomes an audit finding.

Common Mistakes

• No stock check before purchase. New devices bought while equivalents sit in storage. The single most expensive omission in the request process.
• Serial numbers captured at deployment, not receipt. Creates a window where devices are in the building but not in the register — the origin of most ghost assets.
• Approval chains longer than the lead time. Drives shadow purchasing, which produces assets with no PO, no tag, and no record.
• Request statuses and asset statuses in the same field. Produces impossible states and breaks every report built on status.
• Returns with no destination. Devices recovered from leavers with no triage step pile up in a room until they are worth nothing.
• Leased assets flagged the same as owned. Missed return dates and end-of-lease penalties that no one forecast.

Next Steps