How to Write an Onboarding Guide or Manual (With Checklist Template)

Write an onboarding guide by listing what a new starter must know, do and be given in their first weeks, then splitting it into two documents: a manual that explains how things work, and a checklist of tasks with a named owner and a date against each. Most guides fail because they mix the two.

This is employee onboarding, getting a new hire productive, rather than client onboarding at the start of an engagement. It is written for whoever has been handed the job of documenting it: an HR lead, an office manager, a founder with a second hire arriving on Monday.

What does an onboarding checklist mean?

An onboarding checklist means a list of the concrete tasks that must happen around a new starter, each with an owner and a deadline. It is a tracking document, not a teaching one. If a line on it cannot be ticked by a specific person on a specific day, it belongs in the manual instead.

That test separates the three documents organisations habitually merge into one file.

	Onboarding manual or guide	Onboarding checklist	30-60-90 day plan
What it is	Reference: how things work here	Task list: what must happen, and by when	Expectations for one person in one role
Written for	The new starter, read once then searched	Whoever runs the process: manager, HR, IT	The new starter and their manager together
How often it changes	When something it describes changes	Reused every hire, edited rarely	Written fresh for every hire
Fails when	It becomes a policy dump nobody reads	Tasks are owned by “HR” rather than a person	It sets tasks instead of outcomes

The third column is a different job, covered in how to build a 30-60-90 day plan that survives contact with the role, and the stage-by-stage picture including the first-week schedule sits in what an employee onboarding plan should include. This article is about the two documents you write once and reuse.

How to write an onboarding guide

Write the guide backwards, starting from the first thing somebody needs at nine o’clock on Monday and ending with the policies they can look up in month three. Seven steps, in order:

1. Ask three recent hires what confused them. Not a survey. Ask three people who joined in the last six months what they had to ask a human about, and what they were told twice by different people. Those are your chapters. Most onboarding manuals are written by whoever has the least recent experience of being new.
2. Split reference from tasks before you write a word. Anything with a date and an owner goes on the checklist. Anything that answers a question goes in the guide. Deciding this once prevents the hybrid document that is too long to read and too vague to track.
3. Write day one in the order it happens. Where to arrive or which link to click, who meets them, when lunch is, when they can stop. First days fail on logistics, not culture.
4. Name humans, not functions. “Contact IT” is a dead end. “Message Sam Okoye in #it-help” is a usable instruction. Accept that this section will need editing every time somebody leaves, and edit it.
5. Document the things nobody writes down. How decisions actually get made, which recurring meetings are genuinely optional, what the internal acronyms mean, which channel matters and which is noise. None of it can be looked up, which is why working it out alone takes months.
6. State what settled in looks like. Give an observable description at the end of week one and month one: they have shipped something small, they know who to ask about payroll, they have met everyone they depend on.
7. Delete anything the handbook already says, and link to it. Duplicated policy text goes stale silently. The guide should be the map, not a second copy of the territory.

Keep the tone the same as the way people actually speak internally. A guide written in formal HR register tells a new starter, on their first evening, that the organisation says one thing and writes another.

An onboarding checklist template

Four columns and four phases. The columns matter more than the rows, and the last column is the one most templates leave out.

Phase	Task	Owner (a person)	Done when
Before day one	Laptop built, tested and delivered	IT lead	Tracking number recorded, or device on desk
Before day one	Contract signed and any checks your organisation requires completed	HR lead	Signed copy filed
Before day one	Week one invites sent, buddy confirmed	Hiring manager	Buddy has accepted, calendar is populated
Day one	Access to every system the role needs, tested by the new starter logging in	IT lead	They have logged into each one themselves
Day one	Team introductions and a tour of where things live	Buddy	Introductions made to everyone on the dependency list
Week one	First piece of real work assigned	Hiring manager	Item is in the tracker with a due date
Week one	Payroll, expenses and leave booking walked through	HR lead	New starter has submitted a test expense or leave request
Month one	Objectives agreed and written down	Hiring manager	Both parties hold a copy
Month one	Onboarding review: what was missing, what was wrong	HR lead	Corrections applied to the guide and checklist

“Done when” converts good intentions into evidence. “Set up accounts” gets ticked by the person who created them; “they have logged into each one themselves” gets ticked when it actually works, which is frequently a different day.

Two rules keep the rest honest. An owner is a named person, because a task owned by a department is owned by nobody and gets discovered at 9:15 on Monday. And it is ticked as things happen, not reconstructed before the probation review.

Who owns the onboarding guide once it exists

One named person owns the guide, but the content is written by the people who do the work it describes. HR owns the process and the checklist; the page explaining how engineering releases code has to come from engineering, or it will be confidently wrong within two months.

That is the failure behind most bad onboarding manuals: one person writes the whole thing alone, describing roles they have never held, and the errors surface one new starter at a time. An hour with the hiring manager, the buddy and whoever provisions the accounts removes the guesswork. Projan is built for that kind of session: it pulls the existing document out of Notion or Confluence as context, asks the group in Slack who owns each provisioning task and what the new starter should be able to do unaided by the end of week one, then writes the answers out as a plan with tasks attached. What matters is that the answers come from the people who hold them, not from whoever had a free afternoon.

Maintenance works better as a trigger than a calendar reminder. Make the last item on every checklist the new starter’s own list of corrections, and make applying them somebody’s task rather than a suggestion. A guide that has never been wrong has never been read. Keeping it current uses the same mechanics as writing a standard operating procedure.

Frequently asked questions

How to create an onboarding manual? Start from the questions new starters actually ask rather than from a table of contents. Collect them for a month, group them into six or seven themes, and write a page per theme. Keep it somewhere people can search, link out to the staff handbook rather than copying it, and put the author’s name at the top so corrections have somewhere to go.

How long should an onboarding guide be? Short enough that a nervous new starter reads it on their first evening. Ten to fifteen pages covers most organisations, and much of that should be links rather than prose. If yours runs to forty pages, you have merged the guide with the staff handbook, and the handbook will win by making the guide unreadable.

Should every role have its own onboarding guide? No. Write one company guide covering everything common to every hire, then a short role appendix of one or two pages per team. Duplicating the whole guide per role guarantees that eleven versions drift apart and only the one belonging to the loudest team stays current. The appendix is where a team’s tools, rituals and jargon go.

Is the onboarding guide written for the new starter or their manager? The new starter, with a separate short section for the manager. Mixing the two produces a document that reads as instructions to somebody else while the person it was meant for skims past it. If the manager needs a briefing on their own responsibilities, give them a page of their own and say so in the heading.

The distinction is worth holding on to: the manual answers questions, the checklist proves things happened. Write both, keep them apart, and let each new starter correct whichever one lies to them first.