TL;DR
Somebody asks for a better laptop and you have about a minute to work out whether they are blocked or irritated. Both are real and they need different answers. The question that separates them is not what is wrong with your machine, it is what are you waiting for and how long.
- Ask what they are waiting for, and how long. That one question sorts most requests.
- A measured wait is a business case. Slowness in general is a complaint.
- Memory and a second screen solve more requests than a new machine does.
- Answer within days. A slow no is worse than a fast one.
- Log every refusal. The same request eight times is a policy gap.
- Health and accessibility requests never go through this process.
The one question that sorts a better laptop request
Do not ask what is wrong with the machine. You will get a description of symptoms, all of them real and none of them decisive.
Ask instead: what are you waiting for, and how long does it take?
Somebody who answers that builds run for eleven minutes, or that the design file takes ninety seconds to open and they open it forty times a day, has handed you a business case. The arithmetic does the rest.
Somebody who says it feels slow has handed you a complaint. That is not dismissive. Complaints are real and worth addressing, and they usually have a cheaper fix than a new machine.
Why the distinction matters
Because the two need different responses, and conflating them produces either a stream of replacements or a blanket no that frustrates the people with genuine constraints.
The measured-wait group is usually small and almost always worth approving quickly, because the waiting costs more than the hardware within a quarter.
The frustration group is larger and mostly solvable without a purchase.
What actually fixes most requests
Three things, in order of how often they work.
More memory. The single most common real constraint on an otherwise fine machine, and on many laptops it is a cheap upgrade rather than a replacement. Many modern machines cannot be upgraded after purchase, which is worth knowing before promising it.
A second screen. A surprising share of requests described as needing a faster machine turn out to be about switching between windows all day. A monitor costs a fraction of a laptop and fixes that completely, and the workstation setup guidance published in the United States Occupational Safety and Health Administration computer workstations eTool is a better starting point for screen and posture questions than a hardware catalogue.
Storage pressure. A machine that is nearly full behaves badly in ways that feel like age. Worth checking before anything else, because it takes minutes.
| Symptom described | Usual cause | First thing to try |
|---|---|---|
| Slow with many apps open | Memory pressure | Add memory if possible |
| Constantly switching windows | Screen space | Second monitor |
| Generally sluggish, older machine | Often storage | Check free space |
| Long builds or renders | Genuine processing limit | This one needs the machine |
| Poor video calls | Usually network or camera | Test before replacing |
Only the fourth row reliably requires new hardware. The other four are cheaper and faster to resolve, and resolving them builds more goodwill than a refusal does.
Saying no without damaging anything
Disclosure: RemoAsset, named below, is owned by the same people who publish PeopleOpsHQ. It is described with its limitations stated, on the same terms as every other supplier. This site takes no vendor money.
Most of the harm in this process comes from how a refusal is delivered rather than from the refusal itself.
Three things make a no survivable.
Speed. Answer within a few days. A no after three weeks of silence reads as being ignored, and that is what people remember and repeat.
A reason that is not budget. “There is no budget” invites a return visit next quarter and tells the person nothing. “Your machine meets the specification for this work and here is what we can do instead” is a position they can engage with.
An alternative. Memory, a monitor, or a review date. Almost nobody argues with a no that comes attached to something.
The thing never to route through this process
Requests connected to health, pain or accessibility must have their own path with a different owner, and the policy should say so explicitly.
Somebody who needs a particular setup because of a physical condition should never be queued behind somebody who wants a larger screen, and the person deciding equipment budgets is not the right person to assess a health need.
This is the single most important line in any equipment policy and it is missing from most of them. If you need a starting framework for what accessible working actually involves, the W3C Web Accessibility Initiative introduction to accessibility is written for digital work rather than for buildings, which is the right scope for a distributed team.
Log the refusals
Every no goes in a list with the reason. Review it quarterly. If the same request appears repeatedly from the same function, the standard specification is wrong and the policy is generating friction it does not need to.
The decision table
| Situation | Scale | Setup | Primary pain | Recommended starting point |
|---|---|---|---|---|
| Measured wait, engineering | Any | Standard machine | Time lost to builds | Approve quickly, it pays back |
| Feels slow, no numbers | Any | Machine within spec | Frustration, not blockage | Check storage, then memory or screen |
| Whole team asking | Any | One standard for all | Specification gap | Review the tier, not the requests |
| Requests keep returning | Any | Refusals unlogged | Same argument repeatedly | Log refusals and review quarterly |
| Health or comfort related | Any | Single request queue | Wrong people deciding | Separate route, different owner |
What a replacement actually costs the company
Worth having these numbers to hand, because the conversation usually assumes the laptop price is the whole cost.
A replacement means a purchase, a shipment, setup time, data migration, a period where the person is partly productive, and eventually the old machine coming back, being wiped and being redeployed or disposed of.
The hardware is a minority of that. Which argues both ways: it makes casual replacement more expensive than it looks, and it makes a genuinely justified replacement worth doing properly rather than deferring for two quarters and buying twice.
The machine that comes back
The part most often forgotten. When somebody is upgraded, their old machine is still a working device with life left in it.
If it goes into a drawer, the upgrade cost you a full machine. If it is wiped and reissued to somebody whose needs it fits, the upgrade cost you the difference between two tiers, which is much less.
That only happens where there is a route back: collection, a trusted wipe, storage and reissue. Where that chain is missing, every upgrade is a net new purchase and the budget reflects it. A storage and redeployment service for returned devices is one way to close it, and the limitation is worth stating: it costs money to store a machine, so for low value or very old devices the sum does not always work. Do the arithmetic per device band rather than assuming.
For how to set the tiers these requests push against in the first place, see our guide to laptop spec standardisation.
Give the answer a date instead of a verdict
The version of this process that generates the fewest arguments does not get better at saying no. It stops needing to.
Publish the refresh interval and let people see where their own machine sits in it. Somebody who knows their laptop is replaced in eight months asks a different question from somebody who believes the answer is never, and the second person asks it repeatedly.
That costs nothing to set up. It is one column in whatever the asset register already is, plus a way for a person to look up their own entry.
Two numbers that make the conversation shorter
The date the machine was issued, and the date it is due for replacement. With both visible, most requests either resolve themselves or arrive with a reason that genuinely beats waiting, which is exactly the filter you wanted the policy to apply.
It also surfaces the case nobody tracks: people whose replacement date passed and whose machine was never swapped. Those are not upgrade requests, they are a backlog, and they should be handled as a refresh rather than as individual appeals. Any team that has never checked this finds some, usually among people who never complain.
What to do with the exceptions you approve
Record them against the person rather than against the request. Somebody who needed a higher specification once will need it again at the next refresh, and rediscovering that through a second business case wastes both sides a conversation. One field saying this person is on the higher tier, with the date and the reason, removes the whole exchange next time. For how the standard tiers themselves get set, procurement with a standard build per role covers the mechanism, with the caveat that the tiers still have to be your decision rather than a supplier catalogue.
See how an upgraded machine gets back into service at storage and redeployment of returned devices, or read our guide to laptop spec standardisation.
Frequently asked questions
How do we tell a real need from a preference?
Ask what they are waiting for and how long it takes. Somebody who says builds run for eleven minutes, or that a file takes ninety seconds to open and they open it forty times a day, has given you a business case and the arithmetic finishes the argument. Somebody who says the machine feels slow has given you a complaint, which is real and usually has a cheaper fix.
What fixes most upgrade requests?
Memory first, which is the commonest genuine constraint on an otherwise fine machine, though many modern laptops cannot be upgraded after purchase so check before promising. A second screen next, because a surprising share of requests framed as needing speed are really about switching between windows all day. And storage pressure, which makes a machine behave badly in ways that feel like age.
How quickly should we answer?
Within a few days, and a fast no beats a slow yes for most people. A refusal after three weeks of silence reads as being ignored, and that is the part people remember and tell colleagues about. The speed of the answer does more for how the policy is received than the generosity of the decision.
How should we phrase a refusal?
Not as a budget problem, because that invites a return visit next quarter and explains nothing. Say that the machine meets the specification for the work and offer what you can do instead, whether that is memory, a monitor or a review date. Almost nobody argues with a no that arrives attached to something concrete.
Where do health related requests go?
Down a separate path with a different owner, stated explicitly in the policy. Somebody who needs a particular setup because of a physical condition should never queue behind somebody who wants a bigger screen, and whoever manages the equipment budget is not qualified to assess a health need. This line is missing from most equipment policies and it matters more than the rest of them.
What should we do with the old machine?
Get it back into service rather than into a drawer. An upgraded person leaves behind a working device with life in it, and if it is wiped and reissued the upgrade cost you the difference between two tiers rather than a whole machine. That needs a route back: collection, a wipe somebody trusts, storage and reissue. Without that chain every upgrade is a net new purchase.
Should we track refusals?
Yes, with the reason, reviewed quarterly. One refusal is a decision. The same request arriving eight times from the same function is a specification gap, and chasing individual requests will never fix it. The log turns a stream of awkward conversations into one policy change, which is cheaper for everybody including the people doing the asking.
PeopleOpsHQ covers the operational side of distributed work. We describe suppliers with their limitations stated, and we take no vendor money.
