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.
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.
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
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.
Migration inventory, workshops and template configuration
Priority processes configured and tested with real cases
Phases 3–4
Week 4
Client demo, change requests and sign-off
Templates approved by the client’s project owner
Phase 5
Weeks 5–6
Training, branded help and go-live
First real checklists running, two weeks of priority support
Phase 6
Days 30, 60, 90
Adoption reviews and handover
Success criteria reviewed with the sponsor
Phase 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.
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.
Do you like cookies? 🍪 We use cookies to ensure you get the best experience on our website. Learn more