Build onboarding docs for a new hire
Assemble a role-specific onboarding guide from what your company already knows.
New hire onboarding docs have a structural problem: the people who should write them are the people who 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.
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.
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.