Playbook

Playbook: Build a Customer Onboarding Checklist Skill

There is a wiki page somewhere in your customer success documentation that lists the 22 things to do when onboarding a new customer. It was written by a seni...

Agent Skillsagent-skills / playbook-customer-onboarding-checklist

There is a wiki page somewhere in your customer success documentation that lists the 22 things to do when onboarding a new customer. It was written by a senior CSM eighteen months ago. Two CSMs use it, one ignores it because she has her own checklist in Notes, and the newest hire on the team can't find it because the wiki search is bad and the page title got renamed. New customers get onboarded inconsistently. Renewal conversations six months later reveal what got skipped: the integration walkthrough never happened, the success criteria were never agreed in writing, the executive sponsor introduction was missed.

The CSMs are not negligent. They are doing the work, with the document they have, the way their training showed them. The problem is that "the document" is a wiki page, the work belongs to the company, and the consequences land on renewals. This playbook walks you through replacing the wiki page with a reviewed Agent Skill — attached to your customer success agent — that turns the checklist into an enforced workflow, with explicit checks and a record of what was actually completed for each new account.

What you will build

By the end of this playbook, you will have:

  • A workspace Agent Skill named Customer Onboarding Checklist with a SKILL.md procedure, the 22 (or however many) onboarding tasks codified as required steps, a customer data policy, an output template, and worked examples of complete and incomplete onboardings.
  • An approved version of that skill, attached to your Customer Success Agent with a readable mount path.
  • A repeatable workflow: a CSM tells the agent "we just signed Acme Corp, start the onboarding checklist," the agent walks through the steps, asks for evidence at each one, and produces a structured record of what was completed and what is still open.
  • A renewal-readiness signal: at any point during the customer lifecycle, the agent can produce a "onboarding completeness" report for a given account.

What you need before you start

  • An Assist workspace where you can create workspace-scoped Agent Skills.
  • A workspace admin who can review and approve versions.
  • A Customer Success Agent in your workspace — the operational agent your CS team already uses, ideally with tools that can read the CRM, the support system, and any account configuration system. If you do not have one, create a subagent first.
  • The current wiki onboarding checklist (or whatever document the team uses today). If it lives in multiple places, collect them all — discovering the differences is part of the work.
  • A senior CSM and a CS manager willing to define which tasks are required, which are conditional, and what evidence counts for each. The skill is only as good as their input here.

Step 1: Collect the real onboarding tasks

Before authoring anything, find what the team actually does. Two sources:

The documents. Pull the wiki page, the Notion doc, the personal checklist in Notes, the email template, the playbook PDF. List every task that appears in any of them.

The actual onboardings. Pick two recent onboardings — one that went well and one that went sideways. Walk through them with the senior CSM:

"Show me everything you did during Acme Corp's onboarding. What was the first conversation? When did you introduce the executive sponsor? When did you agree on success criteria, and where is that documented?"

Map what was actually done against what the documents say should be done. The gap is the failure mode — the tasks that the documents list but real CSMs skip, or the tasks that real CSMs do but the documents don't mention.

You will end up with a list that is longer and more honest than any document. That's the input to the skill.

Step 2: Classify each task

Not every task is required for every account. Classify the tasks into three buckets:

  • Required for every account. Examples: kickoff call within seven days of signature; executive sponsor introduction; success criteria documented in the CRM; primary user trained on core workflow; integration health check.
  • Conditional based on account type. Examples: SSO setup (only if the contract includes SSO); compliance review (only for accounts above the regulated tier); custom integration walkthrough (only for accounts that purchased the integration).
  • Optional but recommended. Examples: introduction to the user community; quarterly business review scheduling; reference call participation.

The classification matters because the skill needs to know what to enforce vs. what to suggest. A skill that treats every task as required produces a lot of "skipped" entries on accounts where the task wasn't applicable, and the CSMs learn to ignore the output.

Step 3: Create the draft skill

Open Assist and go to Workspace > Agent Skills. Click New Skill and set:

  • Name: Customer Onboarding Checklist
  • Slug: customer-onboarding-checklist
  • Scope: Workspace
  • Description: Walks a CSM through the customer onboarding checklist for a new account, enforces required tasks, conditionally enforces tasks based on account type, and produces a structured record of what was completed.

Or scaffold from chat:

"Create a workspace Agent Skill called Customer Onboarding Checklist. Slug: customer-onboarding-checklist. It walks a CSM through the onboarding tasks for a new account, applies required and conditional task lists, and produces a completeness record. Start a draft SKILL.md and folders for templates, policies, and examples."

The skill is a draft. Author the files safely.

Step 4: Write the main procedure

Open /SKILL.md. The first line tells Assist when to pick this skill up:

Use this skill when a user asks to start, continue, or report on the onboarding for a new customer account.

Then walk through the procedure. A useful SKILL.md for this skill includes:

  1. Confirm the account name and account type. Refuse to proceed without an account name — onboardings without an explicit account get lost.
  2. Look up the account in the CRM to get the contract details: tier, signature date, contract value, named primary user, named executive sponsor.
  3. Determine which conditional tasks apply based on the account type and contract terms, using the rules in /policies/task-applicability.md.
  4. Walk through each task in the order defined by /templates/onboarding-checklist.md. For each task, ask the CSM for evidence: a CRM field updated, a call logged, a document linked, a Slack message sent. Refuse to mark a task complete without evidence.
  5. Apply the customer-data policy in /policies/customer-data-rules.md — the onboarding record will be referenced in renewal conversations, so the data captured needs to be safe to share with the account team.
  6. Produce the completeness report in the format defined by /templates/onboarding-record.md: tasks completed (with evidence), tasks pending (with assigned owner and due date), tasks skipped (with the reason and approval).
  7. Flag the onboarding for manager review if any required task is skipped, if the onboarding has been open for more than 30 days without completion, or if the customer's primary user has not been trained.

The procedure is what stops the checklist from being a wiki page that gets ignored. Every task requires evidence. Every skip requires a reason. Every overdue onboarding fires a flag.

Step 5: Add the supporting files

  • /templates/onboarding-checklist.md — the full task list, organized by phase (Pre-Kickoff, Kickoff Week, First 30 Days, First 60 Days), with task descriptions, required evidence, and applicability rules.
  • /templates/onboarding-record.md — the strict output format the agent produces when reporting. Tasks completed, tasks pending, tasks skipped with reasons. Required fields per task: completion date, evidence link, owner.
  • /policies/task-applicability.md — which conditional tasks apply for which account types. Be specific: "SSO setup applies if the contract includes the SSO add-on OR the customer is in the regulated tier." Avoid vague rules like "for enterprise accounts."
  • /policies/customer-data-rules.md — what kinds of customer information get captured in the onboarding record. Be careful here: notes about a customer's internal team dynamics or organizational changes are sensitive and should not flow into renewal conversations without the customer's awareness.
  • /policies/escalation-triggers.md — when the agent must flag for manager review. Examples: required task skipped without manager approval; primary user not trained within 14 days of kickoff; executive sponsor introduction skipped; integration health check failed.
  • /examples/complete-onboarding.md — a fully worked example of a successful onboarding record. Every required task completed with evidence, conditional tasks applied correctly, no flags.
  • /examples/incomplete-onboarding.md — an example of an onboarding with skipped tasks and flagged items. Show how the agent should describe what is missing and what the next action is.

Drive the work from chat:

"Draft /templates/onboarding-checklist.md for the Customer Onboarding Checklist skill. Organize into four phases: Pre-Kickoff, Kickoff Week, First 30 Days, First 60 Days. Include the 22 tasks we identified, with required evidence and applicability rules for each."

Review every file. The skill enforces what is in the file — if the policy says "kickoff call is required" without saying what evidence proves the kickoff happened, the agent has to guess.

Step 6: Submit for review and approve

From the skill detail page, click Submit for review. The senior CSM, the CS manager, and a workspace admin walk through the files:

  • Does the task list match what the team actually does for successful onboardings?
  • Are the applicability rules correct — will the right tasks apply to the right account types?
  • Is the evidence required for each task realistic? CSMs will not adopt the skill if it asks for evidence they cannot easily produce.
  • Do the escalation triggers match what the CS manager actually wants to be flagged on?

When approved, the version becomes available to mount. If rejected, the feedback comes back as comments. Author a new draft addressing the points — the file is the contract for what onboarding means at your company.

Step 7: Attach the skill to the Customer Success Agent

Open the Customer Success Agent and attach the approved version with a readable mount path:

/skills/customer-onboarding-checklist

Now the CS Agent runs the reviewed onboarding workflow. The wiki page becomes a reference document, not the source of truth. The CSM with the personal Notes checklist switches over because the agent's record is what shows up in QBR prep and renewal reviews.

Step 8: Validate on real onboardings

Pick two recent onboardings — one strong, one weak. Ask the CS Agent to walk through each one in hindsight:

"Walk through the onboarding for Acme Corp using the reviewed checklist. The account is in the enterprise tier with the integration add-on. Tell me what was completed, what is still pending, and what was skipped."

"Produce an onboarding completeness report for Beta Industries. The contract was signed 45 days ago and we have not had a kickoff call yet."

The senior CSM and the CS manager read the output and check:

  • Did the agent apply the conditional task rules correctly? In the first example, did the integration walkthrough get marked required?
  • Did the agent demand evidence at the right granularity? "Kickoff completed" with no link to a calendar event or recap email is not evidence.
  • Did the escalation triggers fire when they should? In the second example, did "primary user not trained within 14 days" or "kickoff not held within 7 days" produce a flag?

Iterate on the skill files. If the agent over-flagged a low-priority skip, the escalation triggers need to be more precise. If the agent accepted weak evidence, the task definition needs to spell out what counts.

Step 9: Roll out to the CS team

Announce the change to the CS team and the manager:

"Starting next Monday, the onboarding checklist is run by the Customer Success Agent using a reviewed workflow. The 22 tasks are now codified, with explicit evidence requirements. The wiki page is being retired — use the CS agent instead. The onboarding record the agent produces is what shows up in renewal reviews, so the evidence you capture matters."

Tie the change to a real consequence: renewal review. The CSM's onboarding record now follows the account through the lifecycle. Strong onboardings produce strong renewals; weak onboardings produce visible flags. Stop maintaining the wiki page. The CSM with the personal checklist switches over because the company-owned record is what the manager looks at.

Step 10: Improve the skill from real onboardings

After 60 days of real use across five to ten new accounts, patterns surface. Maybe the team realized that the "executive sponsor introduction" task is too vague — it needs sub-steps (initial meeting, follow-up email, scheduled cadence). Maybe a new task became important (security review for accounts in regulated industries). Maybe the evidence requirement for "primary user trained" is too lenient and renewals are revealing that training was nominal, not real.

Open a new draft of the skill, update the policies and templates, submit for review. When approved, deliberately upgrade the CS Agent's attachment using the workflow in Governing Agent Skill versions. Existing onboardings in flight finish on the old version (so the record stays consistent). New onboardings get the new one.

What you built

You have a reviewed Agent Skill that turns the customer onboarding checklist into an enforced, evidence-backed workflow. The skill has:

  • The 22 onboarding tasks codified as a structured list, with required evidence per task.
  • Applicability rules that route conditional tasks to the right account types.
  • A customer-data policy that keeps the onboarding record safe to share with the account team.
  • Escalation triggers that flag onboardings in trouble before the manager notices them in the renewal review.
  • An output format that shows up in QBR prep and renewal conversations, so the work is visible.
  • A clear path to improve the checklist as the CS function evolves.

More importantly, you replaced a wiki page, a personal Notes checklist, and an inconsistent verbal handoff with one reviewed workflow the CS team owns. The new CSM joining the team does not invent their own onboarding approach — they use the CS agent. The renewal conversation six months later does not surface "oh, we never did the integration walkthrough" — the integration walkthrough either has evidence or it has a documented skip reason. The customer experiences a consistent onboarding regardless of which CSM owns their account.

This is what bringing scattered AI use under one platform looks like in customer success: one approved skill, one operational agent, one enforced workflow, with the consequences of skipped steps actually visible.

Where to go from here

  • Add a renewal readiness skill. Build a sibling skill that takes an account's onboarding record plus the last six months of customer health signals and produces a renewal readiness report. The onboarding record from this skill is the input.
  • Connect a sandcastle dashboard. Build a sandcastle that shows onboarding completeness across the customer base, with drill-downs by tier, owner, and pending tasks. The onboarding records this skill produces are the data source.
  • Add a customer health check skill. Once onboarding is solid, the natural next workflow is the periodic health check. Same playbook: define the checks, the evidence, the escalation triggers, the output format.
  • Standardize for self-serve accounts. If your company has a self-serve onboarding path, build a sibling skill that handles the lighter-weight version. Same shape, fewer required tasks, different escalation triggers.