Client onboarding projects, done right

Onboarding is the most important project you'll ever run for a client, because it's the one that decides whether they trust you. Get it clean and consistent and you've earned the relationship. Let it sprawl into a half-remembered checklist and you've spent your best first impression on chaos. The work itself is well understood — documentation, tooling, identity, security baseline, knowledge transfer — which is exactly why it should be systematized instead of improvised.

The job to be done

A standard onboarding runs the same shape every time: gather and document the environment, deploy your RMM and EDR agents, stand up or take over Microsoft 365, apply your security baseline, and complete a knowledge transfer so your service desk can actually support the account on day one. It should be repeatable, consistent no matter which engineer runs it, and visible to the new client during the exact window when they're most anxious about the decision they just made.

Where it usually goes wrong

Onboarding tends to live in one of two bad places: a static checklist that every engineer runs slightly differently, or a single PSA ticket that balloons into an unreadable thread of internal notes. Neither gives the client a window in. So the new partner — who just signed and is quietly wondering whether they chose well — hears nothing but silence for two weeks.

The other classic failure is the handoff. Sales closes the deal with a head full of context: what was promised, what the environment looks like, what the client actually cares about. Almost none of it survives the trip to delivery. The assigned engineer starts from scratch, re-asks questions the client already answered, and the relationship takes its first small, avoidable dent.

How Current fits

Current covers onboarding end to end because it holds the CRM and the delivery work in the same platform — so the context sales gathered is already there when delivery starts, not stranded in someone's inbox.

• Playbooks turn your standard onboarding into a one-click clone: phases, tasks, and dependencies, run the same proven way every time regardless of who's on the job.
• A won quote becomes a project. The ScalePad Quoter Win Quote Engine bridge, and the booking-to-CRM-to-PSA flow, carry sales context straight into delivery.
• Draft from a statement of work: paste the SOW and Current drafts the phases, tasks, and dependencies for you to review before anything is created — nothing is saved until you approve it.
• A partner portal that gives the new client visibility from day one — timeline, milestones, and progress — with no financials, ever, enforced at the database layer.
• Microsoft 365 integration provisions the SharePoint project folder and mirrors a Teams channel, so documents and conversation have a home from the first task.
• Native time entry that flows to your PSA — Autotask, ConnectWise, or Halo PSA — for billing on a synced project, plus milestones for the go-live moment that tells everyone onboarding is genuinely finished.

An honest boundary

Current isn't a general-purpose project tool with a giant template marketplace, and it won't run your marketing. What it does is make onboarding a controlled, repeatable engagement that starts from won sales context and ends with a client who watched the whole thing go right. If you onboard more than a handful of clients a year, the consistency alone usually pays for the switch — and the visibility is what turns a nervous new signup into a confident, referenceable one.

Why onboarding sets the whole relationship

The first ninety days establish what the client believes about your competence, and that belief is durable. An onboarding that runs late, needs chasing, or surprises them with things nobody mentioned creates a client who checks up on you for years. One that visibly runs to plan buys trust you spend later, during the incident that inevitably happens.

The practical implication is that onboarding deserves to be a real project with real sequencing rather than a checklist somebody works through, because a checklist cannot tell you on day twelve that you are going to miss the day-thirty cutover.

The dependencies people forget

• Client-side tasks you do not control: DNS access, decisions about naming, a signature on something.
• Third-party lead times: circuits, hardware delivery, licence provisioning.
• Sequencing you cannot compress: a tenant has to exist before mailboxes migrate into it.
• Your own capacity, since the engineers onboarding this client are also on the ticket queue.

The first two are where onboardings actually slip, and both are invisible in a checklist. Modelled as dependencies with realistic offsets, they show up in the forecast date instead of as a surprise.

Give the client the plan

Most onboarding friction is really communication friction: the client does not know what is happening, so they ask, and answering costs more time than the work. A portal where they see the plan, their own outstanding tasks, and genuine progress removes most of that traffic. Current's partner portal isolates financial data at the database layer rather than hiding it in the interface, so it is safe to hand a client a live link rather than a curated status email.

Make it a template

The second onboarding should be faster than the first. Capture the sequence as a playbook once it works, so each new client starts from accumulated knowledge rather than from somebody's memory of the last one. This is also how onboarding stops depending on one person.