TL;DR
- These requests arrive one at a time and get decided case by case, which is slow, inconsistent, and makes people advocate for themselves repeatedly.
- There are legal dimensions here that differ by jurisdiction and by circumstance. Take local advice on those. This article covers the operational route, which is the part that is usually broken.
- Do not route them through a procurement budget. A request that lands in a team's equipment line gives the manager a reason to discourage it.
- Most ergonomic requests are for a handful of items. Stock those and let people take one without asking.
- The commonest practical blocker is a device management policy that prevents an accessibility tool being installed, which turns a resolved request into an argument with IT.
- Record approvals with dates, so moving team does not restart the process. That is the failure people feel most.
The Request That Took Nine Weeks
Somebody asked their manager for a different keyboard. The manager did not know whether that was theirs to approve, so they asked HR, who said it depended on whether it was an ergonomic need or a preference, and asked for more detail.
The person provided more detail, which meant explaining a wrist problem to their manager and then again to somebody in HR. The request moved to IT, who said the keyboard was not on the standard list and would need a budget code. The budget code belonged to the team, so it went back to the manager, who approved it, and then procurement asked for a quote from a supplier who did not stock that model.
Nine weeks. The keyboard cost less than a monitor. Nobody in the chain did anything wrong and the person had explained a medical matter to four people to obtain an item that should have been on a shelf. What they learned from the process was not to ask again.
Best tools for HR Operations
That is the shape of this problem at most companies. The decision is usually yes. The route is the thing that fails, and it fails in a way that disproportionately affects the people least willing to push.
Three Things That Get Conflated
Separating these is most of the fix, because they need different routes, different decision-makers and different speeds.
A preference. A second monitor, a larger screen, a particular mouse because somebody prefers it. Entirely legitimate, no justification required beyond the work, and it belongs in the ordinary equipment request route with a stated turnaround.
An ergonomic need. A chair, a desk, a keyboard, a vertical mouse, a laptop stand, a footrest. Usually small items, frequently requested, and the category where the nine-week failure above lives. These should mostly not require a request at all.
An accessibility requirement. Screen reading, magnification, dictation, a specialised input device, captioning, software configuration. Lower volume, higher variability, and the category where an individual conversation genuinely is appropriate because the requirement is specific to the person.
Companies that run one route for all three end up applying the scrutiny appropriate to the third category to requests from the second, which is how a keyboard takes nine weeks. And they apply the speed appropriate to the first to the third, which is how somebody waits two months for software they need to do their job.
| Category | Route | Decision speed | Justification needed |
|---|---|---|---|
| Preference | Ordinary equipment request | Days | The work, briefly |
| Ergonomic need | Open stock, no request for common items | Same day | None for stocked items |
| Accessibility requirement | A separate named route | Days, not weeks | A conversation, with one person |
Stock the Common Items and Stop Asking
The highest-return change in this article and the one that needs no policy.
Across most companies, the great majority of ergonomic requests are for a small set of items. A vertical or ergonomic mouse. A split or compact keyboard. A laptop stand. A separate keyboard so a laptop can be raised. A footrest. A larger or second monitor. A headset with better padding. An anti-glare screen filter.
That is about eight things. Hold a small stock of each and let anybody take one without a request, a justification or an approval, exactly as most companies already handle pens and notebooks.
Three reasons this works better than a process.
It removes the disclosure. Nobody has to explain a wrist, a back or a migraine to a manager to obtain an item that costs less than a week of their time. That alone resolves the most common complaint about these processes.
It is faster than any approval route could be. Same day, or the next delivery for a remote worker.
It costs less than the administration it replaces. The staff time consumed by a nine-week approval chain exceeds the cost of the item by a wide margin, and that is true even if some items are taken by people who did not strictly need them.
For remote staff the equivalent is a short catalogue with a one-click request and no approval step, shipped to the home address. Same principle, slightly slower, and still faster than anything involving a manager.
And review what people actually take after two quarters. If one item accounts for most of the requests, consider adding it to the standard bundle for everybody, which removes even the one-click step.
When a Request Should Be a Conversation
Not everything can be on a shelf, and the third category genuinely needs a person.
When the requirement is specific to the individual. Specialised input devices, software configurations, or anything that needs setting up around how a particular person works. A catalogue cannot anticipate this and should not try.
When an assessment would help. Sometimes the useful answer is not the item somebody asked for, and an assessment by somebody qualified identifies that. This should be offered rather than required, because requiring an assessment to obtain a footrest is the nine-week problem again.
When it interacts with the managed device. Covered below, and it is the practical blocker that most often turns an approved request into a continuing problem.
When it is not equipment at all. Some requests are about hours, location, meeting formats or written materials, and routing them through an equipment process will fail. The route needs to be able to pass a request sideways rather than refusing it.
What any of this obliges an employer to do, who may ask for what information, and how any of it should be recorded and protected differs by jurisdiction and by circumstance, and some of it is genuinely a matter of legal duty rather than good practice. Take local advice before designing the route, and particularly before writing anything about what information may be requested or retained.
Five Questions People Ask First
"Whose budget should this come from?" A central one, and this is the single most important design decision here. If a request lands in a team's equipment line, the manager has a financial reason to discourage it, and some managers will, without any ill intent, simply by asking whether it is really necessary. A central budget removes the incentive entirely and the amounts involved are small enough that it is affordable at almost any size.
"Does the manager need to know why?" They need to know that a request was approved and whether anything changes practically, such as a delivery arriving or a desk setup differing. They do not need the reason. Designing the route so that the reason goes to one named person rather than up a management line is the difference between a route people use and one they avoid.
"What if somebody asks for something expensive?" Then it is a conversation, and a conversation is fine. The problem this article describes is not expensive items receiving scrutiny; it is inexpensive items receiving the scrutiny designed for expensive ones. Set a value threshold below which nothing needs approval, and most of the volume falls below it.
"Can we ask for medical evidence?" This is exactly the question to take local advice on, because what may be requested, by whom, and how it must be handled varies considerably and getting it wrong has consequences beyond an unhappy employee. Operationally, the point worth making is that requiring documentation for a footrest guarantees nobody will ask for a footrest.
"How do we stop people abusing it?" Mostly by not worrying about it. The items in the open-stock list are inexpensive and unglamorous, the realistic worst case is that somebody takes a laptop stand they did not strictly need, and the cost of that is far below the cost of a process designed to prevent it. Where a request is genuinely large, the threshold already routes it to a conversation.
The Managed Device Problem
The practical blocker that turns an approved request into a continuing problem, and the one most likely to be invisible to whoever approved it.
Accessibility software is frequently already present in the operating system. Screen reading, magnification, contrast adjustment, dictation and caption tools ship with most platforms and need no purchase at all. The obstacle is rarely the software and often the device policy.
Four specific collisions.
Installation is blocked. A managed device that prevents software installation will prevent an accessibility tool being installed, and the person is then negotiating with a security policy rather than using their approved adjustment.
A setting is enforced centrally. Display scaling, contrast, pointer size and animation settings are sometimes managed, which means a person's adjustment is reverted on the next policy refresh. This is the most frustrating version, because it works and then stops working.
A peripheral is not permitted. Some device policies restrict external devices, which can block a specialised input device.
An extension is blocked. Browser-based accessibility tools are often extensions, and extension allowlists are usually maintained for security reasons with no accessibility input.
So the fix is to put this on somebody's list before it is needed rather than resolving it per incident. Ask whoever manages the device policy to produce an exception path for accessibility tooling, documented, with a named approver and a short turnaround, and to confirm that enforced display and input settings can be overridden per device. Both are ordinary configuration work and neither is urgent until somebody is waiting.
Designing the Route
Six properties, and a route with all six will work regardless of how it is implemented.
One entry point. A single place to ask, which is not the person's manager. A form, a named role, or a dedicated queue.
No disclosure to the management line. The reason goes to one named person. The manager is told that something was approved and anything they need to do practically.
A stated turnaround, in days. Five working days for a decision is reasonable. The number matters less than its existence, because an unstated expectation becomes nine weeks and nobody can point at a breach.
A value threshold. Below it, no approval. This is what keeps the volume out of the route entirely.
A central budget. Not the team's. Non-negotiable if you want the route to be used.
The ability to pass sideways. Some requests are not about equipment, and a route that can only approve or refuse equipment will refuse things that should have gone elsewhere.
Then one thing that is not a property but a test: ask somebody who has used the route what it was like. Not whether they got the item. Whether they had to explain themselves more than once, and to how many people.
Record It So It Does Not Restart
The failure people report most often and the one that is cheapest to prevent.
Somebody obtains an adjustment, it works, and then they change team, change manager, change office or receive a new laptop at refresh. The new manager does not know, the new machine does not have the software, the new desk does not have the chair, and the person starts again. Often with the same explanations to new people.
Record the approval, with its date, against the person, in a place that survives a team change. Not in an email thread and not in the approver's memory. What may be recorded, where, and who may see it is precisely the kind of question to take local advice on, so settle that first and then implement it properly.
Attach the device-related parts to the asset and the refresh process. If somebody's machine needs particular software or a particular configuration, that should be a property of their setup that follows them to the next machine automatically. Otherwise refresh day undoes the adjustment, which is a bad day for somebody who had to ask for it.
Carry physical items across a move. A chair that follows somebody to a new desk costs nothing. A chair that stays with the desk means a new request.
Tell the new manager the minimum. That an arrangement exists and what they need to do, not why.
So the test is whether somebody who moves team in month 14 has to ask again. Because every company's offboarding and onboarding processes are built for joining and leaving rather than for moving, internal moves are where these arrangements quietly expire, and nobody is informed because no event fired.
How to Choose: Five Questions Before You Design Anything
What does the current route actually look like, traced end to end? Follow one real past request through every hand it passed through and count the hands and the days. Most companies discover a chain nobody designed and nobody can defend, which is the argument for changing it.
Whose budget does it come from today? If the answer is the team's, change that first. It is a single decision and it removes the structural disincentive.
How many people learn the reason? Count them. Anything above one is a design flaw and is also the thing people cite when they say the process is difficult.
What are the eight most requested items? Ask whoever processes these. The list is shorter than expected and it is the basis for the open stock that removes most of the volume.
Can your device policy accommodate accessibility tooling, and has anybody checked? Ask before somebody is waiting. This is the one item here that cannot be resolved quickly when it is urgent.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| Requests go through the manager | Any | One entry point that is not the manager | Explaining a medical matter to obtain a keyboard | Change the entry point before anything else |
| Budget sits with the team | Any | Central budget line | A financial reason to discourage requests | Move the budget. One decision |
| Small items taking weeks | Any | Open stock of about eight common items | Approval scrutiny applied to cheap items | Stock them and remove the request entirely |
| Remote staff with no office stock | Any | Short catalogue, one click, no approval | A shelf that only helps people in a building | Ship from the catalogue to the home address |
| Software blocked by device policy | Any | Documented exception path with an approver | An approved adjustment that cannot be installed | Ask the device policy owner now, not later |
| Settings reverted at policy refresh | Any | Per-device override for display and input | An adjustment that works then stops | Confirm overrides are possible before you need them |
| Adjustment lost at refresh or on a move | Any | Recorded against the person, carried forward | Internal moves firing no process | Record it properly, with local advice on how |
| Requests that are not about equipment | Any | A route that can pass sideways | Refusing something that belonged elsewhere | Give the route a referral option |
The Software Half, Which Is Usually Free
A large share of accessibility requirements are met by software, and a large share of that software is already installed, which makes this the cheapest category and frequently the slowest to resolve.
Screen reading, magnification and contrast adjustment ship with every major operating system. So does pointer size, reduced motion, colour filtering and, on most platforms, dictation and live captioning. Nothing needs buying and nothing needs approving. What they need is for somebody to know they exist and for the device policy not to prevent them.
The specialised tools are the minority. Where somebody needs a particular screen reader, a specific dictation product or a professional magnification tool, that is a purchase and a conversation. It is also a much smaller population than the built-in features serve.
The real work is discovery, not procurement. Most people do not know what their own machine can already do, and the features are buried in settings panels with names that do not match what anybody would search for. A single internal page listing what is available on your standard builds, with the path to each, is worth more than any approval process and takes an afternoon to write.
Three things to do with that page.
Write it per platform you actually run. Generic advice is useless because the settings are in different places and named differently. Two short sections beat one long general one.
Link it from the handbook's equipment section and from onboarding. Somebody who sees it in week 1 does not have to ask in month 11.
Say explicitly that using any of it needs no permission. This is the sentence that matters. A list of features with no statement about permission will be read as a catalogue of things to request, which reintroduces the route you were trying to bypass.
And have whoever owns the device policy confirm the list works on a managed machine before publishing it. Because a page telling somebody their laptop can do something it has been configured not to do is worse than no page, that verification is the step not to skip, and it is also how the policy exceptions get identified before anybody is waiting.
Setting the Threshold and the Turnaround
Two numbers do most of the work in this route and both are usually left unstated, which means both default to somebody's discretion.
The value threshold. Below it, nothing is approved by anybody. The item is taken from stock or ordered from the catalogue and that is the end of it. Set it high enough to cover the 8 items above comfortably, which at most companies means a figure that covers a monitor rather than one that covers a mouse. Setting it too low is the common error and it leaves the majority of requests still inside an approval process you built the threshold to avoid.
The decision turnaround for everything above it. 5 working days to a decision, and 10 working days to the item being in somebody's hands including delivery. Publish both. A route with a published 10 days is held to it and a route with no published figure took 63 days in the example that opens this article without anybody breaching anything.
Then two numbers worth tracking rather than setting.
The proportion of requests that fall below the threshold. If it is under about 70 per cent, the threshold is too low and you are still processing volume you intended to remove. Raising it is a single decision and usually costs very little, because the items between the old and new thresholds are inexpensive by definition.
The elapsed time, measured from the first time the person mentioned it. Not from when the form was submitted. Those two dates can be 3 weeks apart, because the gap between somebody raising it with a manager and the request entering the route is invisible to the route's own reporting. Ask for the first date on the form.
So the published commitment is two figures and the internal measure is two more, and the internal ones are the ones that tell you whether the design is working. Because a route measures itself from the moment a request enters it, every badly designed route reports excellent performance, which is why the 63-day request in the opening example would have appeared in no report at all.
What to Put on the Shelf
The open-stock list is the intervention with the shortest path to a result, so it is worth being specific about what goes on it and roughly what each item solves.
| Item | What it addresses | Why it belongs on open stock |
|---|---|---|
| Vertical or ergonomic mouse | Wrist and forearm discomfort | Among the 3 most requested items at most companies |
| Split or compact keyboard | Shoulder width and wrist angle | Inexpensive, and the request that most often needs explaining |
| Laptop stand | Screen height, neck posture | Solves a problem almost every laptop user has |
| Separate keyboard | Required once the laptop is raised | Useless without the stand, so stock them together |
| Footrest | Seat height mismatch with a fixed desk | Cheap, bulky, and never worth an approval chain |
| Larger or second monitor | Screen reading, magnification, multitasking | The one item that sometimes exceeds a threshold |
| Padded headset | Long call days, comfort, hearing | Frequently requested and rarely stocked |
| Anti-glare filter | Light sensitivity, migraine triggers | Very low cost, almost never available |
Three practical notes on running it.
Stock 2 or 3 of each rather than a precise count. This is a consumable arrangement, not an asset one. Track a stock level and reorder when it drops, and do not create asset rows for a footrest.
Pair the items that only work together. A laptop stand without a separate keyboard leaves somebody worse off than before, because the screen is now at the right height and the keyboard is unreachable. Issue them as a pair by default.
Put the shelf somewhere people can reach without asking. A cupboard that requires somebody to find a key defeats the entire purpose, and the person who most needs the item is the least likely to go hunting for whoever holds the key. A shelf in an open area with a sign is enough, and if the concern is items disappearing, the honest comparison is between the cost of replacing a few mice and the cost of the process you would otherwise run.
For remote staff the same 8 items become a short catalogue with no approval step. Because the whole point is removing the conversation rather than speeding it up, any version of this that routes through a person has lost most of the benefit, even if that person always says yes within a day.
The Refresh Day Problem
Worth its own section because it is the most reliable way an adjustment that works gets undone, and it is entirely foreseeable.
A laptop refresh replaces the machine. Everything configured on the old one that was not part of the standard build goes with it: the magnification settings, the installed dictation tool, the pointer size, the contrast profile, the browser extension. Somebody who spent 9 weeks obtaining an arrangement discovers on refresh day that they have a clean machine.
Four things prevent it.
Flag the asset record, not the person's memory. A device whose user has a non-standard configuration should carry a marker, so whoever prepares the replacement knows to ask. What that marker may say and where it may live is a local advice question; a neutral flag indicating that configuration notes exist is usually enough.
Capture the configuration as a short list at the time it is set up. Three or four lines naming the software and the settings. Written once, used at every refresh thereafter.
Build it before handover, not after. The replacement machine should arrive configured, which means the preparation step needs the list. Delivering a clean machine and fixing it afterwards puts the burden back on the person.
Ask before the refresh rather than after. One message, a week out, checking whether the current arrangement still suits them. This is also the cheapest opportunity to improve something that has been imperfect for two years and that nobody has mentioned.
And apply the same logic to a machine replacement after a failure, which is the version that happens with no notice at all. A loaner with none of somebody's configuration is a machine they cannot use, and the loaner process is where this is most often forgotten.
What Getting This Wrong Costs
The visible cost is the nine weeks, and it is the smallest of three.
The second is the requests that stop being made. Somebody who had to explain a wrist problem to four people to obtain a keyboard will not ask about the chair, and the next person who hears about that experience will not ask at all. Because an unmade request leaves no trace anywhere, a route that discourages people looks identical in every report to one nobody needs, and the only way to see the difference is to ask somebody who used it.
The third is the one that should concern anybody designing this. A process that is slow, repetitive and requires disclosure does not affect everybody equally; it filters by how willing and able somebody is to push. The people who most need an adjustment are frequently the least positioned to spend nine weeks obtaining it, which means the practical effect of a badly designed route is the opposite of what the route exists to achieve. There may also be obligations engaged here that a poor process puts the company on the wrong side of, which is a further reason to take proper advice on the design rather than only on the decisions.
The reframing question: of the adjustments in place across your company today, how many were obtained by somebody who had to push for them, and how many people are using a setup that does not suit them because the route looked like too much trouble?
When You're Ready to Fix the Route
The honest position is that the decision is almost always yes and the route is almost always the problem, which is unusual and makes this cheaper to fix than most things in this area.
The trigger worth acting on is one traced request. Not a complaint and not a policy review. Follow a single real past request through every hand and count the days, because that trace is the entire business case and it takes an afternoon to assemble.
The sequence costs very little. Move the budget to a central line, which is one decision and removes the structural disincentive. Ask whoever processes these requests for the eight most common items and put them on a shelf, with a catalogue equivalent for remote staff. Set one entry point that is not somebody's manager, with a stated turnaround in days and a value threshold below which nothing needs approval. Then ask the device policy owner for a documented exception path for accessibility tooling, before anybody is waiting on it.
And take local advice on the parts that engage legal duties, specifically what information may be requested, how it must be handled and what obligations apply, because those vary and they are the one part of this that cannot be worked out from first principles. The operational design above is the half you can fix this month.
Two closing observations worth keeping separate from the process advice.
The first is that almost nothing in this article is expensive. A shelf of eight inexpensive items, a central budget line, a published page describing features already present on machines you already own, and a documented exception path in a policy you already maintain. The reason these routes are bad is almost never cost. It is that they sit between HR, IT, procurement and line management, and each of those four can see a quarter of the problem while owning none of it. Naming a single owner for the route is worth more than any individual improvement in it.
The second is that the quality of this route is read as a statement about the company, accurately. Somebody who asks for a keyboard and receives it in two days learns something, and somebody who explains a medical matter to four people over nine weeks learns something else. Both of them tell colleagues. Of all the operational processes a company runs, this is among the smallest in cost and among the largest in what it signals, which is an unusual combination and a good argument for fixing it before anybody has to complain.
Frequently Asked Questions
How should equipment adjustment requests be routed?
Through one entry point that is not the person's manager, with the reason going to a single named person rather than up a management line. The manager is told that something was approved and anything they need to do practically, not why. Add a stated turnaround in days, a value threshold below which no approval is needed, a central budget rather than the team's, and the ability to pass a request sideways when it turns out not to be about equipment at all.
Whose budget should pay for ergonomic and accessibility equipment?
A central one, and this is the most consequential design choice available. When a request lands in a team's equipment line, the manager has a financial reason to question it, and some will ask whether it is really necessary without any ill intent at all. A central budget removes the incentive completely, and the amounts involved are small enough to be affordable at almost any company size. The administration saved typically exceeds the cost of the items.
Should common ergonomic items require a request at all?
No. Across most companies the large majority of these requests are for about eight items: an ergonomic mouse, a split or compact keyboard, a laptop stand, a separate keyboard, a footrest, a larger monitor, a better headset and an anti-glare filter. Hold a small stock and let anybody take one with no request, justification or approval, exactly as most companies handle stationery. For remote staff, a short catalogue with one click and no approval step does the same job.
Does a manager need to know why an adjustment was requested?
No, and designing the route so they do not is what makes it usable. They need to know that a request was approved and anything practical that follows, such as a delivery arriving or a desk being set up differently. The reason should reach one named person only. What information may be requested, by whom, and how it must be handled and recorded differs by jurisdiction and by circumstance, so take local advice on that specifically before writing any of it down.
Why do approved adjustments stop working?
Usually the managed device policy, and it happens in four ways. Software installation is blocked, so an approved tool cannot be installed. A display or input setting is enforced centrally and reverts at the next policy refresh, which is the most frustrating version because it works and then stops. An external device is not permitted. Or a browser extension is blocked by an allowlist maintained for security reasons with no accessibility input. Ask the device policy owner for a documented exception path before anybody is waiting.
How do you stop an adjustment being lost when somebody changes team?
Record the approval with its date against the person, somewhere that survives a team change rather than in an email thread, and take local advice on where and how that may be held. Attach anything device-related to the refresh process so a new machine inherits the configuration automatically. Let physical items follow the person rather than the desk. And tell a new manager the minimum, meaning that an arrangement exists and what they need to do, not what it is for.
Is accessibility software something you have to buy?
Mostly not. Screen reading, magnification, contrast adjustment, pointer size, reduced motion, colour filtering and, on most platforms, dictation and live captioning all ship with every major operating system, so nothing needs purchasing or approving for the majority of requirements. Specialised products are a genuine minority. The real work is discovery, since most people do not know what their own machine already does and the settings are buried under names nobody would search for. Publish a page per platform listing what is available and stating plainly that using it needs no permission.
How do you know whether the current route is working?
Ask somebody who has used it, and ask the right question. Not whether they received the item, which is usually yes, but whether they had to explain themselves more than once and to how many people. Then trace one real past request end to end and count the hands and the days. The requests that were never made leave no trace anywhere, which means a route that quietly discourages people looks identical in every report to one nobody needed.
HROpsLab takes no vendor money and publishes no paid placements, which is why this article says plainly which questions need local advice rather than answering them.