Onboarding documentation usually exists before anyone names it. It's in the notes from the last training call, the checklist someone pasted into an email, the PDF from a vendor, the SOP written after a mistake, and the answer you keep sending when a new person asks the same question.
Docapybara helps you turn that existing material into a practical onboarding path. The point isn't to make a polished handbook first. The point is to gather the source material, let Capy search and draft from it, then edit the result into pages a new person can actually use.
Start with the role, not the whole company
Company-wide onboarding is too broad for a first pass. Pick one role or responsibility: front desk coverage, field technician, office coordinator, property maintenance, inventory clerk, support triage, weekend manager.
Create a page for that role. At the top, write what this person needs to be able to do after the first week: answer the phone, complete a site visit, receive a shipment, update a customer, close the office, escalate an incident. Specific verbs keep the documentation grounded.
If the role depends on repeatable process, Standard Operating Procedures, Without the Wiki Maintenance Tax is the natural companion. Onboarding tells someone where to start. SOPs tell them how to do the recurring work.
Gather the source notes before drafting
Don't open a blank page and try to write the perfect onboarding guide from memory. Pull in the material you already have: training notes, meeting transcripts, checklists, vendor PDFs, policy snippets, field notes, escalation examples, and common questions.
Docapybara can hold typed notes, uploaded PDFs converted to searchable markdown, and audio recordings with speaker diarization. That mix matters because onboarding knowledge rarely arrives in one clean format.
Once the sources are in the vault, ask Capy to list what each source appears to cover. This first pass is not the guide. It's the map of raw material, and it usually reveals both duplication and gaps.
Ask Capy for a first outline with source links
The safest prompt is specific: "Using the linked notes on this role page, draft an onboarding outline for the first five working days. Include source links for each section and mark anything that needs human confirmation."
That last instruction keeps the draft honest. Capy can search, group, and write, but it shouldn't invent missing process. If the notes don't explain how expense approvals work, the outline should say that, not pretend.
For a deeper product explanation of why source-linked drafting matters, see Claude Code for Documents. The useful part is that the agent is working inside your documents, not summarizing from a separate pile.
Separate welcome context from task instructions
New people need two kinds of documentation. They need orientation: who does what, where things live, what words mean, how the week usually feels. They also need instructions: how to submit a request, process a return, inspect a unit, or respond to an alert.
Keep those separate. A role overview page can hold the friendly map. Linked SOP pages can hold the task steps. That way the welcome page stays readable, and the step-by-step pages can be maintained when the process changes.
If onboarding includes field work, AI Notes for Field Teams shows how site notes, shift context, and follow-ups can live in the same vault.
Use databases for progress, not surveillance
An onboarding tracker should help the new person and the manager see what's been covered. It shouldn't become a heavy reporting machine.
Use a small inline database via the :::database::: directive with columns for topic, source page, status, responsible trainer, review date, and notes. Keep statuses plain: Not started, In progress, Reviewed, Needs update. Link each row to the relevant page.
This makes gaps visible. If "vendor escalation" has no source page, you know what to write next. If "closing checklist" hasn't been reviewed in a year, you know where the risk is.
Turn training conversations into durable notes
The best onboarding material often comes from live training. Someone explains what to do when a tenant calls after hours, or how to spot a receiving discrepancy, or which vendor needs a phone call instead of an email.
When appropriate, record those sessions in Docapybara. Ask Capy to turn the transcript into a training note with concepts, examples, terms, decisions, and follow-up questions. Then edit it while the trainer's memory is fresh.
This is especially useful for work that lives in judgment rather than checklists. The transcript catches the "usually," "except when," and "ask me if" moments that formal documentation tends to miss.
Review the guide after the first real onboarding
The first person through the guide is your best editor. Add a feedback section to the role page. Ask them which step was confusing, which link was missing, which term needed definition, and where the documentation assumed too much.
After the first week, ask Capy to compare the feedback notes with the onboarding pages and suggest updates. You decide what changes. The agent makes the maintenance pass less painful.
For broader internal knowledge bases, Build a Company Wiki from Casual Notes extends the same pattern beyond one role.
Start with the next repeated question
Pick the question new people always ask. Create a page for the answer. Link the source notes. Ask Capy to draft the first version, then edit it into something direct and kind.
Do that a few times and onboarding stops being a heroic writing project. It becomes a set of useful pages growing out of the work you already do. Try Docapybara free and turn one repeated explanation into a page the next person can use.