Zero-touch is the floor now, and the last mile is somebody's living room

The best onboarding automation I ever shipped was beaten by a dongle.

Everything upstream of that dongle worked perfectly. The laptop was ordered, auto-imported into the vendor's business portal, auto-assigned to our MDM, asset-tagged by the reseller with the serial pushed into our hardware asset system by API, and drop-shipped to a house I have never seen. No IT hands touched the box. The new hire unboxed it, signed in with credentials that already existed in our identity provider, and roughly half an hour later she had a working desktop with her apps on it.

Then she went to plug in her monitor and had the wrong cable.

So she waited, on the entirely reasonable assumption that somebody would follow up. Nobody did. Every dashboard we owned was green, because by every measure our tooling understood, the onboarding had succeeded. Three weeks later her manager mentioned it offhand.

I think about that far more than I think about any provisioning benchmark I have ever run.

The numbers that ended the internal argument

For about two years, one org with roughly 1,400 users could not ship a computer directly to an employee. Their PC process was fully manual re-imaging, which required knowing whose machine it was before it shipped, which meant every device stopped at an IT desk first. Two hours of hands-on prep per unit. Then over an hour of the employee's own time at the other end.

The same pipeline now costs zero IT hands-on time and about thirty minutes of end-user setup, unboxing to usable desktop, contingent on decent home Wi-Fi. Hold onto that last clause. It turns into the whole story later.

What actually settled the argument internally was a hiring surge: about 70 new Mac hires onboarding simultaneously. The team's own assessment of doing that under the old process is that it would not have been possible. Not painful. Not slow. Seventy devices times two hours of prep is most of a month of one person's working life, and the new hires were not going to wait a month for a laptop.

Their fleet moved from around 300 Macs against about 1,000 PCs to roughly 845 Macs against 543 PCs. The zero-touch rollout began with customer service and claims, over 700 users, about half the company.

The detail I repeat to people is how that team won internal buy-in. Not with a vendor deck. They pulled their own support-ticket history and showed fewer audio and driver problems on one platform than the other across their call-taker fleet, measured in their own queue. Nobody argues with your own tickets.

Fast enough that speed stopped being interesting

Ten apps, several of them large, including Citrix Workspace and CrashPlan. A purpose-built onboarding tool installed the set in an average of 3 minutes 9 seconds, best run 2:38. The identical ten through a hand-rolled Installomator loop averaged about 15 minutes 29 seconds across three runs of 12:39, 16:12, and roughly 18:00. Call it 5x.

The number that should bother you more is the steady-state one. Re-running that loop against a fully up-to-date set of the same apps still burned about three minutes to establish that nothing needed doing.

None of the gap is magic, and the four ideas behind it show up in every good first-run tool:

• Downloads run concurrently rather than serially, so nothing waits for install A to finish before download B starts.
• Retries use exponential backoff, three attempts, on the assumption that network blips during enrollment are normal rather than exceptional.
• Every payload is checksum-verified against a maintained catalog, 770-plus apps in this case, so a corrupted download fails loudly instead of installing garbage.
• Runs are idempotent. Anything already present and current gets skipped rather than re-downloaded to prove a point.

The best deployments then go a step further and push both a configuration profile and an installer package during Setup Assistant itself, before the user account even exists. Installs are already running in the background while somebody is still picking a keyboard layout. By first login, most of the software is there.

I filed all of this under "nice optimization" for a long time, and I was wrong about why it matters. Shaving twelve minutes off a desk-side build is a rounding error. Shaving twelve minutes off two hundred simultaneous residential internet connections is a capacity plan.

Which brings us to somebody's living room

Once IT stops touching the hardware, every remaining variable lives in a house you cannot inspect.

Start with the failure mode that a lot of provisioning design now exists to survive: the user closes the laptop lid mid-download. It is day one, they were told setup takes half an hour, they need to move the car or feed a small child, and the machine sleeps with four of ten installers half-fetched. Caching and retry logic exist precisely so that this stops being a ticket.

Then bandwidth. One team tested a mass onboarding event with 50-plus devices setting up at once and saturated their own office Wi-Fi doing it. In an office. With enterprise access points and a real uplink. Their response was to publish a minimum home-internet baseline of about 50 Mbps as a prerequisite for remote setup, and I have defended that position in meetings while feeling faintly uncomfortable about it. It is a legitimate technical requirement. It is also IT declaring that part of somebody's apartment is now part of the deployment surface, and we should at least say that out loud rather than burying it in a wiki.

The practical version of the same problem is throttling that changes with context: cap concurrent downloads to one or two on office Wi-Fi during a mass event, uncap them at home where the machine has a whole circuit to itself. Any tool that hard-codes one concurrency number has not met your network.

And then there is intern season, which is the purest form of this. Hundreds of people start on the same Monday, all default to the same platform, and all pull the same enormous installer inside the same twenty minutes.

Dongles, docks, and the form I used to think was busywork

This is the unglamorous half of remote onboarding, and it decides more outcomes than your MDM configuration does.

Pre-tested peripheral bundles, shipped as a set. One team standardized on a dock, keyboard, and mouse combination verified to work across both platforms, specifically so that changing somebody's laptop platform did not also mean re-buying their accessories. Boring. Effective.

Second, a form. A short intake asking each remote employee exactly which peripherals and cables they already have, so IT can identify the person who is going to need a USB-C dongle before the laptop ships instead of three weeks after. I used to think collecting that was make-work in spreadsheet form. See the opening of this article for my current position.

Third, and this one costs organizations real money: shipping new hardware without an explicit "return the old device within X days" policy. What happens next is exactly what you would predict. The new machine gets set up, the old one becomes a shelf ornament in a spare bedroom, and your asset register slowly turns into fiction.

Let them watch

Post-login, show a progress list. Every app, every script, in order, with state.

The payoff arrives when it hangs on item seven of twelve. A user who can see item seven tells you "it's stuck on Zoom," and you hand them a bypass code to get onto the desktop and sort the remainder out later. Without that view, the ticket says "my computer is loading" and your first ten minutes go to establishing where in a fifteen-step sequence the machine actually is.

Two more cheap things in the same spirit.

Link the platform vendor's own official documentation inside your knowledge base instead of writing yours from scratch. Apple maintains better first-run docs than you are going to, they get updated without your involvement, and the hours you save go to the twelve documents only you can write.

Then record a private walkthrough video. Not screenshots. A remote new hire in a kitchen with a toddler attached to one leg needs to pause, deal with the toddler, and rewind ten seconds. A screenshot cannot do any of that.

Cohorts of 25 to 50, and a week and a half of overlap

Migrating existing users is a different job from onboarding new ones. The same team ran it in chat-channel cohorts of 25 to 50 people, each cohort with its own channel, and waited until roughly 85 to 90% of a cohort had migrated and returned old hardware before starting the next wave.

They also gave people an overlap window: a week to a week and a half holding both machines, rather than reclaiming the old one on day one.

That overlap is what I would fight for in a budget meeting. Some of these users had multiple decades of muscle memory on the other platform. What they needed was less training than safety net, for the specific afternoon when they cannot find the thing they need to find and there is a customer on the line. Given that net, almost nobody rejected the new platform outright.

Two permanent mistakes

Most onboarding mistakes are recoverable. These two are not, or not cheaply.

Hardware bought outside the pipeline. A device purchased through some other channel and never added to the vendor's business portal has to be enrolled manually and interactively, and it permanently loses the management capabilities tied to automated enrollment. You cannot retrofit that by adding the serial number afterward. It is a small mistake with a permanent tail, and it usually happens because somebody in a hurry bought a laptop at retail on a Friday.

Personal accounts on company hardware. An employee signs into a corporate device with their personal Apple ID, gets terminated eight months later, and never releases the activation lock, because by then they have no reason to care. Before release-by-purchase-record existed, untangling that meant a 30 to 90 day proof-of-purchase process. There is no version of that story where anyone has a good week.

The part we were wrong about

For most of the last decade, provisioning was the interesting problem, and it deserved to be. Imaging was miserable, golden images went stale the week after you built them, and every new hire cost somebody an afternoon with a USB stick.

That problem is solved. Not solved for everyone and not solved for free, but solved in the sense that the techniques are known, the tooling is mature, and a competent shop can take a stranger from sealed box to working desktop in half an hour without ever touching the hardware.

What we found underneath was that the machine was never the hard part. The hard part is a house with 12 Mbps DSL, a cable nobody thought to ask about, a lid closed at the wrong moment, an old laptop that never came back, and a person sitting alone in a kitchen on day one wondering whether they are supposed to be worried yet.

Those are mostly not engineering problems. They are logistics, communication, and follow-up: the three things IT has always been worst at and has always been judged on. Zero-touch did not remove them. It removed everything that used to hide them.

---

Foqal builds conversational IT support for Slack and Microsoft Teams, so the day-one questions a new hire is embarrassed to file a ticket about reach a human anyway.