Giving People the Same Kit in Twelve Markets, and Why You Cannot

TL;DR

• Parity means three different things and only one of them is achievable across markets. Companies write a standard for the wrong one.
• Same model fails on availability, keyboard layout, regional warranty and landed cost. Same spend fails harder, because identical money buys unequal machines.
• Capability parity is the one that works: define the job the machine has to do, name a model per market, and let the model vary.
• Lead time is a parity failure nobody calls one. Three days in one market and five weeks in another is a real difference in how it feels to join.
• Peripherals are where people actually compare, and almost no standard names them.
• A standard that does not state the keyboard layout and the operating system language has delegated both to whoever places the order.

The Standard That Said One Model

A 190-person company with people in 12 markets wrote an equipment standard. One page, clear, and the hardware line named a single laptop model with a memory and storage configuration.

It worked in 4 markets. In 3 more the model was available with a 5-week lead time against 3 days at home. In 2 it was available only in a configuration one step up, which pushed the landed cost past what the budget line allowed. In the remaining 3 the person ordering locally substituted something close, reasonably, and told nobody.

Eighteen months later the register held 11 distinct models and configurations across 12 markets. Nobody had broken the standard: the standard had described an outcome that supply could not produce, so every market resolved it locally and the resolutions never came back. The support team was carrying knowledge of 11 machines, the spares strategy had quietly become per-market, and a resale batch that should have been one clean lot was four small ones.

Recommended Tools

Best tools for Device Management

B BambooHR HR management system L Lattice Performance management D Deel Global payroll & EOR

View all recommended tools

The company had written a standard about a model. What it needed was a standard about capability, and the difference is the whole of this article.

Three Things People Mean by Parity

When somebody says everybody should get the same kit, they mean one of three things and usually have not decided which.

Same model. Everybody gets the identical machine. Intuitive, easy to audit, and the version that cannot survive contact with twelve supply chains.

Same capability. Everybody gets a machine that does the same job to the same standard, which may be a different model in different markets. Harder to audit and the only one that holds.

Same spend. Everybody gets the same budget. The most superficially fair and the least fair in practice, for reasons below.

Choosing between these is not a detail. It determines what your standard document says, what your procurement team is accountable for, and what you tell somebody who notices their colleague in another country has a different laptop.

Pick capability. Then be explicit that you have, because the people who will compare are comparing models and need to know that the model is not the promise.

Why Same Model Does Not Survive

Four reasons, and the first is the one that gets discovered immediately while the others surface later.

Availability and lead time. A configuration in stock in one market may be 5 weeks out in another, or available only through a channel that does not support automated enrolment. The person ordering locally faces a choice between a delay nobody will accept and a substitution nobody will notice, and they will substitute.

Keyboard layout. The same model ships with different layouts and a layout is not a preference, it is how somebody types all day. A standard that names a model without naming a layout has not actually specified the machine, and the default will be whatever the local supplier stocks.

Regional warranty and service. Warranty terms and the availability of on-site or next-day service vary by market, so the same model carries materially different support depending on where it was bought. A machine bought in one region and carried to another can also fall outside the service you thought you had, which matters for anybody who relocates.

Landed cost. Import duty, local taxes and freight all move the delivered cost, and the divergence between markets is large enough to break a single budget line. So a standard built on one model and one figure will be in breach in some markets on the day it is published.

None of these is a reason to give up on consistency. They are reasons the consistency has to be expressed at the capability level, because that is the level supply can actually deliver.

Why Same Spend Is Worse Than It Sounds

Equal budgets feel like the fairest possible rule and they produce the least equal outcome.

The mechanism is simple. The same amount of money buys a different machine in different markets, because duty, local taxes and local pricing all differ. So an identical figure delivers a capable machine in one market and a compromised one in another, and the person with the compromised machine has been treated equally in a way that is worse for them.

Because the budget is the visible number and the capability is not, this failure is invisible to whoever set the budget and obvious to the person using the laptop. It also compounds: the market where the money buys less is often the market where the lead times are longest and the support weakest, so the same people get the thin end of three separate decisions.

Equal spend has one legitimate use, which is peripherals and home setup allowances where the goods are locally sourced and roughly equivalent. Even there it is worth stating a capability floor alongside the figure, so somebody in an expensive market is not choosing between a chair and a monitor.

When Parity Is Not Worth Chasing

When you are in two or three markets

Below about four markets, with one person coordinating orders, you do not need a document. The coordinator holds the whole picture and will make sensible substitutions. Writing a standard at this size produces a document nobody reads and a false sense that the question is settled.

When the roles are genuinely different

An engineering workstation and a laptop for somebody working in a browser all day are different machines because the jobs are different, and that is not a parity failure. The thing to avoid is letting role-based variation become seniority-based variation, which is a different article and a worse habit.

When the market has one person in it

One person in a market you may never hire into again is an exception, and treating it as a precedent costs more than treating it as an exception. Record what you did and why, so the next person can see it was deliberate.

The edge case that forces the full answer

The third market, or the first relocation. Three markets is roughly where one coordinator stops holding it and substitutions start going unrecorded. A relocation is harder, because the person arrives with a machine bought under another market's arrangements and immediately sits outside both.

Five Questions People Ask First

"Can we just buy everything centrally and ship it?" Sometimes, and it is better than its reputation for a small number of markets. What it costs you is lead time and duty on every unit, and what it buys you is one model, one keyboard decision and one warranty conversation. For 3 or 4 markets it is often the right answer. Past that, the freight and duty arithmetic stops working and the lead times become the parity problem.

"How do we handle keyboard layouts?" By naming them in the standard, per market, as an explicit field. There is no neutral default and leaving it blank means the local supplier decides. Also decide what happens when somebody wants a different layout from their market's default, which is common among people who learned to type elsewhere, and make that a request rather than an argument.

"Should the budget be the same everywhere?" No, and this is the counterintuitive one. Hold capability constant and let the figure vary, which is the opposite of how most budgets are written. The finance conversation is easier than it sounds once somebody has seen what an identical figure actually buys in two different markets.

"What about people who relocate?" Decide in advance whether the machine travels with them. Usually it should, and the two things to check are whether the warranty follows and whether the keyboard layout still suits them. Neither is automatic, and both are cheap to resolve at the point of the move rather than six months later.

"Does any of this matter if nobody complains?" The register answer is yes even where the people answer is no. Eleven models is a support cost, a spares problem and a resale discount whether or not anybody has mentioned it, and those costs arrive quietly rather than as a complaint.

Capability Parity, and How to Define It

The useful standard describes what the machine must be able to do, names the model that delivers it in each market, and treats the model list as something that changes.

Define capability in five fields. Not more, because a longer list produces exceptions, and not fewer, because a shorter one does not actually specify a machine.

Then add the two fields that make it executable rather than aspirational.

A named model per market, with two alternates. Not a minimum specification, because a minimum invites somebody to meet it with something odd. A named model and two substitutes for when the first is out of stock, which happens more often than central procurement expects.

A review date on the model list. Quarterly is reasonable. Hardware lines change, and a model list with no review date becomes a document people work around rather than from.

So the standard has five capability fields that rarely change and a model table that changes every quarter. Because those two things have completely different lifespans, keeping them in one undated document is what caused the eleven-model outcome, and separating them costs nothing.

The Fields Nobody Writes Down

Four things that are decided by default when a standard omits them, and all four are visible to the person receiving the machine.

Keyboard layout, per market, with an exceptions route. Covered above and worth repeating because it is the most common omission and the most immediately felt.

Operating system display language. Often set by the supplier based on the shipping destination, which produces a machine in a language the person may not use for work. Trivial to specify and awkward to change afterwards on some platforms.

The power adapter and any travel requirement. Obvious until somebody moves between regions or travels regularly, at which point the absence of a second adapter is a daily irritation that costs very little to prevent.

The peripheral set. This is where people actually compare, and almost no standard names it. A monitor, a dock, a keyboard, a mouse and a headset is a typical set. If it is not stated, each manager negotiates it individually and the outcome correlates with how assertive somebody is rather than with what they need.

Lead Time Is a Parity Problem

Nobody writes lead time into an equipment standard and it is one of the clearest inequalities in the whole area.

Somebody who joins and has a working laptop on day one has a different experience from somebody who waits 3 weeks and works on a personal machine in the meantime. The second person has also been given a quiet instruction about where company data can live, which is a security outcome rather than an inconvenience.

Three things make it manageable.

Publish the lead time per market, alongside the model. Not a target, the observed figure. People accept a known 3 weeks far better than an unknown wait, and publishing it also makes the markets where it is bad visible to the people who could fix it.

Hold a small number of regional spares in the markets where lead times are long. Funded from recovered machines rather than new purchases, which costs nothing and connects two halves of the lifecycle that usually operate separately.

Make the order trigger earlier in the markets with longer lead times. This is the cheapest fix available and it is a calendar change rather than a procurement one. If the lead time in a market is 5 weeks, the order has to be placed at offer acceptance rather than at the start of the onboarding process.

And measure it. The number of starters who had working equipment on day one, by market, over the last two quarters, is one query and it will tell you which of your markets has a problem that the standard document cannot see.

How to Choose: Five Questions Before You Write Anything

How many markets do you employ in, and how many will you in two years? Under 4 and a coordinator beats a document. Above that you need the model table, and the forecast matters because adding a market to an existing table is easy while retrofitting a standard across 12 is not.

Which of the three parities are you actually promising? Write the sentence. If you cannot say whether you are promising a model, a capability or a budget, the document will promise all three and deliver none.

What is the observed lead time in each market? Ask whoever orders rather than whoever supplies. This single table will probably surprise you and it is the input to both the spares decision and the order-trigger decision.

Who decides a substitution, and does it come back? The eleven-model outcome is a reporting failure rather than a discipline failure. Somebody substituted sensibly and had no route to tell anybody. Name the route.

What is the peripheral set? Decide it now. It is the part people compare, it is cheap relative to the laptop, and leaving it open converts every new start into a small negotiation.

The Options in Practice

Central purchase and ship

Best for 3 or 4 markets with tolerable freight routes. One model, one keyboard decision, one warranty conversation.

Where it struggles: duty on every unit, lead times that get worse rather than better, and residential delivery in markets where you have no presence.

A local supplier per market

Best where lead times matter most and you have somebody in each market who can own a supplier relationship.

Where it struggles: this is the arrangement that produced eleven models. It works only with a named model table and a substitution reporting route, and it needs each supplier checked for automated enrolment eligibility rather than on price alone.

A lifecycle platform

Best for more than about 6 markets, or where residential delivery and later collection are both needed and you have no local presence anywhere.

Workwize, Deel IT, Firstbase, GroWrk and allwhere all operate here to varying depth, and none of them publishes a price, so comparing three is three sales processes before you have a budget figure. The capability to test is the model list they can actually deliver in your specific markets, not their country count.

Where they struggle: pricing opacity, and the model range offered in a given market may be narrower than you would get locally.

RemoAsset

Disclosure: RemoAsset is owned by the same people who publish HROpsLab. It is relevant here because the order, the configuration and the shipment are one step, which means the model actually delivered is recorded against the asset rather than discovered later, and that is the specific failure in the opening example. It publishes no price and requires a demo, it is much weaker for hardware it did not supply, and it is not a certified disposal vendor.

The Comparison

The second column is the one people optimise and the third is the one that costs them later, because a cheap local supplier whose devices do not appear in automated enrolment turns every start into a manual setup call.

The Decision Table

Writing the Standard

One page, two tables, and a review date. Here is what goes on it.

A sentence saying which parity you promise. For example: we hold capability constant across markets, so the model may differ and the capability will not. That sentence prevents most of the comparisons that otherwise arrive as complaints.

The five capability fields, as exact figures. Memory, storage, screen, battery expectation, operating system. Exact rather than minimum, because minimums produce drift.

The model table. One row per market: the named model, two alternates, the keyboard layout, the operating system language, the observed lead time, and the supplier. With a quarterly review date and an owner.

The peripheral set, as a list. Standard items and request-only items, separately.

The substitution rule. Who may substitute, what they may substitute to, and where they record it. One line, and it is the line that prevents the eleven-model outcome.

The exceptions route. How somebody asks for something different, who decides, and roughly how long it takes. An exceptions route that exists on paper is what stops exceptions being granted informally by whoever is asked first.

So the document is short and the model table is the living part of it. Keep them in the same place and review only the table, because the capability fields should be stable for years while the models change every few months.

Two tiers is almost always the right number, and the split is by what the machine has to run rather than by job title. A standard tier for everybody whose work is a browser, a document editor and a video call, which is most people and is where exact memory and storage figures matter most because they decide whether the machine is still pleasant in year three. And a higher tier for the roles that compile, render, run virtual machines or handle large media, defined by the workload rather than by seniority, so that a senior person doing browser work gets the standard tier and a junior engineer gets the higher one.

Resist a third tier. The pressure for one comes from a handful of genuine edge cases, and those belong in the exceptions route rather than in the standard, because a third tier immediately becomes the tier people negotiate for. Two tiers with a working exceptions route handles the same range of needs with a quarter of the argument, and it keeps your model table to 2 rows per market instead of 3.

And write the tier names so they describe the work, not the person. Anything that sounds like a grade will be read as one.

Measuring Day-One Readiness

Everything in this article points at one number and almost nobody has it. The proportion of starters who had working company equipment on their first morning, by market.

It takes one query and two fields you probably already hold. Take every person who started in the last two quarters. For each, the start date from the HR record, and the delivery or collection date for their device from the register or the courier record. Then a yes or no on whether the second was on or before the first.

Three things to do with the result.

Report it by market, never as a single company figure. A company-wide 87 per cent is a number that hides the problem completely, because the failures cluster in two or three markets and the average is carried by the market where most people are. The whole point is the variation.

Separate the two causes. A late delivery is a supply problem and a late order is a process problem, and they have opposite fixes. The test is whether the order was placed with enough lead time for that market's observed figure. If it was and the device still arrived late, that is the supplier. If it was not, the order trigger is in the wrong place.

Publish it quarterly to the people who can act on it. An unmeasured onboarding failure gets attributed to bad luck, and a measured one with a market attached gets a lead time fixed or an order trigger moved. The 2 markets at the bottom of that table are where your entire parity problem actually lives.

And count the near misses. A machine that arrived on day one because somebody expedited it at the last moment is a pass that should be recorded as a near miss, since the arrangement did not work and a person rescued it. A quarter with 5 near misses in one market is the same signal as 5 failures, and it is the one that disappears from a binary measure.

Running the Regional Spare Pool

The lead time section says to hold a few spares in the slow markets, funded from recovered machines. That is the whole fix for day-one readiness in those markets and it is almost never done, so here is what it involves.

Hold spares only where you hire at least 3 or 4 times a year. Below that frequency a machine will be too old to issue before anybody needs it, and you have converted a usable asset into stock you will eventually sell at a discount. In most companies this means two or three markets, not twelve.

Size the pool from your worst month, not your average. A market where you hired 6 people last year did not hire 0.5 people a month; it hired 3 in September and none in four other months. The pool has to cover the September, which for most markets is 1 or 2 machines.

Fund it from recovered devices rather than new purchases. This is the point that makes the whole thing affordable, and it connects two halves of the lifecycle that usually operate independently. A machine recovered in a market and held there is a domestic shipment away from being useful; the same machine shipped to a head office has consumed an international movement and needs a second to come back.

Wipe on arrival into the pool, not on the way out. A spare that has been cleared with the date and method recorded carries no exposure while it waits, and it can be issued the same day rather than needing a day of preparation when somebody urgently needs it.

Put a review date on every machine in the pool. Ninety days. Without it the pool silently becomes a cupboard of machines nobody will issue, which is the failure mode of every storage arrangement.

Record the pool as its own location in the register. Not as in storage generally. The market matters, because a spare in the wrong market is not a spare.

So the honest arithmetic: 2 machines held in each of 3 slow markets is 6 devices, funded from recoveries, covering the markets where day-one readiness is currently worst. Because the devices are already yours and already in the right country, the only new cost is somebody holding them, which is a local office, a lifecycle platform's regional warehouse, or in the worst case a person willing to keep two boxes, with the understood risk that the arrangement ends when they leave.

The Exceptions Route

An exceptions route that exists on paper is what stops exceptions being granted informally by whoever is asked first, which is how a standard becomes decorative. It needs four things and fits in a paragraph.

A single place to ask. A form, a ticket type, or a named person. Not a manager's discretion, because a standard where managers may grant exceptions is not a standard, it is a default.

Three categories, decided differently. A capability request, where somebody needs more than the tier provides for genuine work reasons. A configuration request, such as a keyboard layout or a second adapter, which should be approved almost automatically because the cost is trivial and the irritation of refusing is not. And an accessibility or ergonomic request, which should not go through a procurement route at all and needs its own path.

A stated turnaround. Five working days for a decision is reasonable, and the number matters less than its existence, because an unstated expectation defaults to whenever somebody gets round to it. A request that takes three weeks teaches people to go around the route next time.

A record of what was granted. One line per decision. After two quarters that log is the most useful document in this whole area, because the pattern in it tells you whether your capability tiers are set correctly. If 8 of the last 12 capability requests came from the same role, the tier is wrong rather than the people.

And publish the refusals as well as the approvals, in aggregate. A route that only ever says yes is a budget line pretending to be a process, and a route whose refusal rate nobody can see will be assumed to be arbitrary.

What Getting This Wrong Costs

The visible cost is the complaint, and it is the smallest of three. Somebody notices a colleague has a better machine, it gets raised, somebody explains the supply situation, and it subsides.

The second cost is the fragmented fleet, and it arrives silently. Eleven models means the support team holds knowledge of eleven machines, the spares strategy becomes per-market by default, and a resale batch that should have been one clean lot is four small ones at a worse rate per unit. Because each individual substitution was sensible, there is no point at which anybody did anything wrong, which is exactly why it persists.

The third is the one that does real damage, which is the day-one gap. Somebody who waits 3 weeks for a laptop works on a personal machine, and that is a decision about where company data lives made by default rather than by policy. It is also the single worst first impression a distributed company can make, and it falls hardest on the markets that already have the longest lead times and the thinnest support.

The reframing question: of the people who started in the last two quarters, what proportion had working company equipment on their first morning, and does that proportion differ by market?

When You're Ready to Write It Down

The honest position is that a standard is not the first thing to write. The first thing is the lead time table, because it is a fact rather than a policy and it will tell you whether you have a parity problem at all or just a procurement one.

The transition point is the third or fourth market, or the first substitution that nobody reported. Both are signals that the coordinator has stopped holding the whole picture, and that is the condition a document exists to address.

The sequence costs an afternoon. Ask whoever places orders for the observed lead time per market and write it down. Pull your register and count distinct models and configurations, because that number is the honest measure of how well your current arrangement works. Decide which of the three parities you promise and write the sentence. Then build the model table with two alternates per market and name the substitution reporting route.

Do that and the standard writes itself, because you will be describing an arrangement that already works rather than one you hope supply can produce. And the eleven-model outcome stops being something you discover in a resale quote.

Frequently Asked Questions

HROpsLab takes no vendor money and publishes no paid placements, which is why the owner's own product is named above with its three limitations rather than its three best features.