A customer onboarding plan template gives every new account the same strong starting point: clear phases, named owners on both sides, due dates and a definition of done for each stage. Without one, every onboarding gets rebuilt from scratch, steps get missed and customers wait while your team works out what happens next. With one, your team spends its time on the parts of onboarding that are actually different for each customer.
This guide gives you a copyable 30-60-90 day onboarding plan for B2B software. It covers the phases, milestones and owners, Day-N due dates and the exit criterion that closes each phase. It also explains what to standardize in a template and what to tailor for each customer. If you want more detail on choosing milestones, see onboarding milestones. For the end-to-end timeline, see implementation timeline from kickoff to go-live.
What a Customer Onboarding Plan Should Include
Whatever format you use, a working onboarding plan has the same building blocks:
- Phases that group the work into stages the customer recognizes, such as setup, rollout and adoption.
- Milestones that mark checkpoints, such as "integration live" or "first team trained".
- Tasks under each milestone, each with one owner and a due date.
- Owners on both sides. Many onboarding steps can only be done by the customer, such as granting access, sharing data or nominating admins. These need customer owners just as clearly as your internal tasks need yours.
- Relative due dates counted from the start date (Day 0, Day 7, Day 30) so the template works for any start date.
- Exit criteria that say, in observable terms, when a phase is done.
- Information requests for anything you need from the customer, such as configuration details, files or contacts.
In Quivly, these map directly onto Projects. Milestones are checkpoints in the plan, tasks carry an assignee, priority and due date, and subtasks break down larger pieces of work.
The 30-60-90 Day Customer Onboarding Plan at a Glance
| Phase | Days | Goal | Exit criterion |
|---|---|---|---|
| 1. Kickoff and setup | 0 to 30 | Agree on goals and get the product connected | Core setup live and checked against real data |
| 2. Rollout and first value | 31 to 60 | Get the first team using the product for real work | The customer reaches the first value event you agreed at kickoff |
| 3. Adoption and handoff | 61 to 90 | Expand usage and move to ongoing success | Adoption goals met and a review cadence agreed with the customer |
The 30-day blocks are a starting point, not a rule. A simple self-serve product may finish in 30 days, and a complex enterprise rollout may need longer phases. Keep the structure and stretch the dates.
Days 0 to 30: Kickoff and Setup
The first phase sets expectations and removes technical blockers. Most onboarding delays start here, usually while you wait on something only the customer can provide.
- Day 0: Internal handoff review. Read the sales handoff, confirm the agreed goals and flag any promises made during the sale. Owner: onboarding lead.
- Day 3: Kickoff call. Confirm success criteria, the timeline, named contacts on both sides and how you will communicate. Owner: onboarding lead, with the customer's project sponsor.
- Day 5: Technical discovery questionnaire returned. Owner: customer technical contact.
- Day 10: Access and SSO configured, admins provisioned. Owner: customer IT admin, supported by your implementation engineer.
- Day 20: Core integration connected and field mappings agreed. Owner: implementation engineer.
- Day 30: Data validated with the customer. Owner: implementation engineer, with sign-off from the customer.
Exit criterion: the core integration is live and the customer has confirmed the data looks right.
Tasks like the discovery questionnaire are easier when the request is built into the plan. In Quivly, you can attach a form to a template task, so every new project asks for the same information in the same structure instead of a fresh email thread each time.
Days 31 to 60: Rollout and First Value
With setup done, the focus moves from configuration to use. This phase is about getting real users doing real work, and about reaching the first value event agreed at kickoff.
- Day 35: Pilot team selected and workflows configured for their use case. Owner: onboarding lead, with the customer's team lead.
- Day 40: Admin and end-user training delivered. Owner: onboarding lead.
- Day 45: Pilot team using the product for day-to-day work. Owner: customer team lead.
- Day 50: Mid-point review of usage, blockers and feedback. Owner: onboarding lead.
- Day 60: First value event confirmed, such as the first report used in a real decision or the first workflow running in production. Owner: onboarding lead, confirmed by the customer sponsor.
Exit criterion: the customer has reached the first value event and can point to it.
The mid-point review is a good moment to post a project status. In Quivly, a project update can carry an On Track, At Risk or Off Track health selection, which updates the project's health so everyone sees the same status without a separate report.
Days 61 to 90: Adoption and Handoff
The last phase turns a successful pilot into lasting adoption and hands the account to the team that will own it long term.
- Day 65: Rollout extended to further teams or use cases. Owner: customer sponsor, supported by the onboarding lead.
- Day 75: Adoption check against the goals set at kickoff. Owner: onboarding lead.
- Day 80: Open issues, workarounds and decisions documented for the ongoing owner. Owner: onboarding lead and implementation engineer.
- Day 85: Handoff meeting with the customer and the CSM. Owner: onboarding lead.
- Day 90: Success metrics and review cadence agreed. Owner: CSM.
Exit criterion: the agreed adoption goals are met, the CSM owns the account and the customer knows when the next review happens.
For more on making this last step stick, see implementation to adoption handoff.
What to Standardize and What to Tailor
A template should remove repeat work without forcing every customer into the same shape. A useful split:
Standardize in the template:
- Phase names, milestones and their order.
- Tasks that happen on every onboarding, such as kickoff, access setup, training and handoff.
- Default owners by role and relative due dates.
- Standard information requests and the questions they ask.
- Exit criteria for each phase.
Tailor for each customer:
- The specific success criteria and first value event.
- Integrations and data sources in scope.
- Customer-side owners and their names.
- The target date, based on their constraints.
- Extra tasks for custom requirements agreed during the sale.
If your segments onboard very differently, keep separate templates rather than one template full of optional steps. Quivly supports separate onboarding blueprints for different segments, product lines or use cases, and the template library lets you duplicate a plan when you need a variation.
How to Build the Template in Quivly
Quivly's project templates follow the same structure as the plan above:
- Create the template. Start from scratch, a starter or a duplicate of an existing template. Give it a name, description and estimated duration. The estimated duration suggests the project's target date, which you can override when creating a project.
- Add milestones and tasks. Add milestones for each checkpoint and tasks for the work needed to reach them, with subtasks where useful.
- Set default assignees. A task's default assignee carries into every new project. The overall project owner is chosen when the project is created.
- Use relative dates. Set "Due after … days" from the project's start date. If a project starts on October 5, Day 0 is October 5 and Day 7 is October 12.
- Choose customer visibility. Choose Hide all, Show all or Per task for what customers can see. Visibility defaults do not invite anyone, so customer access is managed separately through the customer portal.
- Draft with AI if you like. Create with AI or Edit with AI lets you describe the outcome, phases, timing and information you need from the customer, then review the proposal before accepting it.
When you create a project from the template, Quivly copies the plan and calculates every task date from the start date. Later template edits only apply to future projects, so you can improve the template without disrupting onboardings already in flight.
Keeping the Plan Alive After Kickoff
A template only helps if the plan stays current. A few habits keep it useful:
- Review overdue tasks weekly and reassign or re-date them rather than letting them pile up.
- Turn decisions and blockers from calls and threads into tasks on the plan, not side notes.
- Mark projects On Hold or Blocked when that is the reality, so status reflects what is happening.
- After every few onboardings, update the template with what you learned.
Quivly helps with the second habit. Its agents can turn a conversation into a proposed task, risk or blocker with the evidence attached, and a person still chooses whether to apply it. If you want your onboarding plans, customer requests and progress in one workspace, take a look at onboarding at scale with Quivly.
