An onboarding playbook is the working document set that tells a new hire, their manager and everyone who touches the first months what happens, who owns it, and how decisions get made in the role. A good one has a clear timeline and named owners. It also holds the part most playbooks leave out: the exceptions, thresholds and reasoning that experienced people carry in their heads.
Most playbooks fail on that last point. They are checklists with a welcome message on top. This guide shows what to include, how to structure it, and how to fill it with knowledge that is usually lost.
TL;DR
- A playbook is more than a checklist. It combines a timeline, role-specific procedures, named owners and the reasoning behind decisions.
- Plan for far longer than week one. UNC's HR guidance summarizes expert views that onboarding should run about a year.
- Make manager accountability explicit. Role clarity and supervisor follow-through are the most common failure points.
- Capture expertise by interviewing the people who do the work, not by asking them to write documents from scratch.
- Review the playbook after every hire. A playbook nobody updates becomes folklore.
Table of Contents
- What an onboarding playbook is (and what it is not)
- Why the stakes are higher than a welcome email
- The parts of a playbook that carry the load
- A 30-60-90 skeleton you can copy
- Onboarding playbook examples by role
- Why playbooks go stale, and how to stop it
- How to capture the knowledge for your playbook
- Our perspective: documents hold rules, people hold judgment
- Putting Kept to work on your playbook
- Frequently asked questions
- Sources
What an onboarding playbook is (and what it is not)
People use the word loosely. Some mean a checklist of accounts to create. Some mean a culture deck. Some mean a full operating manual for a role.
We use it this way: a playbook is the set of plays your organization runs when someone new arrives, written down so they run the same way whether the usual person is available or not. A play has a trigger, an owner, steps, and the judgment calls inside those steps.
That definition separates it from neighboring documents:
| Document | Answers | Typical gap |
|---|---|---|
| Checklist | Did the task get done? | Says nothing about why or when to deviate |
| SOP | What is the standard procedure? | Rarely records exceptions |
| Culture deck | What do we value? | Not tied to daily decisions |
| Playbook | Who does what, when, and how do we decide? | Needs upkeep to stay true |
The playbook can contain all three of the others, but it earns its name when it connects them to a timeline and to people.
Why the stakes are higher than a welcome email
The numbers on onboarding quality are not flattering. A roundup of employee onboarding statistics cites Gallup's finding that only 12% of employees strongly agree their organization does a great job of onboarding. The same roundup reports that new hires are more likely to call their onboarding exceptional when their manager is actively involved. Treat these as secondary reporting of the original surveys and check the primary sources before quoting them in your own materials.
Research on socialization points the same way. A dissertation applying organizational socialization theory found that a lack of role clarity and weak supervisor accountability were central pain points, and that checklists alone did not carry new staff through the informal norms of a team. That matches what most managers see: the checklist gets finished and the new hire still does not know who to ask or what good looks like.
There is also the knowledge side. A paper on process documentation and skill retention in business process management treats documented processes as a way to keep skills when people move on. If your best operator leaves and your playbook only lists the steps, the new person inherits the ceremony without the judgment.
The parts of a playbook that carry the load
Some steps in a procedure are load-bearing: remove them and the outcome fails. Others are ceremony: they exist because someone once needed them. A playbook should help the new hire tell the difference. These are the components we would build first.
1. A timeline with phases, not just a first week
The UNC guidance describes onboarding as a strategic, multi-dimensional experience rather than a single orientation event. A study of IT-sector staff, published in 2022, examined extended onboarding and its effect on engagement and retention. One summary of that study reports that a nine-month program improved one-year retention against a control group. It is a single study in one sector, so read it as a reason to extend your plan, not as a promise.
A workable structure:
- Before day one: access, equipment, a named manager and buddy, the first week's schedule.
- Days 1 to 30: orientation, the team's tools, first small tasks, and the core procedures for the role.
- Days 31 to 60: supervised work on real tasks, with exceptions introduced deliberately.
- Days 61 to 90: independent ownership of defined work, a formal review with the manager.
- Months 4 to 12: periodic check-ins, deeper projects, feedback on the onboarding itself.
Our employee onboarding checklist for managers lays out the first 90 days in more detail if you want a manager-facing version.
2. Named owners for each play
Every step needs one person, not a department. "HR sends the welcome packet" is fine. "IT provisions the laptop" is fine. "The team ensures the new hire feels included" is not a step, because nobody owns it.
The same logic applies to people outside the payroll. Our piece on contractor onboarding uses five checks, each with an owner, because contractors tend to fall between HR and the hiring team.
3. Role-specific procedures
The research background on post-pandemic teams is blunt: simply moving physical induction manuals into digital files is not enough. Teams need role-specific onboarding procedures that are standardized, plus mentorship networks to make up for the hallway conversations that remote work removes.
So the playbook should have a general track (everyone gets it) and a role track (this is how a support lead, an analyst or an engineer gets to competence). The role track is where most of the value, and most of the missing knowledge, sits.
4. Decisions, thresholds and exceptions
Here is where we think most playbooks break. A procedure that says "approve refunds under the limit" does not say what happens at 1% over the limit for a customer of ten years. The experienced person knows. The document does not.
For each important procedure, record:
- the rule as written,
- the exceptions people actually grant,
- the reason behind each exception,
- who to ask when the case is genuinely new.
The rule is what the document holds. The exception and the reason are what the person holds. A playbook that captures both is the one a new hire can use alone on a Tuesday afternoon.
5. Feedback loops
Ask each new hire at 30, 60 and 90 days what was missing, wrong or confusing. Put the answers in the playbook within a week. This is the cheapest quality control you have.
A 30-60-90 skeleton you can copy
This is a generic structure. Adapt it per role.
| Phase | Goal | Manager does | New hire does | Evidence of progress |
|---|---|---|---|---|
| Days 1 to 30 | Orient and learn | Weekly one-to-one, explains how decisions are made | Learns tools, shadows core procedures | Can describe the role's main workflows |
| Days 31 to 60 | Apply with support | Reviews first real work, introduces exceptions | Handles routine tasks, logs questions | Fewer repeated questions, correct routine output |
| Days 61 to 90 | Own defined work | Agrees goals for next quarter | Runs defined work independently | Manager and hire agree on scope of ownership |
| Months 4 to 12 | Deepen and belong | Monthly check-ins, career conversation | Takes on projects, mentors the next hire | Retention conversation, updated playbook |
Onboarding playbook examples by role
No single template fits every team, so here is how the contents shift.
Customer-facing support team. The role track focuses on escalation paths, tone, and the judgment calls: when to refund, when to loop in an engineer, which accounts get different treatment. Exceptions matter most here.
Engineering team. The role track covers the repository, deployment, on-call, and the history of why systems are the way they are. A decision log beats a wiki page of diagrams. Our video for engineering managers shows how to onboard engineers from what the team already knows.
HR and operations. Here the playbook doubles as a compliance record. The reasoning behind a decision matters when someone asks later why it was made, which is why we wrote about audit trails that capture decisions, not steps.
Client onboarding. Some readers searching for a playbook mean onboarding customers rather than employees. The structure carries over: phases, owners, exceptions. The difference is that the customer's timeline becomes the spine of the document.
If your technical team is large or your workflows are tangled, it can help to map where work really flows before you document it. Raremind's AI readiness assessment describes one way to map workflows before you choose tools, which is a sensible first step if you do not yet know which processes deserve a play.
Why playbooks go stale, and how to stop it
Three things kill a playbook.
It is written once, by someone who no longer remembers the questions. The person who knows a process best is usually the worst at explaining it to a beginner. They skip steps that feel obvious.
It is written in a document nobody owns. If the playbook has no editor and no review date, it will drift. Give it an owner and a quarterly review.
It records the official process, not the real one. People work around broken procedures and never tell the document. The workaround is often the real knowledge.
A fix we like: version your processes and note why each change was made. We cover that in process version control for HR and operations. When the reason for a change is attached to the change, the next person can tell whether to keep it.
How to capture the knowledge for your playbook
Asking experts to "write it down" mostly produces thin documents or none at all. Interviewing works better. Think of oral history or an investigative interview: you ask for a specific case, then the next one, then "what would you have done if the customer had been on the enterprise plan?" Exceptions come out because you ask for them.
A practical sequence:
- Pick three to five processes. Choose the ones where a mistake is costly or where one person holds the knowledge.
- Interview the person who does the work. Use real recent cases, not hypotheticals.
- Record the rule, the exceptions and the reasons in separate fields so they cannot blur together.
- Have the expert review the draft for accuracy, then have a recent hire test it.
- Attach it to the timeline. Each procedure belongs to a phase and an owner.
- Schedule a review tied to the next hire, so the document gets tested against a real newcomer.
We describe a staged approach in piloting onboarding documentation in four to eight weeks, and a personal version for team leads in capturing three to five processes in a personal knowledge workspace.
Our perspective: documents hold rules, people hold judgment
We have read a lot of onboarding playbooks, and the pattern is familiar. The first half is excellent on logistics. The second half, where the real work begins, says "shadow a colleague." That is not a plan. It is an admission that the knowledge lives in someone's head and nobody has worked out how to get it out.
That is the problem Kept is built around. We use conversational AI to guide people through describing their work in their own words, asking follow-up questions about exceptions and reasoning, then structuring the answers into procedures that can be searched and cited. The aim is not to replace the expert's judgment but to keep it from walking out the door.
Three convictions shape how we think about playbooks:
- Capture should be opt-in and visible. People share more when they control what is captured, can review it, and can delete it.
- The why is the asset. A step list can be rebuilt. A decision's reasoning, once lost, rarely can.
- Onboarding is the best forcing function. A new hire exposes every gap in your documentation within weeks, which makes it the ideal moment to fix them.
If your playbook can answer "what would you do if this were unusual?", you have a playbook. If it cannot, you have a checklist with ambitions.
— Anthony
Putting Kept to work on your playbook
If you want to build the role track from what your team already knows, our onboarding use case shows how guided conversations become structured, searchable procedures. Business workspaces have access controls, opt-in capture, review and deletion. For plan options, see the pricing page, where you can choose between kept for you and kept for business.
Frequently asked questions
What should an onboarding playbook include?
A timeline in phases, named owners for each step, role-specific procedures, and the decisions and exceptions behind those procedures. Add a feedback loop so each new hire improves the next one's experience. Start with the roles where hiring is frequent or where one person holds critical knowledge.
How long should an onboarding playbook cover?
Longer than the first week. Expert guidance summarized by UNC's HR office suggests onboarding should last about a year. In practice, detail the first 90 days and then schedule lighter check-ins through month twelve.
How is a new hire playbook different from an onboarding checklist?
A checklist confirms that tasks were done. A new hire playbook explains who owns each task, when it happens, how to handle exceptions and why the procedure exists. The checklist can live inside the playbook as one of its tools.
Who should own the playbook?
One named person, usually in HR or operations, with each role track owned by the relevant team lead. Ownership matters more than the tool you use. Without it, updates stop and the document goes stale.
How do we get experts to contribute without adding to their workload?
Interview them about recent real cases instead of asking for a finished document. A short guided conversation, reviewed afterward, takes less of their time than writing and produces better detail on exceptions.
Sources
- Enhancing Onboarding for Staff Engagement and Belonging, UNC Human Resources
- The Overlooked Majority: The Socialization of New Field-Trained Community College Professionals, University of Texas at Arlington
- Knowledge Transfer During Onboarding in Organisations in Post Covid Era
- Onboarding Effects on Engagement and Retention in the IT Sector
- Knowledge Transfer and Skill Retention in Global BPM: Leveraging Process Documentation for Workforce Development
- 25+ Employee Onboarding Statistics and Trends for 2026, Devlin Peck