How to Actually Onboard a Client

The first migration Threefold ever did, we made a lot of assumptions. We assumed the client understood the scope. We assumed they had thought through the same edge cases we had. We assumed that when they said their data was "pretty clean," they meant what we meant by "pretty clean."

None of these assumptions were correct.

The migration finished. The client was happy with the outcome. But there were points in the middle of the project where we were navigating surprises that should not have been surprises — because if we had asked the right questions upfront, they wouldn't have been.

Every difficult client engagement I've been part of since then traces back to a weak kickoff. Every smooth one traces back to a kickoff where we took the time to do it right.

What most service businesses call onboarding

In my experience, the typical service business onboarding looks like this: a contract gets signed, a deposit hits the bank, and then work starts. Maybe there's an introductory call. Maybe someone sends a welcome email with a few logistics. And then the team is off to the races, working from whatever was discussed during the sales process.

This is the wrong model. The sales process is about making the case that you can do the work. The kickoff process is about ensuring you both understand what "the work" actually is. Those are different conversations, and conflating them is how you end up with a client who thought they were getting one thing and a team that delivered another.

The phases that actually matter

After enough iterations, here is the onboarding process Threefold uses for every church migration. It's not complicated. But it's deliberate.

function onboardClient(client) {
  return [
    {
      phase: 'Pre-Kickoff Data Audit',
      owner: 'Threefold',
      duration: '3-5 days',
      goal: 'Understand what we are actually working with before anyone is on a call',
      deliverable: 'Data Quality Report with known issues flagged',
    },
    {
      phase: 'Kickoff Call',
      owner: 'Joint',
      duration: '90 minutes',
      goal: 'Align on scope, surface unknowns, confirm success criteria',
      deliverable: 'Documented project scope and decision log',
    },
    {
      phase: 'Migration Plan Review',
      owner: 'Threefold',
      duration: '1 week',
      goal: 'Client reviews and approves the plan before any data moves',
      deliverable: 'Approved migration plan',
    },
    {
      phase: 'Weekly Check-ins',
      owner: 'Joint',
      duration: 'Ongoing',
      goal: 'Surfaces issues early, keeps client informed, maintains trust',
      deliverable: 'Status update with open items and next steps',
    },
    {
      phase: 'Training Before Launch',
      owner: 'Threefold',
      duration: '2-3 sessions',
      goal: 'Staff can operate the new platform on day one',
      deliverable: 'Recorded training sessions + quick reference guides',
    },
    {
      phase: '30-Day Post-Launch Review',
      owner: 'Joint',
      duration: '60 minutes',
      goal: 'Catch what we missed, confirm the client is stable',
      deliverable: 'Close-out report and follow-up action list',
    },
  ]
}

The pre-kickoff audit is the most important step nobody does

Before we get on a kickoff call, we look at the data. We get access to the client's current system, export what we can, and spend a few days understanding what's actually there. How many records? How much duplication? Are there fields being used in non-standard ways? Is giving data organized the way the client thinks it is?

This matters because clients almost always have an optimistic view of their own data. Not because they're misleading you — they genuinely believe their data is "pretty clean." But they're looking at it from a user's perspective, not a migration specialist's perspective. There's a big difference.

When we show up to the kickoff call having already done this work, two things happen. First, the client trusts us more — we've taken their project seriously before they were even paying us for this phase. Second, we can have a real conversation about the project instead of discovering the hard things later.

The kickoff call is not a sales call

I've watched people run kickoff calls that were really just an extension of the sales process — lots of enthusiasm, vague commitments, a focus on what we're going to do rather than what we're going to avoid. Those calls feel good in the moment and create problems for weeks afterward.

The purpose of the kickoff call is alignment, not momentum. The questions to answer are: What exactly are we migrating, and what are we not migrating? Who are the decision-makers on the client side, and who has authority to approve changes? What does "done" look like, specifically? What are the non-negotiables, and what's flexible?

Document the answers. Send the notes before the call ends. Get explicit confirmation that your understanding matches theirs.

Training before launch, not after

This one took us longer to get right. Our early instinct was to launch the migration, let the client use the system, and then schedule training. The theory was that hands-on experience would make the training more relevant.

The theory was wrong. What actually happened is that clients would start using the system without knowing what they were doing, build habits around workarounds they invented themselves, and then show up to training confused because the system worked differently than they'd trained themselves to expect.

Training before launch is harder to schedule. Clients are busy. It feels like an extra hurdle before they can use the thing they just paid for. But a team that knows what they're doing on day one is a completely different client experience than a team discovering the platform in real time.

The 30-day check-in is not optional

By the time a migration launches, everyone is relieved it's over. The instinct is to close the loop and move on to the next project. That instinct is usually wrong.

The first 30 days of using a new system are when the real surprises surface. Not the data problems — those usually surface during testing. The process problems. The things that worked in their old system that nobody thought to mention because they'd been doing it so long it felt invisible. The workflows that made sense in the training session but don't quite fit how the office actually operates on a Tuesday morning.

A 30-day check-in gives you the chance to catch and fix those things before they calcify into workarounds. It's also the moment to confirm that the client feels stable — not just technically, but operationally. If they don't, you want to know now, not in a Google review six months later.

The real reason this matters

Beyond the tactical benefits, consistent onboarding communicates something important to the client: that you are organized, that you take their project seriously, and that you've done this before.

In professional services, confidence is a product. Clients are not just hiring you for the deliverable — they're hiring you for the certainty that the deliverable will be delivered. Every piece of your process either builds that certainty or erodes it.

The kickoff is the first impression after the sale. Make it look like a firm that knows what it's doing.