Build onboarding docs for a new hire
Assemble a role-specific onboarding guide from what your company already knows.
An onboarding checklist tells a new hire what to do in week one; the docs behind each item are the part nobody has time to write. The people who should write them no longer remember what a newcomer doesn't know. This workflow builds the onboarding guide from what your company already knows, in Slack, Notion and Google Docs, then asks teammates to fill only the gaps that aren't written down anywhere.
What does this workflow do?
Tell the agent who's starting and in what role. It assembles a role-specific onboarding doc from your existing knowledge: how the team works, the tools and how to get access, who owns what, current projects and their state, the vocabulary and abbreviations your company uses, and where to ask which kinds of questions.
For everything undocumented, it asks the team, one small question per person: the engineering lead gets "What should a new backend dev read before touching the deploy pipeline?", the last person who onboarded gets "What do you wish someone had told you in week one?" Their answers go into the doc and into the knowledge base, so the next hire's doc starts more complete.
How does it work?
- Give it the role and start date. Optionally a template or an old onboarding doc to inherit structure from.
- It drafts from existing knowledge. Team structure, tool stack, project state, key decisions and their reasons, drawn from your connected sources with permissions respected.
- It identifies the gaps. What a newcomer in this role needs that no doc covers, informed by the questions past new hires actually asked in Slack.
- It asks teammates to fill them. Small, specific information requests. The manager approves the final doc before day one.
- It stays live after day one. The new hire asks follow-up questions and gets answers with sources. Questions with no answer route to the right colleague, and the doc updates.
A new hire onboarding checklist to start from
- Before day one: accounts and access requested (email, Slack, the tools the role needs), equipment ordered, and the team told who is joining and why.
- Day one: a working laptop, a first task that can be finished the same day, and a named buddy for questions that feel too small for the manager.
- Week one: intro meetings with the people the role works with most, and a walkthrough of how the team ships: standups, reviews, deploys.
- The role guide: what this person owns, the current state of their projects, and who to ask about what.
- The vocabulary: the product names, abbreviations and inside shorthand everyone else uses without noticing.
- Key decisions: the five to ten past decisions that explain why things are the way they are.
- Week two to four: a real project with a clear owner and a check-in cadence, plus expanding access as needed.
- The 30-day check: what's still confusing, what the docs didn't cover, and what should be written down for the next hire.
Where the checklist meets the workflow
Most items on that checklist point at a document: the role guide, the vocabulary, the decisions, the walkthroughs. Those are the pieces that go stale or never get written. This workflow fills exactly those gaps: it drafts each document from what your company already knows and asks teammates only for what's missing, so the checklist arrives with its reading list attached.
Why generate a fresh doc for every hire?
A static onboarding page is written once, decays quietly, and serves every role the same generic soup. A generated doc is current on the day it's needed, specific to the role, and cheap enough to remake for every hire. The maintenance burden that kills onboarding wikis never accumulates.
The compounding matters most. Every question a new hire asks, and every answer a colleague gives, persists. Companies that onboard four people a year stop paying the same explanation cost four times. Pair this template with the knowledge base gap finder and onboarding becomes the input that keeps your documentation honest.
Works with
Notion, Google Docs, Slack, Gmail. Run per new hire, or per role to maintain standing guides.
Further reading
Frequently asked questions
What goes into the onboarding doc?
Role-specific structure: the team and who owns what, tools and access, active projects and their state, key decisions and vocabulary, first-week expectations, and where to ask questions. You control the template.
What if our documentation is thin?
That's the case this is built for. The agent drafts what it can from Slack history and scattered docs, then fills the rest by asking teammates targeted questions. Thin documentation means more asking on the first run and much less on the second.
Do teammates get flooded with questions?
No. Each person gets a few specific questions matched to what they know, spread before the start date. Answers are reused for every future hire, so the asking shrinks over time.
Can the new hire ask it questions after starting?
Yes. The doc is a starting point, and the agent answers follow-ups with sources. Undocumented questions route to the right colleague, and the answer is captured for the next person.
Does the manager review the doc before the hire sees it?
Yes. The manager gets the draft for approval, edits stick, and the workflow learns the team's preferences for the next hire.