Who Signs Off Equipment Spend, and at What Threshold

TL;DR

• Most companies have an equipment approval workflow that exists only as habit, and habits cannot be delegated or covered during leave.
• The cost of an unwritten one is not overspend. It is three days of delay per request and a new starter without a laptop.
• Four thresholds cover almost every case: standard spec, non-standard spec, above a value limit, and anything recurring.
• Approval should be about exceptions, not about every purchase. A standard laptop for an approved hire needs no approval at all.
• The single highest-return change is a published standard spec that is pre-approved by default.
• Write down who decides when the decider is away, because that gap is where requests sit for a week.

The Laptop That Waited Nine Days for a Yes Nobody Owned

The request went in on a Monday. A new designer starting in two weeks needed a machine with more memory than the standard build, which is an entirely ordinary request and the reason the standard build has a documented exception path. Except it did not.

It went to the hiring manager, who approved it and forwarded it to IT. IT said spend above the usual needed finance sign-off. Finance asked who the budget holder was. The budget holder was on leave. Her deputy had not been told she was covering equipment decisions, because nobody had written down that equipment decisions were a thing she might need to cover. On day nine somebody senior enough to stop asking simply said buy it.

Nobody behaved unreasonably. Each person asked a sensible question. The nine days came from the absence of a written answer to four questions that come up every time: what is pre-approved, who approves an exception, above what value does it change, and who decides when that person is away.

Recommended Tools

Best tools for HR Operations

B BambooHR HR management system R Rippling HR & IT automation W Workday Enterprise HRIS

View all recommended tools

The real issue is not that approval takes too long. It is that nobody can say what the process is, so every request rediscovers it.

What an Equipment Approval Workflow Is Actually For

Worth being precise, because most are designed to control spend and the spend was never the problem.

It is for exceptions, not for purchases. A standard laptop for a hire who has already been approved through headcount is not a new spending decision. It was approved when the role was approved. Routing it through a second approval adds delay and catches nothing.

It is for the things that genuinely vary. A non-standard spec, an unusually expensive item, a purchase for somebody who is not an employee, a recurring cost rather than a one-off. Those are real decisions with real trade-offs.

It is for making the default fast. The measure of a good workflow is what proportion of requests need no human decision at all. Above about 80 per cent, and the exceptions get proper attention because there are few of them.

So the design question is not who should approve equipment. It is what should not require approval, and that list should be as long as you can defend.

When You Don't Need This Written Down

Under about 30 people. Everybody knows who decides and the decider is reachable. Writing a workflow at that size is process for its own sake.

One standard build, no exceptions ever. If everybody gets the same laptop and nobody asks for anything different, the workflow is a purchase order.

Equipment is bought once a year in a batch. Then this is a procurement exercise rather than a workflow, and it needs a budget conversation rather than an approval chain.

Somebody already owns it clearly and is never away. Rare, and it works until they take annual leave, at which point you need the written version anyway.

What People Actually Need to Know

What can I just order? The single most useful thing a workflow can publish. If a hiring manager can see that the standard build for an engineer needs no approval, most requests stop being requests.

Who do I ask for anything else? One name or one role, not a chain. Chains are where days go.

How long should it take? A stated service level, even a loose one. Without it nobody knows when to chase, so they either chase immediately or wait indefinitely.

What happens if that person is away? The question that caused the nine-day delay above. Almost never documented.

What will I be asked? If people know an exception request needs a reason and a cost comparison, they provide both the first time, and the decision happens in one pass rather than three.

The Four Thresholds That Cover Almost Everything

Threshold one: standard spec, approved headcount. No approval. Order it. This should cover the large majority of equipment requests in any company with a defined build.

Threshold two: non-standard spec within a value band. One approver, usually the hiring manager or function lead, deciding whether the role justifies the difference. A designer needing more memory is this case, and it should take an hour.

Threshold three: above a value limit. A second approver, usually finance or a budget holder. Set the limit high enough that it fires rarely. A limit set too low turns every laptop into a finance decision and trains people to route around the process.

Threshold four: recurring cost or non-employee. Anything that creates an ongoing commitment, or equipment for a contractor where ownership and return terms need deciding. Different question, usually different approver, and worth separating because the decision is about terms rather than money.

How to Choose: Five Questions Before You Design Anything

What proportion of requests are genuinely standard? Count a quarter of them. If 85 per cent are a standard build for an approved role, your workflow should approve none of those and you have just removed most of your delay.

What is your real value limit? Not the one in the finance policy written when the company was twenty people. A limit that fires on an ordinary laptop is a limit set wrong, and it produces expense-claim purchases.

Who is the single approver for an exception? One role. If you cannot name one, that is the finding.

Who covers them? Name the deputy explicitly and tell the deputy. This is the cheapest fix on this page and the most commonly missing.

What is the fallback if nothing happens? An escalation after a stated number of days, to a named person. Without it, a stalled request has no route forward except somebody losing patience.

Writing the Standard Spec, Which Does Most of the Work

Everything above depends on having a published standard build, and this is where the real return sits.

Define by role, not by person. Engineering, design, sales, operations. Three or four builds covers most companies. Defining by person produces negotiation; defining by role produces a decision somebody made once.

Publish the actual specification. Model, memory, storage. Vague descriptions invite questions, and every question is a delay.

State what is included beyond the laptop. Monitor, dock, keyboard, headset. Most of the back-and-forth in equipment requests is about peripherals rather than computers, and an itemised standard removes it.

Review it twice a year on a date. Specs go stale, and a stale standard produces exceptions, which is how an exception process becomes the main process. We have written about device spend per role, which is the companion decision about what each build should cost.

Pre-approve it explicitly. The words matter. A published spec that is not stated as pre-approved will still get forwarded to somebody for a yes.

The Deputy Problem

This deserves its own treatment because it causes more delay than any other single gap and takes ten minutes to fix.

Approval authority is usually held by a person rather than a role, and people take leave. When the holder is away, requests either wait or get approved by somebody acting without clear authority, which is worse because it undermines the process for everybody who followed it.

What to do: for each approval point, name a deputy, tell them, and state a value ceiling for their authority if that makes the delegation easier to grant. A deputy who can approve up to a stated amount without escalation covers almost every real case.

Put it where the requester can see it. A delegation nobody knows about does not prevent delay, because the requester still routes to the absent person and waits. The published workflow should name both.

Handle the long absences differently. Parental leave or a sabbatical is not covered by a holiday deputy arrangement, and the right move is to reassign the authority properly for the duration rather than to extend a stopgap for five months.

What the Process Costs When It Works

Worth quantifying, because the business case for writing this down is about time rather than money.

Take a company making forty equipment requests a quarter. If 85 per cent are standard and pre-approved, six need a decision. At a same-day turnaround that is a trivial administrative load on one person.

Now take the same forty with no published standard. Every request needs somebody to decide whether it is reasonable, which means forty decisions, each with a round of questions. At thirty minutes of combined attention per request that is twenty hours a quarter spread across people whose time is expensive, and a new starter waiting somewhere in the middle of it.

The saving is not the licence fee of any tool. It is the difference between six decisions and forty, and that difference comes entirely from publishing a standard and saying it is pre-approved.

Checking Stock Before Approving a Purchase

The step almost no workflow includes, and the one that saves the most money: asking whether you already own a suitable machine before approving a new one.

Most companies above a hundred people hold more spare equipment than they think. Devices returned by leavers, machines from roles that changed, kit bought for starters who withdrew. It sits somewhere, nobody has a count, and every new request is treated as a purchase.

Make the stock check a step, not a suggestion. Before any purchase approval, somebody answers one question: do we have a device matching this build that is available and wiped. If the register cannot answer that in a minute, the register is the problem rather than the workflow.

Define what counts as available. A returned laptop is not available until it has been wiped and confirmed working. Treating unverified returns as stock produces a reissue that fails on day one, which costs more goodwill than a new purchase costs money.

Set an age limit for reissue. A machine three years into a four-year life is not a good answer for a new starter, even though it is free. Publishing the limit prevents the argument, and it should match whatever refresh cycle you already operate.

Count it monthly. Spare stock is only useful if somebody knows it exists at the moment a decision is being made, which means a current figure rather than an annual stocktake.

The reason this belongs in the approval workflow rather than beside it is behavioural. If the stock check happens after approval, the purchase is already authorised and nobody revisits it. Placed before, it changes the decision roughly as often as you would expect from the size of your spare pool, and it is the only step in this entire process that reduces spend rather than controlling it.

Where This Sits Against Headcount Approval

The two processes are frequently confused and the confusion is the source of a specific, repeated argument.

Headcount approval decides whether the role exists. It carries a budget that should already include the cost of equipping the person, because a role without a laptop is not a role.

Equipment approval decides only the exceptions to the standard. It should not re-examine whether the hire is justified, and when it does, two things go wrong at once: the decision takes longer, and the hiring manager correctly feels the same question is being asked twice.

So the clean boundary is this. If the role is approved, the standard build is approved with it. The equipment workflow exists for specification exceptions, unusual value and non-employee cases. Nothing more.

The case that breaks the boundary is a role approved months earlier at an assumed equipment cost that has since changed, or a role approved in one market and filled in another with different pricing. Those are genuine re-decisions and they are rare enough to handle individually. Designing the whole workflow around them is how a standard purchase ends up needing finance sign-off.

What to do: state the equipment allowance at the point of headcount approval, by role band, and treat that as the authorisation. Then the equipment workflow has one clear job and the duplicate-question argument disappears. We have covered the allowance side in device spend per role, and the ownership question in who owns the device budget.

Measuring Your Current Equipment Approval Workflow

You cannot improve this without a baseline, and the baseline takes an afternoon to produce because the data is sitting in your ticket system or your inbox.

Take the last twenty equipment requests. For each one, record four timestamps: when it was raised, when the first human responded, when the final approval landed, and when the device actually arrived with the person.

Compute three intervals. Raised to first response. First response to approved. Approved to delivered. Those three numbers tell you completely different stories and teams routinely attack the wrong one.

The pattern most teams find is surprising. Approval is rarely the biggest interval. First response is, because requests arrive somewhere nobody is formally watching, and they sit for two days before anybody picks them up. That is a queue-ownership problem rather than an approval problem, and no amount of threshold design fixes it.

Then count the exception rate. Of those twenty, how many were a standard build for an approved role. If the figure is high and they all went through a decision anyway, you have quantified the waste and the remedy is a published pre-approved standard.

Keep the twenty-request sample. Re-run it a quarter after you change anything, because an equipment approval workflow that feels faster and measures the same has not actually improved, and the only way to know is to have the before number written down.

What the Request Form Should Ask

Most of the back-and-forth in equipment requests comes from incomplete first submissions, and that is a form design problem rather than a people problem.

Who is this for, and have they been approved as a hire? The second half matters, because it determines whether this is a spending decision at all. A request that cannot answer it should go back to headcount rather than to equipment.

Which standard build applies? Offer the published builds as options rather than asking for a free-text specification. Most requesters will pick one, which routes them straight to pre-approved.

If none applies, what specifically differs and why? Two fields: the deviation and the reason. Without the reason the approver has to ask, and that round trip is a day.

When do they start? Determines urgency, and lets whoever handles fulfilment work out whether the sanctioned route can make it. A request with a start date in eight days and a three-week supply chain needs a different answer, not a faster approval.

Where are they? Country at minimum. The honest answer in some markets is that the standard build is not available and the request becomes a different conversation.

Who holds the budget? Not to create an approval step, but so that the one case needing finance has the information already attached.

Six fields. The temptation is to add more, and every additional field reduces completion quality rather than improving decisions. If a field would not change an outcome, leave it out.

Regional and Multi-Entity Approval

Once you employ through more than one entity, a single approval chain stops working, and the failure is usually discovered by a manager in the newest market.

Spend authority is usually entity-bound. A budget holder in one entity frequently cannot authorise spend in another, for reasons that are about accounting rather than trust. If your workflow names one finance approver globally, requests from a new entity will stall while somebody works out whether that person can actually approve them.

Standards may not be purchasable everywhere. A published build that assumes a particular model and keyboard layout will be unavailable or expensive in some markets, which generates exceptions that are not really exceptions. The better design states the standard by capability with a local-equivalent clause rather than by exact model.

Local rules may constrain the answer. What a company can require regarding equipment, deductions or returns varies by jurisdiction and by circumstance. This is not something a workflow can resolve centrally, and the right behaviour is to flag it for local advice rather than to apply one answer everywhere.

What to do: keep one global workflow shape and allow two local variations: who the entity-level approver is, and what the local equivalent build is. Everything else stays identical, so a manager moving between regions recognises the process.

And name somebody for the first request in a new market, because that one always takes longest. Treating the first hire in a country as a known special case, with a named owner, prevents the two-week discovery exercise that otherwise happens.

Reporting on It

A workflow nobody reports on drifts back to habit within two quarters, and the reporting is three numbers rather than a dashboard.

Share of requests needing no approval. Your pre-approval rate. If it falls, either the standard has gone stale or people have stopped trusting it, and both are worth knowing early.

Median days from raised to delivered. One number, median rather than mean so a single stuck request does not distort it.

Count of requests older than your service level. The queue that needs attention this week, and the figure that keeps first-response time honest.

Show them monthly to one named person. Not a committee. A figure reviewed by one accountable person stays healthy; a figure in a deck nobody reads drifts.

Two things are worth deliberately not reporting. Total equipment spend, because it belongs in a budget conversation rather than a process one and mixing them makes the process look like a cost-control mechanism. And approval counts by approver, which invites people to optimise for approving quickly rather than correctly.

Where the Equipment Comes From, Once Approved

Approval is only half the delay. The other half is the time between a yes and a working laptop, and that depends on your purchasing route.

A sanctioned route that takes three weeks will be routed around by any manager with a start date in ten days, and the result is an expense-claim purchase that cannot auto-enrol and never enters the asset register. We covered that failure in equipping a first hire in a new market, and the compliance consequence in equipment compliance evidence.

So the approval workflow and the fulfilment route have to be designed together. A fast approval feeding a slow supply chain produces the same outcome as a slow approval: somebody buys their own.

RemoAsset is one option for the fulfilment half, and disclosure matters here: RemoAsset is owned by the same people who publish this site. It handles buying, registering, shipping and later retrieving devices, which shortens the gap between approval and a working machine, and means the asset record is created by the fulfilment rather than afterwards. Where it struggles, stated plainly: pricing is quote-based and requires a demo, so it cannot be compared against alternatives on cost without a call; and it is a newer platform with a smaller footprint than the legacy global resellers, which matters most if your hires are in unusual markets. It does not solve approval at all, which is the subject of this article, so the workflow still has to exist.

The Decision Table

Rolling It Out Without Anybody Noticing

A new equipment approval workflow fails on adoption rather than design, and the adoption problem is specific: the people who need it are managers who make one equipment request a year and will not read a process document.

Put it where the request starts, not in a policy. Whatever form or channel people use to ask for equipment should carry the answer at the point of asking. A workflow published on an intranet page is a workflow nobody will find, for the reasons we covered in HR intranet or answering layer.

Tell them what they no longer need to do. The message that lands is not that there is a new process. It is that a standard laptop for an approved hire now needs no approval at all. Lead with the removal rather than the structure.

Brief the approvers separately and first. They need to know what they are now responsible for, what their value ceiling is, and who their deputy is. Three sentences each, in writing, so the first exception request does not generate a conversation about authority.

Run the first ten requests manually and watch. Not to check compliance, but to see where people get stuck. Every real workflow has one step that is obvious to its author and confusing to everybody else, and ten requests will find it.

Then stop mentioning it. A process that needs continual reminding is a process that does not fit how people work. If the pre-approved standard genuinely covers most requests, the workflow becomes invisible, which is the goal.

One more adoption note worth keeping. The single most common reason a published equipment approval workflow gets ignored is that somebody senior bypasses it once, visibly, and the exception becomes the precedent. If the person who owns the process is also the person most likely to short-circuit it, that is worth naming before launch rather than after.

What Nobody Writes Down and Should

Who approves the approver's own equipment. Sounds trivial, causes awkwardness, and the answer should be their manager rather than themselves.

What happens to a request when the hire does not start. Equipment ordered for somebody who withdrew needs a documented destination rather than a cupboard.

Whether a replacement for a broken device needs approval. Usually it should not, and treating it as a new purchase is how people work around a broken laptop for a fortnight.

What counts as an upgrade versus a replacement. The distinction decides which threshold applies and is the most common source of argument.

Who can approve retrospectively. There will be emergencies. Having a named person who can bless a purchase after the fact, with a record, is better than pretending it never happens, and it keeps the exception visible rather than buried in somebody's expense claim three weeks later.

The Emergency Path, Which You Will Need

Every workflow needs a documented way to go fast, because otherwise the way to go fast is to ignore the workflow.

Name who can authorise out of band. One person, or two for timezone coverage. Their authority should be explicit and reasonably broad, because a narrow emergency authority produces a second escalation inside the emergency.

Require a record rather than a form. The point of the emergency path is speed, so it should not have a process. What it should have is an obligation to write down afterwards what was bought, for whom and why, within a stated window. That record is what keeps the path from quietly becoming the normal route.

Review the records monthly. Not to challenge individual decisions, but to spot the pattern. Three emergencies in a quarter for the same reason is a signal that the standard process is too slow for a case that recurs, and the fix is to bring that case into the normal path rather than to keep handling it as an exception.

Set an expiry on what the emergency produced. A laptop bought urgently through an unsanctioned route cannot auto-enrol and may never have entered the asset register properly. Marking it for replacement at the next refresh, with a date, stops a temporary measure persisting for four years.

Teams without a documented emergency path do not have fewer emergencies. They have the same number, handled invisibly, with no record of what was bought or by whom. That is strictly worse than a fast path with an obligation attached, and it is the version that surfaces during an audit.

What Getting This Wrong Costs

The expensive outcome is not overspend. It is that people stop using the process.

A workflow that takes nine days teaches managers to buy on expenses, and once that habit exists it is very hard to reverse, because the unofficial route genuinely works better from their point of view. Every device bought that way is one that cannot enrol automatically, does not appear in the asset register, and carries an ambiguous ownership question if that person leaves. The approval process designed to maintain control produces the opposite.

The second cost is a new starter without a laptop on day one, which is the single most visible failure a people function can have. It gets attributed to IT, or to HR, or to procurement, and it is almost always attributable to an approval question nobody had written an answer to.

And the third is quieter. An unwritten workflow cannot be delegated, so it concentrates in whoever currently holds it, and it leaves with them. The next person rebuilds it from scratch, badly, and the nine-day request happens again.

So the question is not who should sign off equipment spend. It is how much of your equipment spend needs signing off at all, and whether you have published the answer.

When You're Ready to Write It

One page, four thresholds, and the names. That is the whole artefact and it takes an afternoon.

Start with the pre-approved standard, because it removes most of the volume and therefore most of the delay. Publish the actual specification by role, state plainly that it needs no approval for an approved hire, and put a review date on it.

Then name a single approver for each remaining threshold, name their deputy, tell the deputy, and publish both. Add an escalation after a stated number of days so a stalled request has somewhere to go.

And check the fulfilment side before you congratulate yourself. A one-hour approval feeding a three-week supply chain has not solved the problem that managers were actually working around.

A last word on why this is worth an afternoon when it looks like bureaucracy. Nothing in this article adds a control. Every recommendation removes one: pre-approve the standard, raise the value limit, stop re-asking the headcount question, check stock before buying, name a deputy so nothing waits. The net effect of writing an equipment approval workflow down properly is fewer decisions, taken faster, by people who know it is their job. The companies that end up with nine-day requests did not design a heavy process. They designed no process, and a vacuum fills with caution, because in the absence of a written answer every person in the chain does the safe thing and asks somebody else. That is the mechanism, and it is why the document is short and the saving is large.

So write the one page. Four thresholds, the names, the deputies, the pre-approved standard and the escalation. Then measure the twenty requests again in a quarter and see whether the median moved, because that number is the only evidence that any of this worked.

Frequently Asked Questions