Who Ships the Laptop When Someone Is Employed Through a Provider

TL;DR

• Provider selection runs on coverage, price and payroll. Almost nobody asks who ships the laptop, and the answer shapes four of your own processes.
• This article is about logistics and systems only. How any arrangement works legally, and what anybody is obliged to do, differs by jurisdiction and by circumstance, so take local advice on that rather than relying on an article.
• The structural problem is that your register wants to link a device to a person who may not exist in your HR platform.
• The data question is unaffected by the arrangement. Company data on a device is company data, and encryption at deployment is what makes that cheap to resolve.
• The return is where this breaks, because your offboarding process fires from your own records and a departure may be recorded somewhere else first.
• Settle five things in writing before the first person starts, and the whole area becomes ordinary. Settle none and every instance is improvised.

The Laptop That Was Nobody's Job

A company brought on four people in two new markets through a provider. The selection process had been careful: three providers compared, coverage checked market by market, payroll handling reviewed, pricing negotiated.

The first person's start date arrived and nobody had ordered a laptop. Not through oversight exactly. The IT team had assumed the provider was supplying hardware because the provider supplied everything else. The provider had assumed the company was supplying it because nothing in the agreement mentioned devices. Both assumptions were reasonable and neither had been tested.

The gap was not in anybody's process, it was between two processes, and it only became visible on a date that could not move. The machine that eventually arrived was bought locally by the person themselves and reimbursed, which solved the immediate problem and created three more: no serial in the register, no enrolment in device management, and a device holding company data that the company had no record of and no way to clear.

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

Eighteen months later that laptop was still the only machine in the company with no asset row. That is the shape of this problem. It is not complicated, it is just unowned.

What This Article Does and Does Not Cover

Worth being explicit, because the two halves of this question get conflated constantly and only one of them belongs in a software and operations publication.

Not covered here: how any arrangement of this kind works legally, who employs anybody, what obligations sit with whom, what any arrangement transfers, or what any law, regulation or regulator requires, permits or prohibits. Those answers differ by jurisdiction and by circumstance, they change, and the right source is local advice for your own situation. Nothing in this article should be read as describing any of it.

Covered here: who places the order, who pays the invoice, whose register holds the serial number, which device management console the machine enrols into, who holds the delivery address, who arranges the collection at the end, and in which system a departure is recorded first. Those are operational questions with operational answers, and they are the ones nobody asks during provider selection.

So every recommendation below is about sequence and record-keeping. Where a question touches entitlement, obligation or anything resembling a legal position, the honest answer is the same one: that is a question for local advice, and it should be settled before the arrangement starts rather than during it.

The Three Arrangements in Practice

You ship the device

You buy it, you enrol it, you ship it, it sits in your register, and you arrange the collection at the end.

Right when the person needs the same access and the same tooling as everybody else, which is most of the time, and when you already ship hardware internationally for your own staff. It gives you one fleet, one register, one management console and one data story.

Where it struggles: shipping to a market you have never shipped to, and arranging a collection from a residential address in a country where you have no presence. That is the same problem any distributed company has, and it is slightly harder here because your relationship with the person is mediated.

The provider sources it

The provider supplies hardware as part of its service, often locally.

Right when the market is one you genuinely cannot ship to, or where local supply is dramatically faster. Fast to arrange and it removes the logistics entirely.

Where it struggles: almost everything downstream. The device may not appear in your device management, the serial may not reach your register, the specification may not match your standard, and the arrangement at the end is somebody else's process. Each of those is manageable if you have asked about it and unmanageable if you have not.

The person buys it with a stipend

You give a figure, they buy a machine, you reimburse.

Right essentially never for somebody who needs access to company systems, and defensible only for short engagements with no sensitive access. It is the arrangement the company in the opening example fell into by accident rather than by choice.

Where it struggles: there is no enrolment, no standard specification, no serial in your register, and no mechanism to clear the data at the end because the hardware is not yours. It converts a hardware decision into a permanent gap in your asset records.

The middle row is where most of the ambiguity lives, and the fix is a single sentence in the operational handover rather than anything structural.

When the Simple Answer Is Fine

When it is one person for three months

Short engagement, no sensitive access, browser-based work. A stipend or a provider-sourced machine is proportionate and setting up a shipping route for one laptop is not. Just record that you have done it and why, so the exception is visible rather than invisible.

When the market is one you already ship to

If you have people in that country already and a working route for hardware, use it. The arrangement with the provider does not change your logistics, and treating it as though it does is how companies end up with two device standards in the same market.

When the person will not touch company systems

Rare and worth testing rather than assuming. If somebody genuinely works only in a tool the provider administers, your device question largely disappears. The test is whether they will have an account in anything you own.

The edge case that forces the full answer

The second person in the same market, or the first person who needs access to something that matters. Either one converts an improvisation into something that needs to be repeatable, and the second is usually what prompts somebody to go and look at what was done the first time.

Five Questions People Ask First

"Who should buy the laptop?" You, in most cases, because every downstream record depends on it. The serial number and the delivery address are both available at exactly one moment, which is the order, and if you are not the one placing the order you will be reconstructing both from a message later. That is the practical argument and it holds regardless of how anything else in the arrangement is structured.

"Does the device go in our asset register?" Yes, if it is your device. The register records what you own and where it is, so a machine you bought belongs in it whoever is using it. If the provider sourced it, then it is not your asset and the right record is a note that the person has a device you do not own, which is a genuinely different row and should look different.

"Can we enrol it in our device management?" If you bought it through a qualifying channel, yes, and you should, because enrolment is what gives you the ability to apply settings, confirm encryption and clear the data at the end. If the provider sourced it locally through a general retailer, automated enrolment is usually unavailable and the fallback is a manual enrolment somebody has to walk through on a call.

"Who arranges the return?" This is the question to settle first and the one most often left open. The practical answer depends on who owns the device, and the practical problem is that your own offboarding process fires from your HR records, which may not be where this person's departure is recorded. See the section below.

"Should they get the same kit as everybody else?" Operationally, yes, and the reason is boring rather than principled: two device standards in one company means two spares strategies, two sets of support knowledge and two resale batches. The visible version of this matters too, since people notice, but the operational argument is sufficient on its own.

The Record Problem Nobody Designs For

Your asset register links a device to a person. That link needs an anchor, and the anchor is almost always an employee identifier from your HR platform.

Somebody engaged through a provider may not have one. Depending on how you have set things up they may be absent from your HR platform entirely, present as a limited record with no payroll data, or present in a separate list maintained by whoever manages the relationship. All three are common and all three break the same thing.

So the register ends up holding a device assigned to a free-text name, which looks fine until the first reconciliation. A free-text name does not match your leaver list, does not appear in your directory export, and cannot be joined to anything. The row becomes permanently unverifiable, which is exactly the state this publication keeps describing as the thing that destroys a register's credibility.

Three ways out, in order of preference.

Create a record in your HR platform with a distinct record type. Not an employee record, a separate type with its own identifier. This gives you one directory, one anchor and one place to see everybody who has a device. Ask what such a record costs before assuming it is free, because many platforms price a non-employee record at the full per-employee rate.

Hold the population in one maintained list with stable identifiers. A sheet is fine. What makes it work is that each person has an identifier that does not change and that the register uses, so the join is possible even though the list is manual.

Use the device's own identity as the anchor instead. Record the serial, the market, the provider and the engagement dates, and accept that the person is a label rather than a key. Weakest of the three and still better than free text, because the engagement dates give you something to reconcile against.

The Return, Which Is Where This Breaks

Every part of this is manageable except the ending, and the ending has a specific structural fault.

Your offboarding process fires from a date in your HR platform. For somebody engaged through a provider, the departure may be recorded in the provider's system, and it may be recorded there first, and in some arrangements you may learn about it with very little notice. None of that is anybody behaving badly; it is just a different system holding the trigger.

Three consequences follow.

Nothing starts. No ticket, no equipment message, no collection booking, because the event that normally starts them happened somewhere you do not watch.

You may not have an address. For your own staff you hold a delivery address because you shipped something to it. If the provider sourced the device, you may never have had one, and asking for a home address after somebody has finished is awkward and sometimes refused.

The access review misses them. This population is the one most likely to retain access, for the same reason contracted individuals are: access is removed by a process attached to leaving employment, and this person's leaving event is not in your system.

So the fix is to create a trigger you do watch. Four options, cheapest first.

Ask for notice in the operational handover and name a recipient. A named person at your end who is told, by email, on a defined timescale. Crude and it works.

Reconcile monthly against the provider's active list. Whoever manages the relationship already receives or can request a list of current people. Compare it to your device assignments and act on the difference. Ten minutes a month.

Set an engagement end date in your own records and review it. Where engagements have defined terms, this gives you a date to watch without depending on anybody telling you anything.

Time-bound the access at the point of granting it. Where your identity provider supports it, set expiry to the engagement end date. This is the only option that prevents the access problem rather than detecting it, and it is the same mechanism that works for contractors.

How to Choose: Five Questions Before the First Person Starts

Do you already ship hardware to that market? If yes, use your existing route and keep one fleet. If no, this is the one genuine argument for letting the provider source the device, and it should be a deliberate exception rather than a default.

Who will place the order? Decide explicitly and write it down, because this single answer determines whether the serial and the delivery address enter your records at the only moment they are reliably available.

Where will the person exist in your systems? HR platform with a distinct record type, a maintained list with stable identifiers, or not at all. Pick one before the register needs an answer, because the register will accept free text and you will not notice for a year.

How will you learn that an engagement has ended, and how much notice will you have? Ask the question during selection rather than after. A provider that answers precisely is telling you something useful, and the answer determines which of the four triggers above you need.

Will they have the same specification as your own staff? Decide on operational grounds. Two standards in one market is a spares problem, a support problem and a resale problem, and it is also the version of this that people notice.

The Options in Practice

The hardware side of this is a logistics question and the market for it is the same one any distributed company uses. None of these vendors publishes a price, which is worth planning around.

Your existing shipping route

Best when the market is one you already serve. Nothing new to buy, one fleet, one register, one management console.

Where it struggles: a market you have never shipped to, and residential collections in a country where you have no presence.

A lifecycle platform

Best where you want one relationship covering purchase, configuration, delivery and later collection across several markets, including the ones you cannot reach yourself.

Workwize, Deel IT, Firstbase, GroWrk and allwhere all operate here to varying depth, and all of them quote on request rather than publishing figures. For this use case the capability that matters is collection from a residential address in the markets you are entering, so ask market by market rather than accepting a coverage map.

Where they struggle: pricing opacity means comparing three of them is three sales processes before you have a budget number.

The provider's own hardware offering

Best for a market you genuinely cannot reach, or where local supply is much faster.

Where it struggles: specification control, enrolment eligibility, and the serial reaching your register. All three are fixable by asking, and none is fixable afterwards.

RemoAsset

Disclosure: RemoAsset is owned by the same people who publish HROpsLab. It is relevant to this specific problem because it places the order, which means the serial and the delivery address are captured from the order rather than reconstructed later, and that is precisely the gap the opening example fell into. 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 first column is the one that should decide it, because every downstream record in this article hangs off whether the serial and the address were captured at the order or reconstructed from a conversation afterwards.

The Decision Table

The Five Things to Settle in Writing

Not a contract and not a legal document. An operational handover, one page, agreed before the first person starts. These are the five questions that each cost a week of improvisation if left open.

Who places the device order, and who pays the invoice. Two separate answers and both matter. The order determines where the serial and address come from; the invoice determines whose asset it is and therefore whose register holds it.

Whether the device enrols in your device management, and if so how it will be bought. Automated enrolment requires a qualifying purchase channel, so this answer constrains the previous one. If the provider is sourcing locally from a general retailer, assume manual enrolment and plan the call.

Who holds the delivery address, and whether you can have it. This is the field that decides whether a collection is possible at all. If you cannot hold it, say so explicitly and record that the collection is somebody else's to arrange.

Who is told when an engagement ends, by what route, and with how much notice. A named person at your end, not a team, and a route that is not a conversation. This is the trigger for everything in the previous section.

What happens to the device at the end, and who arranges it. Including the case where it does not come back. Decide now what you will do rather than deciding it while somebody is already gone.

And add a sixth line that is not a question: the specification standard, stated, so the device parity decision is made once rather than per person.

When You Have to Enrol a Machine by Hand

Twice above the fallback is a manual enrolment, so it is worth saying what that actually involves, because a company meeting it for the first time on somebody's first morning will spend longer than it needs to.

The work is not technically difficult. It is that each step requires the person in front of the machine to do something, and they have never done it, and you are describing it over a video call across a time zone gap.

Expect four stages. Creating or claiming the local administrator account, which is where a device bought from a general retailer usually starts with a consumer-style setup already completed. Installing the management agent, which needs a download link that works in their market and a credential they can type. Applying the baseline, which includes disk encryption and is the one step that genuinely matters. Then the application set and the sign-in, including second-factor enrolment.

Three things cut it roughly in half. Send written instructions with screenshots the day before rather than talking somebody through it live, because reading at their own pace is faster than listening. Have the encryption step verified explicitly and recorded, since it is the step that determines whether you can ever clear the device remotely. And book 90 minutes rather than 30, because a session that overruns into somebody's afternoon is worse for them than one that was scheduled honestly.

And record the serial at the end, in the register, with the person's identifier. That is the whole reason the exercise is worth doing properly: a manually enrolled device with its serial captured is an ordinary asset row, while the same device without it is the permanent gap described earlier. One field, typed once, at the only moment somebody is looking at the machine.

Running the Reconciliation That Tells You Where You Are

This article keeps saying to compare the provider's active list against your own device assignments. Here is the exercise, because it is 20 minutes and it produces the only honest number available on this population.

Get three lists. From whoever manages the relationship, every person currently engaged through the provider, with their market and their start date. From your asset register, every device assigned to anybody who is not a payrolled employee. From your identity provider, every account that has signed in during the last 90 days and is not matched to an employee record.

Match them on email address rather than on name, because name matching produces false pairs across markets with different naming conventions and a reconciliation with false pairs gets abandoned halfway.

Then count four buckets separately, because each has a different cause and a different fix.

Engaged, with a device recorded, with an active account. The population that is working as intended. Check only that each device row has a serial rather than a free-text description.

Engaged, with an active account, with no device recorded. The opening example's bucket. Each one is a machine holding company data that you cannot report on, confirm encryption for or clear at the end. Count them and note whether the device was provider-sourced or bought on a stipend, because those need different remedies.

No longer engaged, account still active. The security finding, and the one most likely to be non-zero. Note how long each has been over, because a handful at 30 days is a notice problem while several at a year is a missing process.

Device recorded against somebody nobody recognises. The free-text row that cannot be joined to anything. These are the oldest entries and usually the hardest to resolve, because the person who set them up has moved on.

A company with 14 people engaged this way across 4 markets will typically find something in at least two of those buckets on a first pass, and the distribution is the argument for whichever fix you choose. Write the four counts down with the date, then re-run it in a quarter with the same method, because one measurement is a fact about one day and two is a trend.

And resolve bucket three first, not bucket four. Removing active accounts for people who have finished takes minutes and reduces real exposure; reconstructing a two-year-old free-text row feels more thorough and changes nothing anybody is at risk from.

What a Specification Standard Actually Contains

The operational handover has a line stating the specification standard, and that line is worth more than it looks because it is the thing that prevents the parity argument from being had 14 separate times.

It does not need to be long. Six fields, on one page, by role rather than by seniority.

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

Memory and storage, as exact figures rather than minimums. A minimum produces a fleet with 6 or 7 different configurations inside two years, which is a spares problem and a resale discount.

The operating system and the enrolment requirement. Including the statement that the device must be purchased through a channel that supports automated enrolment, which is the constraint that quietly rules out the cheapest supplier in most markets.

The peripherals that are standard and the ones that are on request. A monitor, a dock, a keyboard and a headset is a typical standard set. Being explicit stops each new person's manager negotiating it individually.

The refresh interval. So somebody engaged for 30 months knows where they stand and so your own planning has a date rather than an intention.

What happens to the kit at the end, in one sentence. Returned and collected, retained, or purchased. State it here so it is known on day one rather than raised on the last day.

Then apply the same document to your own employees in that market. Because the moment the standard differs by how somebody is engaged rather than by what they do, you have written down the two-tier arrangement you were trying to avoid, and it will be read exactly that way by anybody who sees both versions.

What Getting This Wrong Costs

The visible cost is the first person's start date, and it is the smallest of three.

The second is a permanent gap in your records. A device with no serial in your register is not a tidiness problem; it is a machine you cannot report on, cannot confirm the encryption state of, and cannot evidence the data destruction of. One such device is an anecdote. Because the arrangement that produced it was never corrected, the second and third arrive the same way, and a company with eight of them has a measurable hole in every answer it gives about its fleet.

The third is the access population. People engaged through a provider are, structurally, the group most likely to retain access after they stop working, because the removal process is attached to an event that happens in somebody else's system. That is the finding that shows up in a customer security questionnaire, and the honest answer at most companies is that nobody has compared the two lists.

The reframing question: if a customer asked for a list of everybody with access to their data and the date each person's access ended, would the people engaged through a provider be on it, and which system would you open to find out?

When You're Ready to Make This Routine

The honest position is that this is not a hard problem and it is reliably an unowned one. It sits between IT, HR and whoever manages the provider relationship, and each of those three can see most of it while nobody sees all of it.

The trigger worth acting on is the second person in the same market. The first instance gets improvised and that is fine; the second is the point at which the improvisation becomes a precedent, and precedents set by accident are the expensive kind.

The sequence costs an afternoon. Write the one-page operational handover with the five answers above and the specification line. Decide where these people exist in your systems and give them stable identifiers, so your register has something to join on. Run one reconciliation between the provider's active list and your own device assignments, and count the differences, because that number is the honest state of things today.

Then ask your identity provider whether time-bound access is available, since a yes solves the hardest part of this by construction. And settle anything touching entitlement, obligation or notice with local advice before it becomes a live question rather than after, because that is the one part of this article that genuinely cannot be worked out from first principles.

Frequently Asked Questions

HROpsLab takes no vendor money and publishes no paid placements, which is why this article states plainly which questions it will not answer rather than answering them badly.