Five starters in four weeks and the onboarding material is a Google Doc from two years ago that still references a tool you stopped using. The instinct is to block out a week and document everything. You will not finish, and the parts you do finish will not be the parts that mattered.
Onboarding documentation has one property that makes prioritising it easy, if you notice it: the cost of a missing document scales with how many people hit it and how often.
Sort by how many people need it, times how often
A task all five new hires will do weekly is worth documenting before they arrive. A task one of them will do once next quarter is not, and writing it now is a straightforwardly bad trade.
In practice this produces three tiers.
Before day one: shared and frequent
- Getting access to things. Accounts, permissions, VPN, the request process for the tool nobody remembers is gated. This is the single biggest source of week-one dead time and it affects everyone.
- The daily and weekly rhythm. Which meetings, which channels, where work is tracked, what "done" means, who to ask what.
- The two or three core tasks of the role they were hired for, at enough detail to attempt one supervised.
During onboarding: capture as it happens
Everything a new hire has to be shown once anyway. Have the person doing the showing record it, rather than explain it five times in five separate conversations. The fifth explanation is always worse than the first and nobody is taking notes.
Never, or not yet: rare and narrow
The quarterly reconciliation, the annual audit pack, the migration that happens when a client upgrades. Document these when they next occur, with whoever performs them. Writing them speculatively now, before anyone needs them, is how you end up with documentation that is both stale and unread.
New hires are the best gap-finding instrument you will ever have
For about three weeks, a new starter notices everything that does not make sense, and after that they stop noticing because they have internalised it. That window is short and it does not come back.
So use it deliberately. Ask them to keep a running list of every question they had to ask a human, and treat that list as your documentation backlog. It is far more accurate than your own guess about what is missing, because you cannot see your own assumptions.
Two practical rules that make it work:
- Make it explicit that asking is fine and logging the question is the job. Otherwise people stay quiet to avoid looking slow, and you lose the data.
- When you answer a question that should have been documented, write it down then, in the moment. Answering in a direct message and moving on is how the same question gets asked by the next four hires.
Have the new hire write the first draft
This sounds like offloading work onto the least experienced person, and it is genuinely one of the highest-leverage things you can do.
Someone who just learned a task writes better instructions for it than the expert, because they still remember what was confusing. The expert has forgotten which parts are non-obvious, which is why expert-written documentation skips exactly the steps beginners get stuck on.
The pattern: an experienced person shows them, the new hire writes it up, the experienced person corrects the factual errors. You get accuracy from one and clarity from the other, and the new hire learns the task properly because writing it forces the gaps into the open.
Do not build a course
There is a strong pull towards building structured training: modules, a learning path, maybe quizzes. For five hires, resist it.
Course-shaped material takes much longer to produce, goes stale just as fast, and is harder to fix because updating one fact means re-recording a section. A searchable library of short, accurate procedures serves a new hire better on their second week, when the question is "how do I do this specific thing right now" rather than "teach me the domain".
If you later genuinely need training paths, completion tracking, and e-signature compliance, that is a real category of product and tools like Trainual and Whale are built for it. Just do not start there for a hiring wave, because you will spend the four weeks building curriculum instead of documenting access requests.
A four-week plan that works
- Week one: document access and permissions end to end. Have someone outside the team follow it and try to get access to everything. Fix what fails.
- Week two: capture the two or three core role tasks. Screen record someone doing each one rather than writing from memory.
- Week three: write the team rhythm document. Meetings, channels, where work lives, what done means, escalation paths.
- Week four: leave it alone. Do not document the rare tasks. Set up the question log instead, and brief the team that answering in writing is the default.
Where the time actually goes
Notice that almost none of the above is about writing style. The work is deciding what to document and getting it out of people's heads, and the writing is the part that stalls it.
That is the gap Sendabrief closes. Someone records their screen once while doing the task and it becomes a numbered procedure with annotated screenshots. Someone explains a process out loud for two minutes and it comes back structured. The old onboarding deck gets uploaded and turned into actual steps instead of being rewritten by hand. And because every route lands in the same reviewed library, the new hire's draft goes through the same approval gate as anything else, so accuracy does not depend on who wrote it.