Customer onboarding

A preview of how this template lays out — the boards, their custom workflow states, and where the sample issues land. WIP caps show a badge.

• Acme Corp — kickoff and success plan

  Capture goals, success metrics, and the go-live date.

  P13pt

• Import their existing data and configure workspaces

  P15pt

• Run the admin + end-user training sessions

  P23pt

These rules aren't created when you apply the template — they're recipes you can wire up in Settings → Automations once your board exists.

• When

  Account stalls in 'Implementation' for 14 days

  Then

  Flag the CSM that onboarding is at risk of slipping

• When

  Account moves to 'Go-live'

  Then

  Schedule a 30-day adoption check-in

Kickoff, Implementation, Training, Go-live, Adopted. The last column is the one that makes this different from a project plan: onboarding is not finished when the customer is live, it is finished when they are using the thing. Splitting Go-live from Adopted is a deliberate refusal to let the team declare victory at the technically-working milestone, which is precisely where onboarding-driven churn is created.

1. 1.Open a card per account, not per task

   One card per customer, with the workstreams as sub-issues underneath. This is what lets you look at the board and see accounts, not a hundred and forty tasks. The card is also where the success plan lives — what this customer defined as success at kickoff, in their words, so it can be quoted back at the go-live review.

2. 2.Write down the success criteria at kickoff or skip kickoff

   A kickoff call that does not end with a written, agreed definition of what value looks like for this account has not happened yet. Vague criteria are how onboarding drifts: without them, every request becomes in-scope and go-live keeps moving. Name the criteria, name the customer-side owner, put both on the card.

3. 3.Watch the stall in Implementation

   Implementation is where onboarding dies, usually because the customer owes something — data, access, a decision — and nobody is comfortable chasing. The template's suggested rule flags an account sitting there fourteen days, and the right response is not another email, it is escalating to whoever signed. A stalled implementation at day fourteen is a renewal problem at month nine.

4. 4.Train the people who will actually use it

   Training the champion who bought is necessary and insufficient. The Training column should not clear until the daily users have been through a session, because a champion who leaves takes the entire account's knowledge with them. Track admin training and end-user training as separate sub-issues so the second one cannot be quietly skipped.

5. 5.Gate Adopted on usage, not on a calendar

   Do not move an account to Adopted because thirty days have elapsed. Move it when the success criteria from kickoff are demonstrably met. The thirty-day check-in the template suggests is a prompt to make that judgement, not the judgement itself.

This board encodes one opinion about how the work should run. Here is where that opinion is wrong and something else fits better.

• You onboard self-serve at volume. If a thousand accounts a month sign up and activate themselves, per-account cards are absurd. That is a product and lifecycle-messaging problem measured in cohorts, not a board — instrument activation and fix the funnel.
• You already run a customer-success platform. Gainsight, Vitally, Catalyst and similar are built on product usage data and health scoring, and they do this natively with signals a board cannot see. Running both means two systems disagree about account health, which is worse than either alone.
• Onboarding is a genuine multi-month professional-services engagement. Six-figure implementations with billable hours, statements of work, change orders and staged invoices need project accounting and resource scheduling. Five columns will not hold that, and pretending otherwise is how scope creep goes unbilled.
• Your customers need visibility into their own onboarding. This board is internal. If the customer should see the plan and tick off their own tasks, you need a shared or client-facing surface, and bolting guest access onto an internal ops board rarely ends well.

Honest comparisons, including where the other tool wins. Planoda is pre-launch, so nothing below is a benchmark — it is a description of how each product approaches this job.

• Asana

  Asana's project templates with task dependencies are the mainstream way teams run repeatable client onboarding, and its rule engine can spawn a full task tree per new account. This template is the same idea expressed as a pipeline board where the account, not the task, is the unit of attention.

  Where Asana is better: Asana's dependency modelling and its portfolio view across many concurrent onboardings are stronger than a single board, particularly if you are running dozens of accounts at once and need to see resource conflicts between them.

• HubSpot

  If your CRM already holds the account, running onboarding as a pipeline there keeps the sales-to-success handoff in one record — the deal becomes the onboarding, with the same contacts and history attached. This board is the alternative when the work involves people who do not live in the CRM.

  Where HubSpot is better: The unbroken handoff is a real advantage: everything the sales team promised is visible on the same record the CSM is working, and nobody has to re-enter an account. If your CRM has a service or onboarding pipeline, use it.

• Notion

  A Notion database per account with a template page is common at smaller companies, and the per-account page is genuinely nicer for storing meeting notes, the success plan and the account context in one readable place. What it lacks is the stall signal — nothing tells you an account has not moved in two weeks.

  Where Notion is better: For account context, written success plans, and shareable customer-facing pages, Notion's page model beats a card. Small CS teams with a handful of high-touch accounts often correctly prefer it.