Your Vendor Missed the Equipment SLA: A Practical Guide for HR Teams Deciding Whether It Matters

By [Author Name] · [Date] · [X] min read · [Table of Contents]

TL;DR

• A missed equipment SLA is when a vendor fails the delivery or retrieval standard you agreed.
• One miss is noise. The question is always whether it is a pattern, and most companies cannot answer that.
• You need three things before raising it: your own data, the actual contractual standard, and a stated outcome you want.
• Three responses: absorb it, escalate it, or start looking. Each is right in different circumstances.
• Choose based on whether the cause is structural or incidental, not on how annoyed anybody is.
• Done well, the conversation produces a changed process rather than an apology.

A laptop for a new starter arrives four days late. The hiring manager is unhappy, the new starter spent two days on a borrowed machine, and somebody suggests the vendor should be told. The account manager apologises, explains there was a customs delay, and offers to expedite the next one. Everybody moves on.

Six months later the same thing happens, and nobody can say whether it's the second time or the ninth, because nothing was recorded either time.

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 variations are familiar. A company raises a formal complaint about delivery times and the vendor produces data showing ninety-four per cent on-time performance, which the company cannot dispute because it has no data of its own. Another discovers its contract's delivery standard is business days from dispatch rather than from order, which makes a two-week wait fully compliant. A third tolerates poor retrieval for two years, finally escalates, and is told the service was always best efforts.

The real issue isn't the late laptop. It's that service conversations are driven by the most recent irritation rather than by evidence, so they produce apologies instead of changes.

When You Don't Actually Need to Escalate

Stage one: it's one incident with a cause. A customs hold, a courier failure, a stock shortage on a specific model. Genuinely incidental, genuinely not worth a conversation beyond acknowledging it happened. Most misses are this and treating each one as a service failure costs more goodwill than it recovers.

Stage two: friction appears. It's happened twice in a quarter, or it's happening in one specific market, or retrieval is consistently slower than delivery. Still not a crisis and now worth tracking, because the next step requires data you don't have yet.

Stage three: it's a pattern. You can point to a run of misses with a common cause, and the cause is structural rather than incidental. This is where escalation has a purpose, because there's something specific to change.

Stage four: the relationship is the problem. The misses continue after escalation, or the vendor disputes your data, or the account has changed hands twice and nobody remembers the previous conversation. At that point the question isn't the SLA, it's whether to switch.

What HR Teams Actually Need Before Raising It

> "How often has this happened?" > You need your own count, not theirs. > Without it, the conversation becomes their data against your impression, and their data will be better presented.

> "What does the contract actually say?" > Read it before the meeting. The standard is frequently measured from a different point than you assume. > Business days from dispatch and calendar days from order can differ by a week on the same shipment.

> "Is the cause structural or incidental?" > This determines whether escalation can achieve anything. > A customs process in one market is structural. A specific courier failing once is not.

> "What are you actually asking for?" > Decide before you raise it. An apology is what you get when you haven't decided. > The useful outcomes are a changed process, a different route, a named contact, or a credit.

> "Is retrieval being measured at all?" > Usually not, and it is usually the weaker half of the service. > Delivery gets watched because somebody is waiting. Retrieval gets watched by nobody.

A sixth question matters if you're near a renewal: how does this affect the negotiation? A documented service pattern is the strongest position you'll ever have in a pricing conversation, and it only works if it's documented.

The Three Responses and When Each Is Right

Absorb it. What it is: note it internally, say nothing to the vendor. When it's right: single incidents with identifiable external causes, and anything where the cost of the conversation exceeds the cost of the miss. When it fails: when absorbing becomes the default and two years of misses go unrecorded, leaving you with no case when you finally need one. The fix is to absorb the conversation, not the record.

Escalate it. What it is: a structured conversation with evidence and a stated ask. When it's right: when you have a pattern, a cause, and something specific you want changed. When it fails: when it's done on impulse after a single bad week. An escalation without data gets an apology, and having used the escalation you have less room next time.

Start looking. What it is: begin evaluating alternatives, whether or not you intend to switch. When it's right: when escalation hasn't changed anything, or when the cause is structural and the vendor can't fix it. When it fails: when it's a bluff. Evaluating alternatives is useful on its own terms because it tells you whether the problem is this vendor or the category. Several companies discover their vendor's performance is normal.

I'd escalate once, with data, and start looking if nothing changes within a quarter. The sequence matters more than the individual steps, because an escalation with no follow-through teaches the vendor that escalations don't need acting on.

How to Decide What to Do: Five Questions

Do you have a count? If the answer is no, that's the first task rather than the conversation. A month of recording gives you considerably more standing in that conversation than six months of complaining will ever manage to produce.

Where are the misses? Plot them by market. Equipment service problems are frequently concentrated in one or two countries, which converts a vague performance complaint into a specific request about a specific route.

Is it delivery or retrieval? Check both, because the answer is usually retrieval and almost nobody measures it. A vendor with good delivery and poor retrieval looks entirely fine on every single metric that anybody in your company is actually watching.

What is the measured standard? Find the clause and find the start point. A surprising number of service disputes dissolve when somebody reads the definition, which is better found before the meeting than during it.

What would good look like? Write down the outcome you want in one sentence before raising anything. If you can't, you aren't ready to raise it, because the conversation will drift toward whatever the vendor happens to be willing to offer.

Six Platforms Worth Knowing

RemoAsset Best for: companies that want the delivery and retrieval record to exist independently of the vendor's own reporting. Why companies choose it: procurement and retrieval across 80+ countries with each device tracked from issue through return, which produces the dated record a service conversation needs. Published pricing from $1,499 a year on the Subscription tier for companies with 50 to 5,000+ employees, including a 60 per cent reduction on retrieval charges, and the retrieval side is the half most arrangements never measure. It's our own product, so weigh that accordingly, including in a comparison like this one. Where it struggles: no network discovery, so the record covers devices it handles. No software licence management. And only the Subscription tier publishes a figure, with pay-as-you-go quoted.

Workwize Best for: companies whose delivery misses are really stock problems. Why companies choose it: its own warehouses, which removes one common cause of lateness. Where it struggles: publishes no rate card, so a service credit conversation has no published price to reference. The figures on its pricing page are savings claims rather than prices. Live domain is goworkwize.com.

Firstbase Best for: delivery-weighted needs. Why companies choose it: strong supply side, clean subscription shape. Where it struggles: publishes nothing on price, and retrieval is the weaker half, which is where unmeasured misses accumulate.

GroWrk Best for: companies with concentrated problems in specific markets. Why companies choose it: flexible arrangements that can differ per country. Where it struggles: no rate card, and its pricing page runs a competitor cost estimator producing its own estimates.

allwhere Best for: handing the operation over so service management becomes somebody else's job. Why companies choose it: managed service, low internal lift. Where it struggles: publishes nothing, so you have no reference point for what the service should cost.

Deel IT Best for: companies already running employment through Deel. Why companies choose it: hardware alongside employment with MDM and support included. Where it struggles: publishes no price for IT, and its own page states both 130+ and 150+ countries without reconciling them, which is a reason to measure coverage yourself rather than reading it.

The Decision Table: What Actually Needs Deciding

Rows two and four cover most real situations, and row four is the one nobody notices.

Count Before You Complain

This is the whole recommendation and it takes about ten minutes a month.

A service conversation without data is a conversation about feelings. And the vendor will bring a dashboard. Their numbers will be accurate within their own definitions, and because you have no numbers you cannot establish that the definitions are the disagreement. So the meeting ends with their performance report standing, an apology for your experience, and nothing changing.

What you need isn't sophisticated. One row per order, with the date you ordered, the date it was promised, the date it arrived, the market, and a note if something specific happened. The same for retrievals: date requested, date completed, market. A spreadsheet, filled in as things happen rather than reconstructed.

Three months of that is enough to settle almost any argument. It tells you the real average, which is often better than your impression because bad experiences are memorable and routine ones aren't. It tells you where the misses concentrate. And it tells you whether delivery or retrieval is the actual problem, which is the question most companies get wrong.

It also protects you from the opposite error. I've watched a company prepare a formal service complaint and then discover, on counting, that it had experienced four late deliveries in eighteen months, two of which were its own late orders. The counting stopped a conversation that would have cost the relationship and achieved nothing.

The other thing the record gives you is time. Equipment vendors change account managers often, and each change resets the institutional memory of the relationship. A record outlives that. Walking into a meeting with a new account manager holding two years of dated incidents is a materially different conversation from describing a general impression.

Read the Standard Before the Meeting

The second most common reason service conversations go nowhere is that the two sides are measuring different things, and the contract already decided which definition wins.

The usual gaps are specific. Business days versus calendar days, which on a shipment spanning two weekends and a holiday differs by four days. Dispatch versus order, which excludes however long the vendor took to pick and pack, and that's frequently the slow part. Delivered versus delivery attempted, which means a failed delivery to an empty flat may count as success. And in-market versus cross-border, where the same stated standard may apply to a domestic shipment and not to one crossing a customs boundary.

None of that is sharp practice. These are ordinary commercial definitions and a vendor is entitled to measure the part of the process it controls. But if you assumed calendar days from order and the contract says business days from dispatch, your complaint is about a standard that doesn't exist, and you'll find that out in the meeting.

So read the clause, find the start point, find the unit, and find the exclusions. Then recalculate your own data against the actual standard. Whatever remains after that recalculation is your case, and it is a real one that the vendor cannot dissolve with a definition.

If the recalculation makes the problem disappear, you've learned something more useful than a complaint would have achieved: the service is compliant and your expectations were set elsewhere, probably by a sales conversation. That's a renewal discussion rather than a service one, and it's a better conversation to have.

Measure Retrieval, Because Nobody Else Does

Here's the gap in almost every equipment arrangement, and it's the one worth most attention.

Delivery is self-monitoring. Somebody is waiting for a laptop, that person has a start date, and if it's late you hear about it within hours. The feedback loop is immediate and loud.

Retrieval has no feedback loop at all. The person has left. Nobody internally is waiting for the device. The hiring manager has moved on, HR has closed the file, and the only party with any interest is whoever maintains the asset register, who may not find out for months. So a retrieval that takes eleven weeks, or never completes, generates no signal whatsoever.

Which means retrieval performance is invisible by default, and it's also the harder half of the service, which is a combination that reliably produces poor outcomes nobody notices.

Measuring it is simple and takes a quarter. Every retrieval request: date raised, date completed, market, outcome. Then look at the completion rate and the median time. Two numbers, and in almost every company that runs this exercise for the first time both of them come as a surprise.

What you'll typically find is that most retrievals complete reasonably and a tail of them don't complete at all, concentrated in particular markets or particular circumstances, usually where the person left on bad terms or moved. The tail is the cost, and because each instance is written off individually nobody ever sees the total.

That total is the strongest material you can take into any service conversation, precisely because the vendor probably hasn't measured it either. A specific, dated list of incomplete retrievals is harder to respond to with a dashboard than a delivery complaint is.

What to Ask For Instead of an Apology

If you escalate, decide the outcome first, and make it a change rather than a sentiment.

Four asks are worth more than the rest. A different route or carrier for the market where misses concentrate, which is the most actionable thing a vendor can do and often the actual fix. A named contact for exceptions, so the next problem doesn't start from the beginning. A reporting commitment, so you receive the data rather than having to request it. And a defined notification rule, so a retrieval that hasn't completed within a stated period is flagged to you rather than discovered later.

Service credits are worth less than they look. The amounts are small relative to the disruption, claiming them is administratively tedious, and accepting one closes the incident without changing anything. Take a credit if it's offered and don't make it the ask.

Frame the conversation around cause rather than blame. Because you want a process change and that requires the vendor to engage rather than defend. The useful opening is specific: here are nine incidents over six months, seven of them in one market, here's what we think the common factor is, what can be changed. That gets a different response from a general statement that service has been poor.

And set a review point. Agree what you'll look at in a quarter and when you'll discuss it. An escalation with no review date is an apology with extra steps, and the absence of a review is how the same conversation happens again a year later with nobody remembering the first one.

Where Jurisdiction Comes In

A short boundary. What any contractual provision means, what remedies exist for a breach, whether a service standard is enforceable and what any of it entitles you to are questions for a qualified lawyer in the relevant jurisdiction. Nothing here is legal advice and a genuine breach conversation needs proper input.

What's on this page is the operational half, which is where almost every one of these situations is actually resolved. Count the incidents. Read the standard. Measure retrieval. Ask for a process change. Set a review date. None of that requires legal involvement, and all of it determines whether the conversation produces a changed process or another apology.

The practical point is that most equipment service problems are not breaches and shouldn't be framed as them. Framing a pattern of lateness as a legal matter escalates it past the level where it can be fixed by somebody changing a carrier, which is usually the actual solution.

The Spreadsheet, Exactly

The page says count. Here are the columns, because a vague instruction to track things produces either nothing or an over-engineered template nobody fills in.

Eight columns for deliveries. Date ordered. Date promised, as the vendor stated it rather than as you hoped. Date arrived. Market. Device type. Whether the order was placed late by you, which is the column that protects you from building a case on your own delays. A note field for anything specific. And a flag for whether the person was affected, meaning whether a start date or a working day was actually lost.

That last column is the one that turns data into an argument. Nine late deliveries is a statistic. Four late deliveries that each cost somebody their first week is a different conversation, and the distinction is invisible unless you record it at the time.

Five columns for retrievals. Date requested. Date completed, or blank if it hasn't. Market. Outcome, meaning returned, returned damaged, or not recovered. And a note on why, if known, because the reason is the thing that tells you whether the next one is preventable.

I'd add the "late on our side" column before any of the others. I've watched a prepared complaint collapse in the meeting because 7 of the 23 incidents in it were orders placed after the start date had already been agreed.

Fill it in as things happen. Ten minutes a month at most, and the reason the timing matters is that reconstruction is impossible: nobody can establish six months later when a device was promised, and the promised date is the whole basis of the measurement.

Keep it somewhere that survives you. A file on somebody's laptop is lost at their next role change, which is roughly the same frequency as account manager turnover, so the record and the relationship memory disappear together. A shared location with a sensible name is enough.

Name the file so that somebody who has never seen it can tell what it is. A spreadsheet called notes is a spreadsheet nobody opens.

One refinement after the first quarter. Add the median rather than the average to whatever you report. Equipment delivery times have a long tail, so an average is dragged by the three worst incidents and overstates the typical experience. The median tells you what usually happens and the tail tells you what occasionally does, and you want both separately.

What the Data Usually Shows

Three patterns come out of most first quarters of counting, and knowing them in advance helps you read your own numbers.

The typical experience is better than the impression. Bad incidents are memorable and routine ones aren't, so almost everybody's prior estimate of their vendor's performance is worse than the measured median. That's worth knowing before you escalate, because walking into a meeting with data that contradicts your own complaint is a poor outcome.

The misses concentrate. Rarely spread evenly, almost always clustered in one or two markets, one device type, or one set of circumstances. That concentration is the most actionable finding available, because it converts a general performance complaint into a specific request about a specific route, which a vendor can actually do something about.

Retrieval is worse than delivery and the gap is larger than expected. Delivery usually runs acceptably, and the reason is simply that somebody is waiting for it and will say so within hours. Retrieval frequently has a completion rate well below what anybody assumed, with a tail that never completes at all. This is the finding with real money attached and the one the vendor probably hasn't measured either.

Two secondary patterns show up often enough to watch for. Both are useful. Misses cluster at particular times of year, usually around holiday periods in the destination market, which is predictable and plannable rather than a service failure. And a proportion of apparent vendor delays turn out to be internal: orders placed late, addresses supplied wrongly, approvals pending. That proportion is typically between a fifth and a third, and finding it is uncomfortable and valuable, because it's the part you can fix unilaterally.

The internal share is also why the late-order column matters. A service conversation where the vendor can show that a third of your examples were late orders is a conversation you lose, and you lose it having used up the escalation.

Running the Escalation Meeting

If you do escalate, the meeting itself has a shape that works, and it's different from how these conversations usually go.

Send the data beforehand, two days ahead, with no commentary. Just the incidents, dated, with markets. This does two things: it gives the vendor time to investigate rather than defend, and it means the meeting starts from a shared set of facts instead of spending its first half establishing them.

Open with the pattern rather than the incidents. Seven of our nine misses over the last six months were in one market, and all seven of those involved a cross-border shipment. That's a sentence the vendor can engage with. A list of complaints is a sentence they can only apologise for.

Bring the person who owns the operation. Not the most senior one available. Equipment service problems are fixed by somebody changing a carrier or a route, and that decision is made by an operations manager rather than by whoever attends escalation meetings. A meeting with the right person present and nobody senior usually achieves more than the reverse.

Ask for a cause before asking for a fix. If they can explain why the market is slow, the fix usually becomes obvious to both sides, and a fix the vendor proposes is implemented more reliably than one you demand.

Then land four things in writing before the meeting ends: what's changing, who owns it, when you'll both look at the numbers again, and who you contact when the next one happens. The review date is the item that most often gets omitted and most determines whether anything actually changes.

And say what happens if it doesn't improve. Not as a threat, as a plan: if the median in that market hasn't moved by the review, we'll look at alternatives for that market specifically. Market-specific is more credible than a general warning and it's also what you'd actually do.

When the Problem Is the Category, Not the Vendor

Worth saying plainly, because it is the conclusion most companies reach after measuring and it is rarely what they expected.

Equipment logistics is genuinely hard in a way that software is not. A laptop has to physically reach a specific person at a specific address in a specific country, through customs processes that differ per route, delivered by a third party the vendor does not control, to somebody who may not be in. Retrieval has all of that plus an unmotivated counterparty. Nobody in this category has solved it completely.

Which means a median delivery time you find disappointing may be close to the best available, and switching vendors to improve it produces a migration, a new learning curve, and roughly the same numbers.

Three signs the problem is the category rather than your vendor. Look for all three. Your misses are concentrated in markets that are objectively hard, usually ones with slow customs or limited courier coverage, rather than spread across easy ones. Your delivery performance in your main markets is solid and only the edges are weak. And when you ask other companies of similar shape, their numbers look like yours.

Three signs it is your vendor. Misses in markets that should be straightforward. A retrieval completion rate well below what others report. And an inability or unwillingness to explain the cause of a documented pattern, which is the clearest signal of all, because a competent operator can always explain their own failures.

A category problem needs a different response from a vendor problem. Entirely different. You change your own expectations and processes: longer stated lead times for hard markets, a deeper spare pool, hiring plans that account for equipment timing, and honest communication to new starters about what to expect. None of that is satisfying and all of it works better than a switch that changes nothing.

The honest communication part does more than it looks. A new starter in a hard market who is told at offer stage that their laptop will take about three weeks and here is what they will use in the meantime has a fine first week. The same person told nothing, expecting a machine on day one, has a bad one, and the delay was identical. That is the only part of this problem you control completely, it costs one sentence in an onboarding email, and it converts most of what people experience as a service failure into a planned arrangement.

Which is worth weighing before any switch. If you measured, found the median acceptable, found the tail concentrated in genuinely hard markets, and have never told a new starter what to expect, the cheapest available improvement is not a different vendor. It is the sentence.

That conclusion is unsatisfying. So the test is worth stating plainly. Before switching, ask whether you have done the four things you control: told new starters what to expect, held enough spares to cover the markets that run long, stopped placing orders late, and confirmed delivery addresses before shipping. A company that has done all four and still has a problem has a vendor problem. A company that has done none of them has an internal one wearing a vendor's name, and changing suppliers moves it rather than fixing it.

The Cost of Getting This Wrong

The direct cost of a late laptop is a few days of somebody working on a borrowed machine, which is real and recoverable.

The larger cost is the pattern nobody sees. An arrangement where misses are absorbed individually and never counted has no mechanism for improvement, so whatever rate you're running at is the rate you'll keep running at for the length of the contract. Over three years that's a lot of individually forgivable incidents.

Second is the renewal position. Companies renew equipment contracts without any service data, which means the negotiation is about price alone, from a position with no evidence. A documented service record is the only bargaining position that exists in this category and it costs ten minutes a month to create.

Third is the retrieval tail. That is the one with actual money in it. Devices that never come back, written off one at a time, in a process nobody is measuring. At any meaningful scale that's a number worth knowing, and almost nobody running one of these arrangements knows what theirs is.

And fourth is the escalation spent badly. Raising a service complaint without data gets an apology and uses up the one moment when the vendor was paying attention. The second escalation always lands softer than the first.

So the question worth asking isn't whether the vendor missed. It's whether you could prove it happened nine times.

When You're Ready to Move Beyond Reacting to the Last Incident

The signal is somebody asking how often this has happened and nobody being able to answer.

What replaces it is a spreadsheet and a quarterly look. One row per delivery and per retrieval, with dates and markets. A quarterly review of the two medians and the completion rate. A read of the actual contractual standard, done once, so you know what you're measuring against. And a stated position that escalation requires three things, those being a pattern, a cause and an ask, with none of the three optional. Three things.

That's it. Ten minutes a month and one hour a quarter, and it converts every future service conversation from an exchange of impressions into a discussion of a specific route in a specific market.

RemoAsset is our own product. So weigh this accordingly, including the fact that we appear in the comparison above. The relevant part is narrow: delivery and retrieval dates recorded against each device as they happen, so the record exists independently of anybody's monthly report. It has no network discovery, so it covers devices it handles rather than everything you own, and no software licence management.

If you had a late delivery this month, write it down somewhere you'll find it in six months. That single habit is worth more than any escalation.

Frequently Asked Questions

Count the incidents while they are happening, because you cannot reconstruct them later.