TL;DR
Escalating an equipment request starts with working out which kind of no you received. A budget no, a policy no and a capacity no look identical in a ticket and need completely different responses. Escalating the wrong one to the wrong person is how reasonable requests get stuck for months.
- Budget no goes to whoever owns the budget. Not to IT.
- Policy no needs an exception process, or the policy is the thing to change.
- Capacity no is a timing problem and usually just needs a date.
- Most refusals are never explained, which is the actual defect.
- If you have no exception route, every no becomes an escalation.
The moment this becomes real
Say a designer asks for a larger monitor and a different laptop specification for colour work. The ticket is closed with a note saying it does not meet the standard specification.
That might mean several things. There is no budget this quarter. The standard spec is policy and exceptions need approval. Procurement cannot source that model in their country. Or whoever closed the ticket applied a rule without much thought.
Best tools for HR Operations
The designer does not know which, so they escalate to their manager, who escalates to the Head of Operations, who asks IT, who explain it was the sourcing problem all along and could have been solved in a week by ordering something equivalent. The real issue is not the refusal. It is that a no with no reason attached forces everybody to guess, and guessing costs three people’s time.
When this is lighter than you think
Four stages where this needs no formal route.
- Small companies. Under about forty people, the person who can approve an exception is in the same conversation.
- Generous standard specification. If the default machine covers nearly every role, refusals are rare.
- An existing exception process that works. Then this is not an escalation question, it is a form.
- Clear budget ownership. Where managers hold equipment budget, a no is a conversation with their own numbers rather than an appeal.
It matters in companies large enough that requests go to a queue, with a fixed standard specification, and no written exception route.
The five questions worth asking first
Which kind of no was it? Ask directly, because the answer determines everything. Budget, policy, sourcing capacity or an error. Most tickets do not say, and most people who closed them will tell you immediately if asked.
Who owns the decision? Rarely IT, which is the common misunderstanding. IT usually executes a standard somebody else set, within a budget somebody else holds. Escalating within IT for a budget decision wastes everyone’s time.
Is there an exception process? If yes, use it, because that is exactly what it exists for and it is faster than an escalation. If no, the absence of one is the finding, since without it every unusual request becomes a personal appeal to somebody senior.
What is the business reason? Requests framed as preference get refused and requests framed as a work requirement get approved, often for the identical item. That is not gatekeeping, it is how approvers distinguish between the two, and most refused requests simply never explained the need.
What is the cost of waiting? Quantify it. A designer colour matching on an unsuitable screen is producing work that may need redoing, and that argument lands where a request for a nicer monitor does not.
Three ways this gets handled, and where each breaks
Accept the no. Common, and often the end of it. Costs nothing visible. It breaks quietly: people work around the gap, buy things personally, or stop asking, and nobody learns that the standard specification does not fit a role.
Escalate up the management chain. Manager, then their manager, until somebody says yes. It works and it is expensive. It breaks because it rewards persistence and seniority rather than need, so the people who get equipment are the ones most comfortable pushing.
Route by reason to the right owner. Budget to the budget holder, policy to an exception process, sourcing to procurement with alternatives. Fastest and fairest. It breaks only where the reason was never given, which is why asking for it is the first step.
Five questions about your own process
Whether escalating an equipment request is even necessary depends on five things.
Do refusals come with a reason? If not, every no becomes a guessing game.
Is there a written exception route? If no, you have delegated exceptions to persistence.
Who holds equipment budget? If nobody can say, budget refusals have no destination.
How often are exceptions approved? Near zero or near a hundred per cent both suggest the process is not working.
Are people buying equipment personally? That is the clearest sign the route is broken.
What is actually available
Five honest options for fixing the underlying process.
Require a reason code on refusals. Best first move. Nearly free and it removes most unnecessary escalation immediately. Struggles if the codes are vague enough to be meaningless.
A written exception process. Best structural fix. One form, one approver, a stated turnaround. Struggles if nobody publicises it, since an unknown process is the same as none.
Devolve equipment budget to managers. Best for speed and accountability. Turns an appeal into a decision somebody can simply make. Struggles on consistency and on standardisation drifting.
Review the standard specification annually. Best long term answer. If a role keeps generating exceptions, the standard is wrong rather than the people. Struggles on nobody owning the review.
RemoAsset. Relevant where refusals are really sourcing problems in disguise, which is more common than teams realise. If the honest reason is that nobody can get that model to that country, procurement across 80+ countries changes the answer, and asset tracking shows what people already hold so approvers are not guessing. Where it struggles: budget and policy refusals are internal decisions and no vendor touches them. Its published pricing starts with a pay as you go plan and a yearly subscription above it.
Where to start, by situation
| Situation | Scale | Setup | Primary pain | Recommended starting point |
|---|---|---|---|---|
| Small company | Under 40 | Direct access | Very little | Have the conversation, no process needed |
| Refusals with no reason given | Any | Ticket queue | Everybody guesses | Add a reason code to refusals |
| No exception route exists | 100 plus | Fixed specification | Escalation by persistence | Write a one page exception process |
| Same role keeps requesting | Any | Standard spec | The standard is wrong | Review the specification for that role |
| Refusal is really sourcing | Any | Hard to supply markets | Model unavailable locally | Solve supply, with a service such as RemoAsset |
What the gap actually costs
An unexplained refusal costs a few emails, which is nothing. The pattern costs considerably more, because every ambiguous no generates escalation through people whose time is expensive and who have to reconstruct a decision somebody else already made.
The second cost is fairness, and it is the one that does damage. A process where equipment goes to whoever escalates hardest systematically favours the confident and the senior. Quieter people and those newer to the company accept the first no, which means the distribution of working equipment reflects personality rather than need.
The third is what happens next. People who cannot get what they need buy it themselves, use personal devices for work, or quietly do the job worse. All three are worse for the company than approving the request would have been. So the question is not whether to escalate. It is why anybody had to.
When the standard specification is the problem
If one role generates exception requests repeatedly, the exception process is working and the standard specification is not. That is a useful signal and it is usually read as individuals being difficult rather than as a configuration problem.
A standard spec is a bet that one machine suits most roles. It is a good bet and it is never right for everybody. The sensible response is a small number of role based variants rather than one default and a stream of appeals, which is both cheaper to administer and less demoralising.
The other common hidden cause is supply. A refusal that sounds like policy is sometimes procurement being unable to source a model in a particular country, and nobody saying so plainly. Where lifecycle management covers the markets you hire in, that reason disappears and the remaining refusals are genuine budget and policy decisions, which is where they should be.
See how equipment is sourced in markets that are hard to supply
Read our guide to writing an equipment exception policy
Related reading
- Writing an equipment exception policy
- Designing an equipment approval workflow
- Who signs off equipment spend
- Handling equipment accessibility requests
- Adjustments for disabled employees follow a different route entirely. Acas publishes UK guidance on reasonable adjustments, and the ILO covers disability and work.
Frequently Asked Questions
What is the first step in escalating an equipment request?
Find out why it was refused. Budget, policy, sourcing capacity and simple error look identical in a closed ticket and need entirely different responses. Most people who refused a request will explain immediately if asked, and the answer usually changes where the request should go next.
Should we escalate within IT?
Usually not, because IT rarely owns the decision. They typically execute a standard somebody else set, within a budget somebody else holds. Escalating a budget or policy question inside IT asks people to overturn a decision that was never theirs to make.
Why do similar requests get different answers?
Often because of how they were framed rather than what was asked for. A request explained as a work requirement reads differently from one that reads as a preference, even for the same item. Most refused requests simply never stated the business need.
What does it mean if there is no exception process?
That exceptions are decided by persistence instead. Without a written route, every unusual request becomes a personal appeal to somebody senior, which favours confident and established employees over quieter or newer ones with equally legitimate needs.
How do we know if our standard specification is wrong?
If the same role keeps generating exception requests, the standard does not fit that role. That is a configuration problem rather than a people problem. A small number of role based variants is usually cheaper to run than one default plus a stream of appeals.
What if the real reason is that the item cannot be sourced locally?
That is a supply problem wearing a policy costume, and it is more common than teams realise. The useful response is to ask for an equivalent that can be sourced, or to fix the sourcing, rather than to escalate a decision nobody actually made on the merits.
Is it a problem if people buy equipment themselves?
Yes, and it is the clearest sign the process is broken. It creates unmanaged devices, expense claims that bypass the asset register, and an uneven playing field between those who can afford to and those who cannot. Treat it as a symptom rather than as misconduct.
