A new customer signs the contract on a Friday. The kickoff is scheduled for Tuesday. The CSM who'd been their main contact during the sales cycle is on PTO that week. The replacement opens the customer's record in your CRM and finds three sentences: "Excited about the API integration, mid-sized retail, expanding to LATAM next year." That's the entire transferred context. Everything else lives in the original CSM's head, in a Slack thread that scrolled off, and in two emails the customer sent that nobody filed.
This is the onboarding context-loss problem. Sales handed off rich context. Some of it made it to the CRM. Most of it stayed in the air. Now the new CSM has to either ask the customer to repeat themselves on the kickoff call (bad), or wing it (worse), or spend three hours reconstructing the context from scratch (slow).
This post is about keeping the onboarding playbook and the per-customer context in one searchable place — so the kickoff call goes well even when the original CSM is on a beach.
What customer onboarding documentation actually needs to do
Before the mechanics, the shape matters. Most onboarding teams need their docs to do four things:
- Hold a shared playbook — the canonical version of how onboarding works, kept current as the product and the team change
- Hold per-customer context — the specifics of this customer's situation, what they bought, what they care about, who's involved
- Track progress — where each customer is in the onboarding flow, what's overdue, what's blocked
- Survive handoffs — when the CSM changes, the new person can be productive without re-interviewing the customer
A traditional shape is the playbook in a wiki, the customer context in the CRM, the progress in a project tracker. Three systems. Three update obligations. The handoff is rough because the context is split across three places.
A cleaner shape: one notes workspace where the playbook, the customer context, and the trackers all live as markdown pages, with an AI assistant that can read across all of them when you ask. Adjacent shapes — the SOP layer and the company wiki — are covered in Standard Operating Procedures, Without the Wiki Maintenance Tax and Build a Company Wiki from Casual Notes.
The playbook and per-customer pages, all as markdown
In Docapybara, the onboarding playbook is just a nested set of markdown pages. A common shape:
Onboarding → Playbook (the canonical process — phase 0 prep, kickoff call, configuration phase, training, go-live, 30-day check-in)Onboarding → Templates (the template kickoff agenda, the welcome email, the integration questionnaire, the success-plan template)Onboarding → Reference (product setup docs, troubleshooting notes, API docs that come up frequently)Onboarding → Customers → one nested folder per active customer
Page nesting goes as deep as you need. Each playbook page is real markdown content — written process, embedded screenshots, decision trees written as bullets, links to the templates. The page is searchable and editable, not a structured form you fight.
For each active customer, create a page under Customers with the customer name. Inside, you keep a snapshot (what they bought, the contract terms, the named contacts, the timeline, the success criteria they articulated during sales), the context handoff from sales (the actual notes from the sales process, including the recorded discovery call transcripts), an onboarding plan (which phase of the playbook they're in, customizations specific to their situation, target dates), a running log (every meeting, every email summary, every internal note as it happens), and an open items list (what's owed by you, what's owed by them). Plain markdown means the page is searchable and copyable. When the next CSM picks the customer up, they read one page and have everything — not three systems and a Slack thread.
A live database of every active customer's onboarding status
A :::database::: directive embeds a live database directly inside any markdown page. The most useful place to put one in onboarding work: the team's onboarding-ops dashboard page, with one row per active customer and columns for customer, CSM owner, current phase (Pre-Kickoff, Kickoff Done, Configuration, Training, Go-Live Prep, Post-Go-Live), target go-live date, status (On Track, At Risk, Blocked), days-since-last-update, and notes.
Six column types are available, which covers most onboarding-tracking shapes. Sort by go-live date and you see the calendar pressure. Filter by status and you see who needs attention this week. Filter by CSM owner for the one-on-one prep.
When you tell the assistant "move the Acme account to Configuration phase, mark them on track, target go-live April 30, and note the conversation about the LATAM expansion timeline", it updates the row and adds the note to the customer page in one step.
The agent reads across every customer and every playbook page
Capy, the assistant inside Docapybara, has 27 tools and reads across your entire vault when you ask. The kinds of questions that become answerable in seconds:
- "What's our standard kickoff agenda for a mid-market customer with an API integration?" The agent finds the relevant playbook page and shows you. If the customer has unusual requirements, it can also pull the closest precedent from the customer pages — "and here's the kickoff agenda we ran for Acme last quarter, which was a similar profile."
- "Pull every active customer who's been in the Configuration phase for more than two weeks and tell me what's blocking each one." It reads the database and the customer page notes, returns a list with the relevant context.
- "Have any of our active customers mentioned interest in the new analytics module? Pull the conversation context." Cross-customer retrieval, in seconds.
This isn't AI making customer decisions. It's retrieval — the working memory of the onboarding team made actually accessible. The agent-acts-on-docs side of this is laid out in Claude Code for Documents, and the account-relationship layer that picks up after onboarding ends is covered in How Account Managers Keep Client Context From Slipping.
Recording the kickoff call so the context doesn't drift
The most context-rich moment in any onboarding is the kickoff call. The customer talks about their goals. They mention the org chart. They describe constraints — IT review windows, training availability, leadership skepticism about the new platform. Half of that detail won't fit in a written summary.
Docapybara records audio inside the workspace and transcribes with speaker labels — so the kickoff call is captured with who said what. You ask the assistant: "From this kickoff transcript, pull the success criteria the customer articulated, the named stakeholders, and any constraints they mentioned. Add them to the customer page in the appropriate sections."
What comes back is structured context drawn directly from the customer's own words. When the next CSM picks the account up six weeks later, the actual customer voice is there — not a paraphrased summary that lost the nuance.
For mid-onboarding check-ins, the same pattern: record, transcribe, ask the agent to extract the new commitments and update the customer page. The thread between calls stays intact.
PDFs of contracts, security questionnaires, integration specs
Most onboarding involves a stack of customer-supplied PDFs — the signed contract, the security questionnaire they sent during procurement, the integration spec their tech team wrote up, the org chart they shared. They're useful as reference and frustrating to actually use because PDFs aren't searchable as text.
Drop those PDFs into Docapybara and the conversion pipeline turns each one into searchable markdown. The agent can now read across them. When the customer's CIO asks at week six "what was committed in our MSA about uptime SLAs?", the agent finds the clause in the contract PDF and quotes it back. When the technical onboarding hits a question about their integration spec, the agent can search the spec PDF for the relevant section.
The original PDF stays one click away when you need to send the actual document. The text version makes the content searchable across the whole onboarding.
Templates and handoffs that don't lose context
Most onboarding playbooks have templates — the kickoff agenda template, the welcome email template, the success plan template, the executive readout template. The work of customizing each one for a specific customer is mostly mechanical: pull the customer's name, contract terms, success criteria, named contacts, and drop them into the right slots. In Docapybara, you ask the assistant: "Using the kickoff agenda template at Onboarding/Templates/Kickoff and the customer context at Onboarding/Customers/Acme, draft a customized kickoff agenda for the Acme call on Tuesday." What comes back is a draft with the customer's specifics filled in. You edit the parts that need editing.
The same mechanic carries the harder case: the handoff. The original CSM goes on PTO, leaves the company, or gets pulled to a different account, and a new CSM picks up the customer. In a system where context is split across the CRM, Slack, and someone's head, the handoff is a one-hour briefing call followed by three hours of catch-up reading and a hopeful kickoff with the customer. In a system where the customer page holds the snapshot, the running log, the call transcripts, the open items, and the linked playbook context — the handoff is "read this page." The new CSM walks into the next call with the actual conversational context, not a paraphrased version. That's the test of any onboarding documentation system: can it survive the unplanned handoff? A scattered system can't. A markdown notes workspace with an assistant that reads across the whole context can. The institutional-knowledge dimension of this — what happens when the original owner leaves entirely — is covered in How to Document Institutional Knowledge Before People Walk Out the Door.
Try Docapybara free
The fastest test: open Docapybara, pick one active customer, create a page with whatever onboarding context you currently have on them (kickoff notes, the most recent emails, the last status update), and ask the assistant for a one-page handoff brief that another CSM could read in five minutes and run a productive call from. Five minutes of setup, and you'll know whether having the context in one place changes the handoff math.
Try Docapybara free — bring your most chaotic customer onboarding, last week's kickoff transcripts (audio or summary), and the playbook page you've been meaning to update. See how the workspace handles them.