TL;DR
- An equipment exception policy exists so that the answer to an off-standard request is a decision rather than an argument.
- The rate tells you more than any individual case. Above roughly one in six, your standard is wrong, not your people.
- Name the four exception types separately: accessibility, role requirement, location constraint, and preference. They need different answers.
- Preference requests need a written answer, not silence. Silence gets read as "ask your manager to escalate it".
- One named approver per type, a stated decision window, and the reason recorded. That is the whole policy.
- Never route an accessibility request through the same queue as a monitor upgrade. It is the most common and most damaging design error here.
The Request That Took Five Weeks
He needed a second screen and a specific keyboard. His wrists had been a problem for years, he had a letter about it, and he had asked once in his first week and once in his third.
The first ask went to IT, who said it was not in the standard bundle and suggested he speak to his manager. The manager said it sounded reasonable and asked who approved that sort of thing, and nobody knew. It went to HR, who assumed IT had a process. Five weeks and four conversations later the keyboard was ordered by somebody who decided to stop waiting and expense it.
Nothing in that story involves a refusal. Everybody he spoke to agreed with him. The request failed because no single person could say yes, and an equipment exception policy is the document that fixes exactly that.
Best tools for HR Operations
The real issue is not that the standard bundle was too narrow. It is that the company had a standard with no written answer for what happens when the standard does not fit, which means every off-standard request becomes a navigation problem for the person who made it.
Four Types, Four Different Answers
The most important thing an exception policy does is stop treating these as one category. They are four, and merging them produces the failure above.
Accessibility and health requirements. Somebody needs specific equipment to work comfortably or at all. These should not compete with other requests for budget or attention, should not require the person to explain their reasons to multiple people, and should have the shortest decision window of any type.
Role requirements. The standard bundle does not do the job. A designer needing a colour-accurate screen, an engineer needing more memory, somebody running hardware tests needing a second machine. The question here is technical and the right approver is somebody who understands the work.
Location constraints. The standard cannot be delivered, supported or powered where the person is. A model that is not sold in their market, a power standard that differs, a courier that will not carry it. This is not really an exception to the standard so much as a local substitution, and it should be handled as one.
Preference. Somebody wants a different machine, a larger screen, a particular brand. Entirely legitimate to ask and entirely legitimate to decline, and it needs a written answer precisely because the answer is often no.
| Type | Right approver | Decision window | Default answer |
|---|---|---|---|
| Accessibility or health | HR, with no technical gate | Days, not weeks | Yes, with the specifics confirmed |
| Role requirement | Engineering or function lead | Within a week | Yes if the work needs it |
| Location constraint | Whoever owns logistics | Within a week | Substitute to the nearest equivalent |
| Preference | Manager, within a budget band | Within a week | No, with a reason, or yes at cost parity |
What to do: write the four types into the policy as separate paths with separate approvers. The single-queue version is what produces five-week waits, because the queue inherits the slowest and most cautious handling of whatever is in it.
Why the Rate Matters More Than the Cases
The most useful output of an exception policy is not the decisions. It is the count.
Under roughly one in ten requests, your standard is working. Exceptions are genuine edge cases and handling them individually is correct.
Around one in six, look at the standard. That is a lot of people needing something the standard does not provide, and the cheapest fix is usually to change the standard rather than to keep processing exceptions. A monitor that two in ten people request is a monitor that should be standard, and the approval overhead on it is pure waste.
Above about one in four, the standard is a fiction. It describes a bundle nobody actually receives, and everybody has learned that the real process is the exception process. At that point the policy is doing harm, because it adds a step to the normal path and calls it an exception.
Track the rate by type, not just overall. A high accessibility rate means something different from a high preference rate. The first may mean your standard ignores ergonomics entirely. The second may mean your standard is genuinely below market for your roles, or simply that people like asking, and the difference is visible in whether the requests cluster on one item.
What to do: report the exception rate quarterly, split by type, alongside the approval and decline counts. One table, five minutes to produce, and it is the single best signal you have about whether your equipment standard reflects reality. The cost side of the same question is in equipment cost per hire.
The Accessibility Path Needs Its Own Rules
This is the part of an equipment exception policy that is most often got wrong, and the errors are consistent.
Do not route it through a technical approver. A request for an ergonomic keyboard does not need an assessment of whether the keyboard is technically necessary by somebody whose job is managing a device fleet. It needs somebody who can say yes.
Do not require the person to re-explain it. Each additional person who has to be told is a disclosure the person did not choose to make, and the five-week story above is partly a story about somebody having to explain their wrists to four people. One intake, one approver, one conversation.
Do not hold it against a budget that competes with preference requests. If the accessibility requests and the monitor upgrades draw on the same pot, the accessibility requests will sometimes lose, and that is not a defensible outcome regardless of how the policy is worded.
Do not make the standard the starting point for negotiation. The useful question is what this person needs, not how far from the bundle it is. A policy written as a set of permitted deviations frames the conversation badly from the first line.
And keep the record minimal. Record that an exception was approved and what equipment was issued. Whatever supporting detail was shared does not belong in an equipment system that a wide internal audience can read, and the asset register is not the right place for it. The general principle of keeping personal detail out of the equipment side is the same one behind asset register HRIS integration.
What to do: write this path first and separately, before the rest of the policy, and have whoever owns HR sign it off rather than whoever owns IT. The rest of the policy is a process document. This part has consequences the others do not.
What an Equipment Exception Policy Should Actually Say
An exception policy that runs to several pages will not be read and will not be followed. The working version is short.
Who decides, by type. A name or a role, not a team. Four lines.
How long they have. A stated window per type, and what happens if it passes. An escalation that is written down is used. One that is not written down becomes the person expensing a keyboard.
What gets recorded. The request, the decision, the reason, the date. Four fields. The reason is the one people skip and the one that makes the policy reviewable, because a list of decisions without reasons cannot tell you anything about whether the standard is right.
What happens on a decline. The person is told, in writing, why, and what would change the answer. A decline with no reason reads as arbitrary and generates an escalation, which costs more than the equipment would have.
The budget rule for preference requests. Usually either a cost-parity rule, meaning you can have the different thing if it costs no more, or a band with a number in it. Either works. Having neither does not.
What to do: fit it on one page. If it does not fit on one page, you are writing a standards document rather than an exception policy, and those are two separate documents with two different audiences.
The Intake: One Form, Four Routes
The policy describes four paths, and the person making a request should not have to know which one they are on. That is the intake's job.
One place to ask. A form, a channel, a ticket type, whatever fits how your company already works. What matters is that there is one answer to "where do I ask for this", because the five-week story starts with three plausible places and no correct one.
Routing happens after intake, not before. The requester picks a reason from a short list, and that selection routes it. They do not need to know who approves accessibility requests, which is useful because the person who knows least about your approval structure is the one who joined last week and needs a keyboard.
The accessibility option goes first in the list and says nothing more than it needs to. "I need specific equipment for health or accessibility reasons" routes correctly and asks for no detail at intake. The detail, if any is needed, is a conversation with one person afterwards.
Four fields, not fourteen. What you need, why, where you are, and by when. Anything else can be asked once somebody has read it. Long forms get abandoned, and an abandoned request is indistinguishable from a satisfied employee right up until it is not.
| Intake field | Why it is there | Who reads it |
|---|---|---|
| What you need | Routes the request and prices it | The approver for that type |
| Reason, from a short list | Selects one of the four paths | Routing only, not a judgement |
| Location | Determines availability and shipping | Logistics, on substitution cases |
| Needed by | Separates urgent from routine | The approver, for sequencing |
What to do: build the intake before the approval structure if you have to choose, because a single front door with slow routing still beats four doors with fast routing. Most requests fail at the door rather than at the decision.
Writing the Standard So Fewer Exceptions Are Needed
The cheapest exception policy is the one that rarely fires, and that is a function of the standard rather than the policy.
Specify the standard by role band, not as one bundle. A single company-wide bundle guarantees exceptions from whichever roles it fits worst, and those exceptions are predictable, repetitive and avoidable. Three or four bands absorb most of what would otherwise be role-requirement exceptions.
Include the things people always ask for. If 8 out of 10 people request a dock, the dock is standard and pretending otherwise generates 8 approvals for every 10 hires. Look at a year of exception data before writing the next version of the standard, which is the main reason to record reasons at all.
Write the standard as an outcome, not a part number. "A laptop suitable for the role, a second screen, and peripherals" survives a model being discontinued. A specific model number means the standard is out of date the moment a supplier changes their range, and every hire after that is technically an exception.
State what is deliberately not included, and why. A standard that is silent on chairs, phones or home internet invites a request for each, and the request has to be processed because nothing says no. One line each saying where that sits instead costs nothing and removes a category of request.
Review it twice a year against the exception data. This is the same standing review described above, looked at from the other side: the exception rate is the input to the standard, and the standard is what reduces the exception rate.
What to do: treat the standard and the exception policy as one document with two halves, owned by one person. Split ownership is why exception rates ratchet upward: approving is somebody's job and widening the standard is nobody's.
What Changes When You Hire Across Markets
Location constraints look like exceptions and mostly are not, and treating them as exceptions creates work with no decision in it.
Availability varies by market. A laptop model, a monitor, a specific keyboard layout: each may simply not be sold where the person is, or not be sold at a price that makes sense once import handling is added. There is no decision to make here. There is a substitution to specify.
So pre-approve the substitutions. For each market you hire in, record the nearest equivalent to each standard item. That turns a request into a lookup, and it means the person does not wait a week for somebody to confirm that yes, they may have the model that is actually available.
Keyboard layout is the one people forget. It is not a preference and it is not an upgrade. Somebody working in a market with a different layout needs that layout, and routing it through an approval queue as a preference request is both wrong and slightly insulting.
Power, warranty and support differ too. A device bought in one market may have no local warranty service in another, which is a real constraint rather than a technicality, and it shows up months later as an unrepairable laptop. The substitution table should record where warranty is valid, not only what is purchasable.
Recovery is the other half of this. What you issue in a market determines what you can recover from it, and the recovery side of distributed equipping is its own problem, covered in IT asset recovery for small teams.
What to do: maintain a substitution table per market rather than an exception queue per request. It takes an afternoon per market to build and it removes the single highest-volume category of false exceptions.
What the Policy Costs to Run
Small, and worth stating because unquantified process overhead is how these documents get written and then ignored.
Approver time. At a company of 300 hiring 90 people a year with an exception rate around one in six, that is roughly 15 decisions a year, spread across four approvers. Minutes each. The cost is not the deciding, it is being reachable.
The quarterly report. One table, counts by type, approvals and declines. Perhaps 30 minutes a quarter if the four fields are being recorded, and essentially impossible if they are not, which is the real argument for recording the reason.
The twice-yearly standard review. A half-hour meeting with the exception data in front of it, and an output that is either a changed standard or a written reason for keeping an exception as an exception.
The substitution table. An afternoon per market at setup, then a review when a supplier changes their range, which is perhaps annually.
What to do: add up the above and it is a few hours a year, which is the point. A policy that is described as overhead without a number attached gets cut in the first efficiency conversation. One with a number attached survives, because the number is smaller than the cost of the five-week story happening once.
When You Don't Need a Written Policy
Under about 40 people. Everybody knows who decides and the decision takes a day. Writing it down adds process to something that is working.
One location, one role type. The standard either fits or obviously does not, and the substitutions are small in number and easy.
No standard bundle at all. If equipment is specified per person on hiring, there is nothing to make an exception to. Worth knowing because some companies write an exception policy before they have written a standard, which is the wrong order.
Nobody will track the rate. The main value of the policy is the data it produces about your standard. If that is not going to be looked at, the policy is just a routing document, and a routing document can be three lines in a handbook rather than a policy.
The Exception That Should Change the Standard
A specific and recurring pattern, worth naming because the response is counterintuitive.
When the same exception is approved repeatedly, it has stopped being an exception. The fifteenth approval of the same monitor model is evidence that the monitor belongs in the standard, and continuing to process it as an exception costs approver time for a decision whose outcome is already known.
The reason this persists is that nobody owns the standard. Approving an exception is somebody's job. Changing the standard usually is not, so the path of least resistance is to keep approving, indefinitely, and the cost accumulates quietly in approval overhead rather than in equipment spend.
The fix is a standing review. Twice a year, look at the approved exceptions by item. Anything approved more than a handful of times goes into the standard or gets a written reason for staying an exception. That is a half-hour meeting with a real output.
And accept that the standard will get more expensive. Folding commonly approved exceptions into the standard raises the per-person equipment cost, which is the correct outcome and should be stated as such rather than discovered in a budget variance. You were already paying it through the exception path.
What to do: name an owner for the standard, not only for the exceptions. Without that, the exception rate ratchets upward permanently and the policy slowly becomes the real process.
Manager Discretion, and Where to Draw It
Every exception policy has to decide how much a manager can approve alone, and both extremes fail.
No discretion at all means every request routes centrally, the central approver becomes a bottleneck, and managers learn to tell their people that equipment is somebody else's problem. It also generates the most friction for the smallest requests, because a cable adapter goes through the same path as a workstation.
Unlimited discretion means the standard is advisory, spend varies by how generous a manager is, and two people doing the same job end up differently equipped for reasons that have nothing to do with the work. That is a fairness problem before it is a cost problem, and it surfaces as a grievance rather than as a budget line.
A band is the answer, and the band should be published. Below a stated value, a manager approves and the record is logged. Above it, the type-based path applies. The number matters less than the fact that it is written down and the same for everybody.
Keep accessibility outside the band entirely. An accessibility request should not be subject to a manager's budget discretion in either direction, because that makes the outcome depend on which team somebody happens to be in.
What to do: set the band at a value that covers most peripheral requests and excludes machines. In practice that usually means adapters, cables, keyboards, mice and headsets go through a manager, and anything with a screen or a processor goes through the policy.
Where the Policy Lives, and What Systems Can Hold
An equipment exception policy is mostly a document and a habit, but three parts of it want to live in a system, and knowing which three saves you from buying something you do not need.
The intake and routing belongs wherever your company already raises requests. A help desk, a form tool, a channel with a template. Nothing specialised is required and nothing specialised is better, because the thing that makes an intake work is that people already know where it is.
The record of decisions wants to be somewhere queryable, because the quarterly report is the point. A spreadsheet works at small scale. Above a few hundred people the four fields want to sit next to the asset record, so that the device issued and the reason it was issued are in the same place.
The substitution table wants to live with whoever buys and ships, because it is a procurement artefact rather than a policy one.
What asset registers hold. AssetTiger publishes a plain ladder by asset count, with tiers at $15, $20, $40, $75, $140 and $275 per month, and will record what was issued to whom. Snipe-IT is free and open source self-hosted, with managed hosting published at $399.99 per year for its small tier and $2,499.99 at the top, and its documented API means custom fields for an approval reason are straightforward. Lansweeper, Device42 and Asset Panda all publish no readable price and route to a quote.
What a lifecycle platform adds. RemoAsset is an equipment lifecycle platform aimed at distributed teams, and it is owned by the same people who publish this site, which you should weigh against everything said about it here. The relevance to an exception policy is narrow and real: because it holds procurement and per-market availability alongside the device record, it is the kind of system where a substitution table stops being a separate spreadsheet. Its limitations are real. Pricing is quote-based with no published figure, so you cannot compare it on price from a web page, and it is a newer platform with a smaller footprint than the long-established ITAM names, which matters if a long reference list is part of how you buy.
| Part of the policy | Where it should live | Specialised tool needed |
|---|---|---|
| Intake and routing | Existing request channel | No |
| Decision record, four fields | Next to the asset record | Only above a few hundred people |
| Substitution table per market | With procurement or logistics | No, but helps if integrated |
| Quarterly rate report | A spreadsheet, derived | No |
| Accessibility case detail | Nowhere in the equipment stack | No, deliberately |
What to do: do not buy anything for this. Use what you have, and let the quarterly report tell you whether the record-keeping has outgrown a spreadsheet, which at most companies it has not.
Reviewing the Policy Itself
A policy that is never reviewed becomes a description of how the company used to work, and these have a specific decay pattern worth watching for.
The approvers change and the document does not. Four named roles, and within two years one has left, one has changed team, and one has a different title. Requests route to nobody. This is the most common way an equipment exception policy stops working, and it is silent, because a request that routes nowhere looks like a request nobody made.
The band stops meaning anything. A manager discretion band set a few years ago at a value that covered peripherals now covers almost nothing, or covers a laptop. Either way the intended boundary has moved without anybody deciding to move it.
The standard moves and the exception list does not. Items folded into the standard remain on the exception form, so people keep requesting things they are already entitled to and approvers keep approving them. Pure waste, and it inflates the exception rate, which then makes the standard look worse than it is.
The accessibility path quietly acquires a technical gate. This one is worth watching for specifically. It happens by accretion rather than by decision: somebody adds a confirmation step, somebody else adds a specification check, and after two years the path has the shape the policy was written to prevent.
What to do: review the document itself once a year, separately from the twice-yearly data review. Check the four names resolve to real people, check the band against current prices, check the exception list against the current standard, and walk one accessibility request through the process end to end to see how many people touch it. That last check is worth more than reading the document.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| Under 40 people | Under 40 | Informal | None | Three lines in the handbook |
| Requests stalling | 100 plus | No named approver | Nobody can say yes | Name four approvers by type |
| Accessibility handled slowly | Any | Single queue | Competing with upgrades | Separate accessibility path first |
| Exception rate above one in six | 150 plus | Standard exists | Standard is too narrow | Review and widen the standard |
| Spend varies by manager | 200 plus | Unlimited discretion | Fairness, then cost | Publish a discretion band |
| International substitutions | Any | Global standard | Model unavailable locally | Treat as substitution, not exception |
| Declines generating escalations | Any | No written reasons | Decisions look arbitrary | Require a reason on every decline |
| No standard bundle | Any | Per-person specs | Nothing to except from | Write the standard first |
Three Cases Worth Deciding in Advance
Most of what an exception policy handles is ordinary. Three cases are not, and deciding them before they arrive is considerably easier than deciding them during.
Somebody wants to use their own machine. It arrives as a preference request and it is not one, because it touches what can be installed, what can be enforced, what happens to company data on a device you do not own, and what happens when that person leaves. Whatever your answer is, it should not be given by whoever happens to pick up the ticket. Write the position down once, in the policy, with a pointer to whoever owns the security side.
Somebody wants to keep equipment on leaving. Sometimes reasonable, sometimes a sale, sometimes a gift, and all three have implications beyond equipment. The exception policy should say who decides and on what basis rather than attempting to decide in advance, because the circumstances vary more than a rule can cover. What it should rule out is the request being settled informally by a manager, which is how two people in the same situation get different answers.
Somebody needs a second complete setup. A person working from two locations, or a role that genuinely needs a test machine as well as a working one. These are expensive, legitimate in a minority of cases, and almost always approved badly, either waved through on seniority or refused on cost without anybody asking whether the work needs it. Route it to the function lead with the role-requirement path, not to a budget holder.
What to do: add three lines to the policy naming who decides these, and resist the urge to write the decision itself. The value is in the routing being settled, because each of these arrives rarely enough that nobody remembers what happened last time.
What Getting This Wrong Costs
The visible cost is equipment spend drifting upward through an exception path nobody is measuring. That is the least of it.
The larger cost is the five-week story, repeated. A person who needs something to work comfortably, asking three times, and concluding that the company is indifferent. Nobody in that chain was indifferent. The absence of a named approver produced an outcome indistinguishable from indifference, and the person on the receiving end has no way to tell the difference. That is an engagement cost that does not appear in any equipment budget.
The second is fairness. Without a published band and written reasons, two people in the same role get different equipment because one has a manager who pushes and one does not. That is visible to both of them, it is not defensible when it is raised, and it is the kind of difference that gets discussed in exit conversations.
And the third is that an unmeasured exception rate hides the real finding. A company processing one request in five as an exception has learned nothing from the fact, and the information it is sitting on is that its equipment standard does not describe what people actually need. That is a useful thing to know and it costs nothing to find out, because the data is generated by the policy whether or not anybody reads it.
So the question is not how generous to be with exceptions. It is whether a named person can say yes within a week, whether the accessibility path reaches them without passing through anybody else, and whether anybody is counting the rate twice a year.
When You're Ready to Write It
Write the accessibility path first, separately, and get it signed off by whoever owns HR rather than whoever owns equipment. It is the part with consequences the rest of the policy does not have.
Then name four approvers for the four types, state a decision window for each, and publish the manager discretion band with an actual number in it. Record four fields per request, including the reason, because the reason is what makes the whole thing reviewable.
And put the quarterly rate report in somebody's calendar. The policy's main product is not decisions. It is the evidence about whether your standard is right, and that evidence is only useful if somebody looks at it twice a year.
Frequently Asked Questions
What should an equipment exception policy contain?
Five things, on one page: who decides for each of the four exception types, how long they have to decide, what gets recorded, what happens on a decline, and the budget band within which a manager can approve alone. The four types are accessibility or health, role requirement, location constraint, and preference, and the reason they are separated is that they need different approvers and different default answers.
Why separate accessibility from other exceptions?
Because routing it through the same queue means it competes with monitor upgrades for budget and attention, it requires the person to explain their situation to several people who do not need to know, and it inherits whatever the slowest handling in that queue is. An accessibility request should have one intake, one approver who can say yes without a technical gate, and the shortest decision window in the policy.
What exception rate is too high?
Under one in ten and the standard is working. Around one in six, look at widening the standard, because processing that volume of exceptions costs more in approver time than the equipment would. Above about one in four the standard has become a fiction that describes a bundle nobody receives, and everybody has learned that the exception path is the real process.
Who should approve a preference request?
The line manager, within a published budget band, with the answer in writing either way. Preference requests are legitimate to make and frequently legitimate to decline, which is exactly why they need a written reason: a decline with no explanation reads as arbitrary and generates an escalation that costs more than the equipment would have.
How much discretion should a manager have?
Enough to cover peripherals and not enough to cover machines. In practice that means cables, adapters, keyboards, mice and headsets go through a manager under a published value, and anything with a screen or a processor goes through the type-based path. Publish the number, apply it uniformly, and keep accessibility requests outside the band entirely so the outcome does not depend on which team somebody is in.
What do we do when the same exception keeps getting approved?
Fold it into the standard. The fifteenth approval of the same item is evidence it belongs in the bundle, and continuing to process it costs approver time for a decision whose outcome is already known. Run a standing review twice a year over approved exceptions by item, and expect the standard to get more expensive as a result, which is correct because you were already paying it through the exception path.
Should a declined request be recorded?
Yes, with the reason, and the reason is the field people skip. A list of decisions without reasons cannot tell you whether your standard is right, which is the main thing the policy produces. It also means a person who asks again next year gets a consistent answer rather than a different one depending on who happens to pick it up.
Do we need this if we specify equipment per person at hiring?
No, and writing one would be the wrong order. An exception policy only makes sense against a standard bundle, so if equipment is specified individually there is nothing to make an exception to. Write the standard first, run it for a couple of quarters, and let the pattern of off-standard requests tell you what the exception policy needs to cover.