White-Label Client Onboarding Checklist Template

A client who buys your branded platform is buying your way of working. If their processes are not running on it within ninety days, they will not renew it, however good the branding looks.

Selling a platform under your own brand changes what onboarding has to deliver. The client is not buying a login, they are buying your processes, your configuration and your support, presented as your product. That means onboarding has to end with their real work running on the platform, not with a welcome email and a training video. This free white-label client onboarding checklist gives resellers, MSPs and agencies a repeatable way to take each customer from signed order to adoption. It covers the kick-off and success criteria, a readiness check on the account, configuring the client’s processes as templates, the client’s formal sign-off, admin and end-user training under your brand, go-live and a 30, 60 and 90-day adoption review. A conditional phase handles clients who are moving processes out of documents, spreadsheets or another tool, so it appears only when there is something to migrate.

Use This Template Free See Live Example
No Credit Card Required

You Are Onboarding a Customer Onto Your Product, Not Taking Over Their IT.

MSPs that resell a white-label platform already have a client onboarding process, and it is the wrong one for this job. The MSP Client Onboarding Checklist covers taking operational responsibility for a client’s IT: credentials, discovery, agents, backups and a service desk cutover. Onboarding a customer onto your branded platform is closer to a software implementation. Nothing is being taken over. Success depends on whether the client’s people change how they work.

That shifts the effort from technical tasks to configuration and adoption. The account itself should already be built and tested before the kick-off, using the White-Label Reseller Account Setup Checklist. What remains is understanding the client’s processes, configuring them well, getting a named person to approve them, training people in your brand’s name and then checking, at 30, 60 and 90 days, that the platform is actually being used.

MSP client onboarding

Taking over an IT estate

Owner: the onboarding engineer.

Work: access, discovery, agents, backups, documentation, cutover.

Done when: every in-scope device is managed and documented.

White-label client onboarding

Adopting your branded platform

Owner: the onboarding lead or customer success manager.

Work: success criteria, configuration, sign-off, training, adoption.

Done when: the client’s agreed processes run on the platform.

What the White-Label Client Onboarding Checklist Covers

Seven phases take a customer from signed order to a 90-day adoption review. Phase 3 appears only when the client is migrating processes from documents or another tool.

Phase 1

Phase 1: Kick-Off & Success Criteria

Answer the migration question at kick-off. It decides whether Phase 3 runs.

  • Review the sales handover — plan, user numbers, the processes promised during the sale and why the client bought
  • Hold the kick-off — introduce the onboarding lead, and confirm the client’s project owner and executive sponsor
  • Agree the success criteria — two or three measurable outcomes, such as every new-starter request running on the platform by day 60
  • Agree the onboarding plan — dates for configuration, sign-off, training, go-live and the 30, 60 and 90-day reviews
  • Confirm the data protection terms — a signed data processing agreement, with the platform vendor disclosed as a sub-processor
Phase 2

Phase 2: Account Readiness

Don’t configure anything until the account setup checklist has been approved.

  • Confirm the account setup is approved — hostname, certificate, email authentication and branding all signed off
  • Test notification delivery to the client — send a test to their own mailboxes and confirm it reaches the inbox
  • Agree the user list and roles — who builds templates, who completes tasks and who only views
  • Create the client’s administrator accounts — for the people who will own the platform after onboarding
  • Confirm the support route — the client knows to raise questions with your service desk, by which channel and in what hours
Phase 3 — Migrating Processes

Phase 3: Process Migration

Shown only when the client’s processes currently live in documents, spreadsheets or another tool.

  • Inventory the existing processes — every document, spreadsheet or tool workflow, with its owner and how often it runs
  • Prioritise for go-live — choose three to five processes to launch with and schedule the rest after go-live
  • Export what must be kept — records and history from the previous tool, stored as an archive rather than imported
  • Rebuild, don’t copy — remove steps nobody does, and add owners, due dates and the evidence each step needs
  • Set the cut-over date — the day the old documents or tool stop being used for each process
Phase 4

Phase 4: Process & Template Configuration

  • Run a workshop for each priority process — with the people who do the work, not only the manager who owns it
  • Configure the templates — tasks, form fields, assignments, relative due dates and conditional logic
  • Set up schedules and notifications — recurring runs, reminders and who is told when work is overdue
  • Test each template with a real case — run it with a recent example and fix anything that doesn’t match how the work is done
Phase 5

Phase 5: Client Sign-Off

  • Demo the configured templates — walk the client’s project owner through each one, end to end
  • Record and make change requests — agree what changes before go-live and what waits until after
  • Approve the configured templates — the onboarding lead attaches the project owner’s written sign-off; not approved stops training and go-live
  • Freeze the go-live configuration — further changes go through the change log after go-live
Phase 6

Phase 6: Training & Go-Live

  • Train the client’s administrators — editing templates, adding users, schedules and reports
  • Train end users by role — short sessions on the tasks they will actually complete, recorded for new joiners
  • Publish branded help — quick-start guides under your brand, with your service desk as the support contact
  • Go live — launch the first real checklists and give the client priority support for the first two weeks
  • Announce the change to users — a message from the client’s sponsor, not from you, explaining what changes and when
Phase 7

Phase 7: 30/60/90-Day Adoption Review

  • Hold the 30-day review — active users, checklists run, overdue tasks and the support tickets raised
  • Hold the 60-day review — progress against the success criteria and the next processes to configure
  • Hold the 90-day review with the sponsor — success criteria met or not, and the plan for anything that isn’t
  • Hand over to account management — close onboarding and book the client’s first regular service review

A Typical 90-Day White-Label Onboarding Plan

Most small and mid-sized clients can be live within four to six weeks of the kick-off, with the remaining time spent on adoption. Agree the plan at the kick-off and share it with the client’s project owner, so the sign-off and training dates are in their diary as well as yours.

When What happens Done when Checklist phase
Week 1Kick-off, success criteria, account readiness checkPlan agreed and administrators can sign inPhases 1–2
Weeks 2–3Migration inventory, workshops and template configurationPriority processes configured and tested with real casesPhases 3–4
Week 4Client demo, change requests and sign-offTemplates approved by the client’s project ownerPhase 5
Weeks 5–6Training, branded help and go-liveFirst real checklists running, two weeks of priority supportPhase 6
Days 30, 60, 90Adoption reviews and handoverSuccess criteria reviewed with the sponsorPhase 7

Write the success criteria before you configure anything

Success criteria are the most skipped task in the kick-off and the most useful one at the 90-day review. Without them, the sponsor judges the platform on impressions, and impressions are shaped by the last thing that went wrong. With them, the review is a short conversation about two or three numbers everyone agreed at the start.

Good criteria name a process, a measure and a date. “All new-starter requests raised on the platform by day 60” is a criterion. “Better visibility of onboarding” is a hope. Keep the list short, tie each one to a process you are configuring in Phase 4, and write down who at the client will confirm whether it was met. If the client can’t agree any measurable outcome, treat that as a warning sign about adoption and raise it with the sponsor before go-live, not after.

Adoption signals to check at each review

A configured platform is not an adopted one. These are the signals worth pulling before each review, because they show whether the client’s people are using the platform or working around it:

  • Active users against licensed users. Users who have never signed in are the first sign of a renewal problem.
  • Checklists run per process. Compare with how often the process happens. A monthly process with no run this month is still being done somewhere else.
  • Overdue tasks. A steady build-up usually means a task is assigned to the wrong person or a due date is unrealistic.
  • Support tickets by theme. Repeated how-do-I questions point to a training gap, not a user problem.
  • Template changes requested. Requests are a good sign. They mean people are using the templates and want them to fit better.

If a signal is poor at 30 days, act on it then. By the 90-day review it is a conversation with the sponsor about whether the platform was worth buying.

Why Onboard White-Label Clients in CheckFlow?

1

The same onboarding for every customer

Launch the checklist for each new customer with the plan, project owner and go-live date filled in. Conditional logic adds the migration phase only for clients with processes to move, and relative due dates set the 30, 60 and 90-day reviews from the go-live date.

2

Progress the client can see under your brand

Share the onboarding checklist with the client’s project owner through a link that opens without an account, showing your logo, your company name and your own subdomain. They can follow progress and complete their own steps without being given a seat in your workspace.

3

Sign-off that holds

The client sign-off is an approval. Training and go-live stay locked until the onboarding lead records the project owner’s written sign-off, and the record shows who approved what and when. When a change request arrives after go-live, you can show what was agreed.

Running client delivery under your own brand is what CheckFlow’s white-label features are for. The white-label checklist software guide covers the reseller economics, and why retention matters more than margin.

This checklist assumes the account is already built. The White-Label Reseller Account Setup Checklist covers the hostname, certificate, email and branding, and the general client onboarding checklist guide covers the relationship side of any onboarding.

Frequently Asked Questions

What is white-label client onboarding?

+

It is the process of taking a customer from a signed order to real use of a platform you sell under your own brand. It covers agreeing success criteria, configuring the customer’s processes, getting their sign-off, training their administrators and users with your branded help, going live and reviewing adoption. The customer should experience it as your product and your service from start to finish.

How is this different from MSP client onboarding?

+

MSP client onboarding is the technical takeover of a client’s IT: credentials, discovery, agent deployment, documentation and service desk cutover. White-label client onboarding is closer to a software implementation. Nothing is taken over. The work is configuration, training and adoption, and success is measured by whether the client’s people use the platform. An MSP that also resells a branded platform will usually run both checklists, owned by different people.

How long should white-label client onboarding take?

+

For most small and mid-sized clients, four to six weeks to go-live, followed by adoption reviews at 30, 60 and 90 days. The main variables are how many processes you configure before go-live and whether anything has to be migrated. Launching with three to five priority processes and adding the rest afterwards is usually faster than configuring everything first.

Should we migrate everything from the client’s old documents or tool?

+

No. Migrate the processes, not the clutter. Rebuild each priority process as a template, removing steps nobody does and adding owners and due dates. Keep historical records from the previous tool as an exported archive rather than importing them, unless the client has a clear reason to need them on the platform. Set a cut-over date for each process so the old version stops being used.

Who should sign off the configured templates?

+

The client’s project owner, the person accountable for the processes, not only the administrator who attended the workshops. Their approval confirms the templates match how the client wants the work done. Attach it to the approval task, and agree that changes after sign-off go through a change log, so the scope of onboarding does not grow without anyone deciding it should.

Do we need a data processing agreement with the client?

+

Usually, yes. If the platform holds personal data on the client’s behalf, UK and EU GDPR require a written contract between the client as controller and you as processor. You also need the client’s written authorisation to use the platform vendor as a sub-processor, and a contract with the vendor giving equivalent protection. Take legal advice on your own terms.

Is CheckFlow free for this template?

+

14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.

Onboard Every Customer Onto Your Brand, and Into Real Use

Free trial — no credit card required.