Onboarding a new client from a tech's point of view

I've been at Inology just over a year now. In that time I've helped onboard six new clients — small manufacturers, an accountancy practice in Stockport, a not-for-profit near Ashton, a couple of professional-services firms in Manchester city centre. Every one has been different. What has stayed the same is the shape of the first two weeks. Brett and Simon design the shape; my job, as the junior tech on the team, is to walk it. This is what that actually looks like from where I stand.

Day one is a walk, not a login

The first thing that happens on a new-client onboarding isn't a login screen. It's a car journey. Ben or Simon drives, I take the notebook and the label maker, and we go to the client's office. The client's nominated contact — usually the office manager — meets us at reception, and we start walking.

We walk every desk. Every printer. Every meeting room. We go into the comms cabinet, take the door off if it's a stubborn one, and photograph the back of it before we touch anything. We count switches. We note which sockets are patched and which are dead. If there's a server still on the floor from a project that finished two years ago, we ask about it and log it. If there are labels on cables, we photograph them. If there aren't, we make a note that they need to go on before we finish.

I write everything into a paper notebook first — model numbers, serial numbers, user names on Post-it notes stuck to laptop lids. Paper doesn't need a login, doesn't lose signal in the back of a cupboard, and doesn't argue with me when a warehouse Wi-Fi drops. Back at the office it all goes into our records properly. But on the day, it's paper.

What we're actually looking for

Discovery day has a very short list of questions we're trying to answer, and the reason they matter only becomes obvious later. The list is roughly this. How many end-user devices are there really, versus how many the client thinks there are? Who genuinely uses which one? Where is every network device — routers, switches, wireless access points — and which of them is in support? Is there anything on-premises we didn't expect: a file server, a domain controller, an old bit of line-of-business software running on a PC under someone's desk? Are the printers on the network sensibly, or is one of them plugged into a laptop by USB and being shared out?

The answers to those questions change what the next fortnight looks like. If the estate matches the paperwork, weeks two and three are documentation and enrolment. If it doesn't — and it usually doesn't, quietly, in a couple of places — we find that out on day one instead of finding it out when a printer stops working three months in and nobody can remember what it's called.

The bit clients don't see: writing everything down

After discovery day, most of what I do for the next fortnight is desk work. The client won't see much of it, and honestly the value of it doesn't show up until the first time a ticket comes in.

Every device gets a page. Every page has a name, a serial, a model, a user, a location, a purchase date if we can find it, and a note of anything unusual about it — this laptop has a broken hinge, that desktop is running an old accounts package, this printer likes to be power-cycled if it's been off for a weekend. Every user gets a page too, linked to their device, their Microsoft 365 licence and their phone if they have a business one.

The Wi-Fi passwords go into the shared vault. The admin accounts for the firewall, the switches, the phone system and Microsoft 365 all go into the vault too, and any old admin accounts we can't identify get flagged for a conversation with the client. The comms cabinet gets labelled properly, patch panel to patch panel, before we leave the site again. If there's a floor plan, we mark up which access point covers which zone. If there isn't, we draw one.

None of this is glamorous. All of it is the reason that when someone in the client's finance team phones the helpdesk at nine in the morning six months from now and says "the little printer in the back isn't working," the tech picking up the call already knows which printer that is, where it is, what it's called on the network, whose desk it's next to, and what it likes to have done to it.

The three things a previous provider almost always leaves behind

Most of the clients we onboard are moving from another managed IT provider, not from nothing. So the tidy-up work in the first fortnight isn't building from scratch — it's undoing accumulated mess. There are three things I see almost every time, regardless of who the previous provider was.

The first is old leaver accounts. There will be users in Microsoft 365 who left the business — sometimes years ago — whose accounts are still active, still licensed, and sometimes still forwarding email somewhere they shouldn't. The record for the previous ninety days of sign-ins tells the story. We produce a list, sit down with the office manager, and go through it. Most get disabled the same afternoon. A few get kept for archival reasons and moved to a shared mailbox or a cheaper licence. This alone often pays for the first month of our service. It's also, as Brett has written, the single thing most businesses do worst.

The second is unidentified administrators. Someone, at some point, was set up as a global administrator in Microsoft 365 or as the top-level admin on the firewall, and nobody can now tell us who it is. Sometimes it's an ex-employee. Sometimes it's a previous MSP whose access was never revoked when they were replaced. Sometimes it's a partner or a contractor whose engagement finished. Every one of these is a security problem, and the onboarding is the moment they get found and dealt with — the sort of thing that shows up as an obvious gap in a SecureState baseline review a fortnight later.

The third is the comms cabinet. It will not be labelled. There will be cables running to sockets that don't exist any more. There will be a switch nobody remembers buying. There will be, at least once in every three onboardings, a wireless access point powered on inside a locked cupboard doing nothing useful. None of this is anyone's fault; it happens because tidying a comms cabinet is the sort of job that never becomes today's priority. So we do it, and we photograph it done, and it stays done.

Go-live is deliberately quiet

At the end of the two active weeks — usually the fourth Monday from kickoff — we do a handover call with the client. Brett or Simon runs it. I sit in and take notes. We show them the client page we've built, walk them through the new helpdesk address, explain the ticket flow, and hand them a short document that tells everyone in their business how to get hold of us and what to expect.

Then it goes live, and honestly it should be a non-event. If we've done the two weeks well, nobody in the client's business notices anything has changed except the email address on the "IT support" poster in the kitchen. The first ticket comes in — it's usually a printer, or a password reset, or a laptop that's slow — and it gets closed cleanly because we know exactly what we're looking at. That's the whole point of the two weeks.

What I've learned from the ones that didn't go smoothly

Not every onboarding I've been on has been perfect. On the third one, we underestimated how much of the estate wasn't in the paperwork — the client genuinely didn't know about two whole rooms of workstations that another department managed themselves — and we ran a week over. On the fifth, the previous provider took longer than promised to hand over admin credentials, which delayed enrolment. On both occasions the fix was the same: go back to the walk. If in doubt, physically see it. Trust what you can put your hand on more than what a spreadsheet says.

The other thing I've learned is that clients almost never remember, or care about, the specific things we did during onboarding. What they remember is whether the first three months of tickets felt easy. The relationship between the two is very direct, and it lives in the quality of the paper notebook I fill in on day one.

If you're considering moving your IT support and you'd like to see what a proper onboarding looks like end-to-end — how the service runs day to day, what your first fortnight would involve, and what we'd need from your team — get in touch. The first conversation is a phone call, no obligation, and Brett or Simon will pick up.

FAQ

How long does it take to onboard a new managed IT client?

For a fifteen-to-fifty-person business the technical onboarding is usually two weeks of active work spread over four calendar weeks. Week one is discovery — a site visit, a walk of every room, and a full inventory of devices, users, network kit and existing accounts. Weeks two and three are documentation and enrolment — building the client's page in our records, standing up remote monitoring, enrolling laptops into Intune, and tidying whatever the previous provider left behind. Week four is a handover call with the client and a soft go-live on our helpdesk. Nothing goes live until we can prove we can find, reach and support every device we've been asked to look after.

What does a junior tech actually do during onboarding?

A lot of walking. My job on the discovery day is to physically see every desk, every printer, every switch and every cupboard with something blinking in it. I photograph the back of the comms cabinet, label anything unlabelled, note serial numbers, and record which user is on which laptop. Back at the office I put all of it into our system so any tech on the team can pick up a ticket and know where the device is, what it's called and who uses it. It sounds unglamorous. It's the reason first-week tickets don't turn into detective work.

Why does documentation matter so much on day one?

Because the person picking up the first support call at 9:03 on a Monday morning has never been to that office. If the site page is clean — printer names match the labels on the printers, the Wi-Fi passwords are in the vault, the director's laptop has her name on it in the asset list — the ticket takes ten minutes. If any of that is missing or wrong, the same ticket takes an hour. Multiply that across a year and it's the difference between a service that feels sharp and one that feels sluggish.

What tends to be a mess when you take a client on from another IT provider?

Three things almost every time. Old leaver accounts still active in Microsoft 365 — sometimes years old, still licensed. Domain administrators nobody can identify. And a comms cabinet with no labels and at least one cable running to a device that doesn't exist any more. None of these are anyone's fault in particular; they build up over time. The onboarding is often the first proper tidy the estate has had in five years.

Does the client have to be involved during the onboarding weeks?

Yes, but not much. We need one nominated contact — usually the office manager or an operations lead — who can grant us admin access to Microsoft 365, walk us round on the discovery day, and answer a small number of questions during the two weeks. Everything else runs in the background. Users usually don't notice we're there until the go-live email lands with the new helpdesk address.

What happens after the two weeks?

The account moves from the onboarding tech onto the normal service. That's when the recurring pieces of our managed IT service kick in — monitoring, patching, monthly summary, quarterly review. Any gaps found during discovery that were bigger than tidy-up work get scheduled as a proper project rather than being quietly absorbed. And I go back to the day job, which is fixing tickets.