How do you onboard a new client in a CRM?
A repeatable checklist beats rebuilding each setup from memory: stages, cadences, integrations, users, and documentation, applied the same way every time.
The short answer
- Onboarding a new client without a repeatable checklist means rebuilding a setup from memory each time. That produces inconsistent results and misses steps that only get remembered after something breaks.
- A consistent baseline, standard pipeline stages, standard fields, standard starter automations, saves setup time and reduces the chance of missing something. Real client differences still need some customization on top.
- Document the configuration as it is built, not after the fact. That gives the client and anyone who later supports the account a reference for what was set up and why.
- Set realistic time expectations up front, as a range rather than a single fixed promise. That avoids the common mistake of underselling how long a real setup with integrations and training takes.
Why rebuilding from memory does not scale
The first few client setups an agency does often go fine without a formal checklist. The person doing it remembers roughly what needs to happen. That breaks down as volume grows or as the original person moves to other work. Steps get missed. Different clients end up with inconsistent baselines for no real reason. Troubleshooting a client's account later means guessing what was set up rather than checking documentation.
A repeatable checklist solves this by making the baseline explicit. Which pipeline stages exist by default. Which fields are standard. Which starter automations or cadences get configured. Which integrations need connecting. Which users need access, at what level. Real client differences, a different industry, a longer sales cycle, a bigger team, still need judgment on top. But starting from a documented default is faster and more consistent than starting from nothing each time.
A baseline onboarding checklist
| Step | What it covers |
|---|---|
| Pipeline and stages | Standard stages configured, adjusted for the client's actual sales process |
| Users and access | Team members added with the right access level for their role |
| Integrations | Mailboxes, calendar, and any other connected tools set up and tested |
| Cadences and templates | Starter sequences and message templates in place, customized as needed |
| Documentation | A written record of what was configured and why, for future reference |
What to build if you do not have a checklist yet
Write down every step from your last few onboardings, even the ones that felt obvious at the time. Turn that into a standard checklist. Include a documentation step explicitly, so it does not get skipped under time pressure. Set an honest time-range expectation for clients based on real complexity, rather than a single number that undersells the more complex setups.
Disclosure: SalesCrew is our product. Config export and import between client instances, and a snapshot system for replicating a proven setup, are on our roadmap and not shipped today. Provisioning a new client instance is a supported workflow now. The reusable-template layer on the roadmap is meant to make the checklist above faster to run, not to replace it.
Undocumented configuration is a liability, not a shortcut
Questions
- Should every client get an identical setup?
- A consistent baseline, standard stages, standard fields, standard automations, saves rebuild time and reduces mistakes. Real client differences, industry, sales cycle, team size, usually need some configuration on top of that baseline. Not a fully identical copy.
- How long should onboarding realistically take?
- It depends heavily on complexity. A simple use case can be set up the same day. Something with several integrations and a larger team to train can take a couple of weeks. Define an expected range up front rather than promising one fixed number to every client.
- What is the most commonly skipped onboarding step?
- Documenting the configuration itself: what was set up and why. That gives the client, and anyone else supporting the account later, a reference. Without it, the setup exists only in the builder's memory.