Kitting Out People Who Will Be Gone in Twelve Weeks

TL;DR

• A laptop has three or four years of useful life. A twelve-week engagement consumes about 6 per cent of it, so buying new is the worst of the four available options.
• Reuse from a spare pool is the right answer and most companies do not have a pool, which is why they buy new and then wonder why the cost per intern looks absurd.
• Interns arrive as a cohort and leave as a cohort, which makes this a procurement spike and a recovery spike rather than a steady trickle.
• Fixed-term means you know the end date on day one. Time-bound access set at the point of granting is free and almost nobody does it.
• Return rates for short engagements are worse than for employees, because there is less relationship to draw on. Collect on the last day, not after it.
• The specification test is whether the machine runs the tools, not how old it is. A three-year-old laptop that works is fine; one that costs somebody an hour a day is not.

Ten Laptops in June and Nine in September

A company ran an intern programme for the third year. Ten people, twelve weeks, starting the same Monday in June.

Procurement went well. Ten machines ordered in April, all arrived, all configured, all ready on day one, which is better than most companies manage for their permanent starters.

September was different. The programme ended on a Friday, the managers who had hosted the interns had already moved on to their own work, and nobody owned the collection. Six machines came back in the following fortnight. Three more arrived over the next two months after chasing. One never came back at all, and by the time anybody noticed, the person had finished a master's degree and moved country.

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 programme had a procurement owner and no recovery owner, and the recovery was the half with the money in it. Nine of the ten machines were nearly new and immediately reusable; the whole cost of the programme's hardware was sitting in a decision nobody had been assigned. The following year the same company issued three-year-old machines from a pool it had finally built, recovered all ten on the last Friday in a single morning, and spent nothing.

The Arithmetic Nobody Runs

Take a laptop with a useful life of three and a half years. A twelve-week engagement uses roughly 6 per cent of it.

Buying a new machine for that engagement means the company has paid the full cost and consumed a sixteenth of the value, and the remaining fifteen sixteenths is sitting in a device whose next destination nobody has decided. That is not a procurement problem, it is a reuse problem, and it only looks like a procurement problem because the purchase is the visible event.

Three things follow.

New purchase is the worst option available, and it is the default. It is the default because it is the easiest thing for a procurement process to do, and because the alternative requires a pool that somebody has to have built in advance.

The value is almost entirely in the return. For a twelve-week engagement, whether the machine comes back matters roughly sixteen times more than what was paid for it. So a programme that optimises the purchase and ignores the collection has optimised the wrong end.

Reuse compounds. A machine used by four successive interns over two years has delivered its whole life to the company at one purchase price, which is the same arithmetic as any refresh cycle and is simply never applied to short engagements.

When Buying New Is Actually Right

When the work genuinely needs current hardware

An engineering internship on a project that compiles, renders or runs virtual machines may genuinely need a current machine, and a three-year-old laptop that costs somebody an hour a day is a false economy twelve weeks long. The test is whether it runs the tools at a reasonable speed, which is a question you can answer by trying it rather than by reading a specification.

When the engagement is long enough to be ordinary

A twelve-month fixed term is not a short engagement, it is a third of a device's life, and it should be treated like any other assignment. The arithmetic in this article applies below roughly six months and stops being interesting above it.

When you have no pool and no time

Honest exception. If the cohort starts in three weeks and you have nothing to reuse, buy the machines and build the pool from those same machines afterwards. The mistake is doing this three years running without ever building the pool, which is the situation most intern programmes are in.

The edge case that forces a rethink

A cohort that doubles. Five interns is a manageable improvisation and ten is a programme, with a procurement spike, a configuration spike and a recovery spike all landing on known dates. The moment the cohort reaches roughly eight people, the informal arrangement stops working in all three places at once.

Five Questions People Ask First

"Is it fair to give an intern an older machine?" Yes, if it works properly, and the framing matters. A current-generation machine for twelve weeks is a cost nobody can justify, and a three-year-old machine that runs everything quickly is indistinguishable in daily use. What is not fair is a machine so slow that somebody spends their short engagement fighting it, and that is a test you can run rather than a judgement you have to make.

"Can they use their own laptop?" For anybody touching company systems or data, treat this as a last resort rather than an option. There is no enrolment, no encryption guarantee, no way to apply settings and no mechanism to clear anything at the end, which means the engagement ends with company data on a machine you have no relationship with. If it is genuinely unavoidable, the controls available are account-level only and you should record that you accepted the risk.

"Should we rent instead of buy?" For a cohort, sometimes, and the arithmetic is better than people expect because rental is priced against the period rather than the asset. It is most attractive when the cohort is large, the work needs current hardware, and you have no pool. It is least attractive when you already hold reusable machines, since renting while owning idle stock is the worst of both.

"Who collects the machines at the end?" Name them before the cohort starts, and do not make it the hosting managers, because the programme ending is the moment their attention returns to their own work. This single assignment is worth more than every other decision in this article.

"What about the data at the end?" Ten devices means ten recorded wipes, with a date, a method and a person each. For a cohort this is one afternoon if the machines come back together and an ongoing irritation if they trickle in, which is another argument for collecting on the last day.

The Four Options

The first row is the recommendation and the fourth is the one companies drift into when the first is unavailable and nobody planned. The gap between those two outcomes is a pool that costs nothing to build because it is funded from machines you already own.

Building the Pool From Machines You Already Have

This is the part that makes everything else cheap, and it requires no budget.

Every company with any turnover recovers machines. Those machines sit somewhere while nobody decides what to do with them, and a short engagement is the single best destination for a device that is too old to issue to a permanent employee and far too good to dispose of.

Four rules make a pool work for this purpose.

Take machines at the point they leave the permanent fleet, not later. A device recovered and triaged on arrival is a known quantity. The same device after fourteen months in a cupboard is an unknown one, and it will also be two refresh cycles behind rather than one.

Wipe on arrival and record it. The pool then carries no data obligation at all, and a machine can be issued the same day somebody needs it rather than needing a day of preparation.

Test against the actual tools once, and label the result. Not a specification sheet. Open the applications an intern will use, use them for ten minutes, and mark the machine suitable or not. A pool of machines with an unknown usability state is a pool nobody will issue from under time pressure.

Hold them in the market where the cohort will be. A pool in the wrong country is not a pool, and for a cohort arriving in one office this is easy, which is why intern programmes are the best possible first use of a regional pool.

So the size is straightforward: enough for your largest cohort plus one, which for most companies is a number between 4 and 12 machines. Because they are devices you already own and were going to hold anyway, the only new cost is somebody labelling them and somewhere to keep them, and the alternative is buying the same number of new laptops every June.

The Cohort Problem

Short engagements in ones and twos are easy. A cohort is a different operational shape and it fails in three places at once.

The procurement spike. Ten machines needed on the same Monday, which in a market with a five-week lead time means ordering in April for June. Most companies get this right because the start date is visible and somebody owns it.

The configuration spike. Ten devices to enrol, ten accounts to create, ten access grants, in the same week. Zero-touch enrolment turns this from a week of work into an afternoon, which is the strongest argument for it that exists and the one least often made.

The recovery spike. Ten devices back on the same Friday, and this is the one with no owner. It needs a booked collection or an in-person handover slot, a named person, and a check against a list of ten serials. One morning, if it is arranged. Three months of chasing, if it is not.

And a fourth thing that is not a spike but matters: ten simultaneous access expiries. Because the end date is known on day one, every account can be created with an expiry set to it, which means the access half of offboarding happens by itself for the whole cohort. This is free, takes no longer than creating the accounts normally, and is skipped almost universally.

Collect on the Last Day

Return rates for short engagements are worse than for permanent staff, and the reason is not character. It is that there is less relationship, less time to build a sense of obligation, and no notice period during which somebody is still in contact with you.

So the arrangement that works inverts the usual sequence. Rather than asking for the device after the person has gone, you collect it while they are still there.

In person, if there is an office. A table, a list of serials, a slot in the last afternoon, and somebody ticking machines off. Twenty minutes for a cohort of ten and the recovery rate is effectively 100 per cent.

With a booked collection, if there is not. A courier arriving at their address on a date you have arranged and told them about in advance, with packaging that you sent. Not a request that they organise a return, which is where every distributed recovery stalls.

With a short confirmation either way. One email on the day it arrives, saying the device is back and the data has been cleared. It takes a minute and it closes the loop for somebody who may well want a reference from you later.

And ask for the charger by name. The accessory most reliably lost in any recovery is the power adapter, and a laptop without one is harder to reissue and worth measurably less if it is ever sold.

How to Choose: Five Questions Before the Cohort Starts

How many people, and on which dates? Both ends. The start date drives procurement and the end date drives everything else, including the access expiry you can set for free on day one.

Do you hold machines that run the tools? Test rather than assume, by opening the actual applications on an actual pool machine. This single answer decides between reuse and purchase and it takes ten minutes to establish.

Who collects, and is it anybody other than the hosting managers? Name them. If the answer is the managers, change it, because the programme ending coincides exactly with their attention returning to their own work.

Is there an office they will be in on the last day? If yes, the in-person handover is the whole solution. If no, book the collection before the cohort starts rather than arranging it at the end.

Will this programme run again next year? If yes, the pool is worth building now from this year's machines, which converts an annual purchase into a one-off. Most intern programmes have run three times without anybody making this decision.

The Options in Practice

Your own spare pool

Best for almost every intern cohort and most short fixed terms. Costs nothing beyond labelling and storage, uses machines you already own, and scales to whatever your largest cohort is.

Where it struggles: it has to exist, which means somebody had to divert recovered machines into it rather than leaving them in a cupboard. And it needs the usability test, because a pool nobody trusts is a pool nobody issues from.

Rental or device-as-a-service

Best for a large cohort needing current hardware with no pool available, and genuinely competitive for that case because the pricing is against the period rather than the asset.

The terms to read are the ones about early return, damage and end of term, since a short engagement exercises all three. Ask specifically what happens if a machine comes back three weeks early and what the damage assessment process is, because those two clauses decide whether the arrangement is good value.

Where it struggles: it is poor value if you already hold reusable machines, and the contract administration for a twelve-week cohort is disproportionate to the amount involved.

New purchase

Best when the work needs current hardware or when there is no time to arrange anything else.

Where it struggles: the arithmetic above. It is defensible as a one-off and indefensible as an annual habit, and the difference between the two is whether the machines are collected and pooled afterwards.

Lifecycle platforms

Best where the cohort is distributed rather than in one office, which makes both the delivery and the collection harder than a single-site programme.

Workwize, Deel IT, Firstbase, GroWrk and allwhere all operate here and none publishes a price, so comparing them means several sales conversations before you have a figure. For this use case the capability that matters is a booked collection from a residential address on a date you choose, since that is the step a courier account handles worst.

Disclosure: RemoAsset is owned by the same people who publish HROpsLab. It is relevant to this specific case because it holds devices in region between assignments and reissues them domestically, which is the mechanism that makes a reuse pool work for a distributed cohort rather than only for an office-based one. 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 that explains why most companies end up in row three. A pool is cheapest and requires a decision made months earlier, so the option that wins is the one available on the day somebody remembers.

The Decision Table

The Last-Day Handover, as a Calendar Entry

The recommendation that recovers the most value is scheduling the collection when you schedule the induction. It is worth spelling out as an actual arrangement, because "collect on the last day" is easy to agree with and easy to not do.

Book it in the same hour you book the first-day induction. Same calendar, same owner, both ends of the engagement created at once. If the induction is a recurring annual event, the handover should be the second half of that same recurring event.

Put it at 2pm on the last working day, not 5pm. A 5pm slot competes with goodbyes and with people leaving early, and anything that slips at 5pm slips to never. Mid-afternoon is late enough that work is finished and early enough that stragglers can be found.

Send one message two days before, listing what is expected. The machine by its serial, the charger, any dongle or adapter, and any access card. Naming the items individually recovers more accessories than asking for company equipment, because it removes the recipient's judgement about what counts.

Have the list of serials printed and tick them off. Not a mental count. The gap between what you issued and what arrives is the only number that matters, and it has to be visible in the room rather than reconstructed afterwards.

Confirm each one by email the same afternoon. One line, saying the device is back and the data will be cleared. It takes a minute per person, and for somebody who may want a reference later it closes the engagement properly rather than leaving an open question.

And for anybody who cannot attend, book their courier collection in the same sitting rather than leaving it as a follow-up. A follow-up arranged after the cohort has dispersed is the thing that becomes three months of chasing, and arranging it while you still have everybody's attention costs five minutes.

The Ten-Minute Usability Test

This article says twice to test a pool machine against the actual tools and label the result, so here is the test, because a pool whose usability is unknown is a pool nobody will issue from when somebody needs a laptop tomorrow.

It is not a benchmark. Benchmarks measure the machine and the thing you need to know is whether the work feels slow, which is a different question and a faster one to answer.

Open everything at once, the way a person actually works. The browser with 15 tabs, the chat client, the video call application, the document editor, and whatever else the role uses daily. Not one at a time. The failure mode of an older machine is memory pressure under a realistic load, and a machine that opens any single application quickly can still be unpleasant with all of them running.

Join a real video call with the camera on and screen sharing. This is the single most revealing test for a 3 or 4-year-old laptop, because it exercises the processor, the camera pipeline and the network at once, and it is also the thing somebody will do several times a day. If the fans run constantly and the call stutters, the machine is not suitable regardless of what the specification says.

Time one cold start, from power button to a usable desktop. Under 60 seconds is fine. Over about 3 minutes is a machine somebody will resent twice a day for twelve weeks.

Check the battery health figure and then actually unplug it for an hour. The reported health percentage is a guide and the real test is whether it lasts a meeting. A machine tethered to a desk is a different product from a laptop.

Look at the screen in a normally lit room. Backlights age, and a dim panel is the complaint most likely to be expressed as something else.

Then write the result on a label stuck to the machine: suitable, suitable for light use, or retire. Three values, and the date. Because the test takes ten minutes and the label lasts for a year, this is the highest-return quarter of an hour in the whole pool arrangement, and it is the step that turns a cupboard of unknowns into stock somebody will confidently issue under time pressure.

The Cohort Data-Clearing Run

Ten devices back on one Friday means ten recorded wipes, and doing them as a batch is an afternoon while doing them as they trickle in is a background irritation that never quite finishes. The batch version is worth arranging deliberately.

Do it on arrival, not at the point of reissue. A machine cleared on the day it comes back carries no data obligation while it sits in the pool, which means your storeroom is not an exposure and the device can be issued the same day somebody needs it. Teams that clear at reissue discover that every machine in the cupboard has been holding data since September.

Work from a list of serials, not a count. Ten machines back is not the same as the ten machines you issued. Tick serials off the issue list rather than counting boxes, because the discrepancy is the finding and a count will hide it.

Record four things per device. The date, the method used, the person who did it, and the serial. That is the record a security review asks for, and it is the thing most companies cannot produce for short engagements because nobody treated the cohort as a batch with a register.

Release each device from management and clear any activation lock at the same time. Two minutes per machine, and skipping it is what makes a pool machine unusable for the next person and worthless if it is ever sold. Doing it in the same sitting as the wipe means it happens once rather than being rediscovered a year later.

Note what is missing, particularly the charger. Per device, against the serial. A pool machine without a power adapter is not ready to issue, and discovering that on the morning somebody needs it is the small failure that makes people stop trusting the pool.

So the whole run for ten devices is roughly two hours including the paperwork, and it closes the data obligation, restores the pool, and produces the only evidence you will have that the programme was handled properly. Because nobody is waiting for any of it, this is the work most likely to be deferred and then skipped, which is why it belongs in the same calendar entry as the last-day collection rather than on a list of things to do afterwards.

What Getting This Wrong Costs

The visible cost is the machine that never came back, and at one laptop a year it is small enough that nobody escalates it.

The second cost is the annual repeat. A programme that buys ten new machines every June, uses 6 per cent of each, and recovers them inconsistently has turned a one-off purchase into a recurring line. Because the purchase is approved as part of the programme budget each year, it never appears as waste, and the company can run this for five years without anybody noticing that it owns forty machines it cannot account for.

The third is the access population, and it is the one that shows up in a questionnaire. A cohort of ten people whose accounts were created without expiry dates, whose engagement ended without a leaver process, is ten active accounts belonging to people who no longer work for you. Multiply by three years of programmes and the number stops being small. This is entirely preventable on day one at no cost, which is what makes it the most annoying item in this article.

The reframing question: of the machines issued to short engagements in the last two years, how many are back, how many were wiped with a date recorded, and how many of those accounts are still active?

When You're Ready to Make It Routine

The honest position is that this is not a budget problem and it is not a policy problem. It is an ownership problem with a procurement shape, which is why it keeps getting solved at the purchase end where somebody is accountable and left unsolved at the recovery end where nobody is.

The trigger worth acting on is the second year of a programme. Once is an improvisation; twice is a pattern, and the second year is the point at which the first year's machines are sitting somewhere and could become the pool.

The sequence costs almost nothing. Count what you issued to short engagements over the last two years and how many came back, because that number is the honest state of things and it is usually worse than anybody expects. Divert this year's recovered machines into a labelled pool rather than a cupboard, wipe them on arrival, and test one against the actual tools. Name a collection owner who is not a hosting manager. And set every account's expiry to the known end date at the moment you create it.

Then book the last-day collection at the same time you book the first-day induction, in the same calendar, owned by the same person. Of everything here, that one scheduling decision recovers the most value for the least effort, and it is invisible in every programme plan that does not include it.

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.