The Client Onboarding Document: What to Send After They Say Yes
There is a gap between a signature and the first day of real work, and it is where small projects quietly lose their first two weeks. The client is enthusiastic and has no idea what you need. You are waiting on things nobody has asked them for yet. Both sides think the other one is starting.
The onboarding document closes that gap. It is the most underrated document a small business sends, mostly because people write it as a welcome letter when it should be an operations manual.
It is not a welcome letter
The failure mode here is unusually consistent: it opens by thanking them for choosing you, then introduces the team with photographs, then sets out your values — and the list of things only they can do is somewhere near the end, if it is there at all.
Invert it. A new client already likes you — they just signed. What they do not have is a picture of the next fortnight and a list of the specific things that will stop the work if they are missing. Give them those first and the warmth can go at the bottom, where it reads as sincerity rather than filler.
The seven sections
- What happens in the first two weeks, with dates. Five or six lines. A kickoff call on the 12th, access set up by the 14th, first draft on the 26th. This is the section that converts a signature into momentum, because it gives them something to expect.
- What I need from you. A checklist. Every item has a named owner on their side and a date. See below — this is the section that earns the document.
- Who is who. Two lists side by side: your side and theirs. Beside each name, what to contact them about. “Anything urgent” counts as a category.
- How we work. Meeting cadence, where files live, expected response times in both directions, working hours and time zones, how holidays are handled. Stating your own response time is what makes it fair to state theirs.
- How to ask for a change. The short, human version of the change-control paragraph in the scope document. One sentence about who to tell and what happens next.
- How invoicing works. When invoices arrive, what triggers them, terms, who they go to, and which address. Sorting out the billing contact on day one saves a month later.
- What finished looks like. Two sentences pointing at the deliverables and the acceptance process already agreed. Restating it now, in friendly language, is worth more than the version in the contract nobody re-reads.
The access list is the part that decides your first fortnight
Ask for everything you will need at once, in one list, at the beginning. The alternative — asking for each credential as you reach it — is what actually causes week-one slippage, because each request costs a round trip through somebody who is not your contact.
A usable access item names four things:
- What you need, in the name their IT would recognise — “admin on the Google Analytics 4 property”, not “analytics access”.
- Why, in one clause. People grant access faster when they know what it is for.
- Who on their side can grant it. Often not your contact, which is exactly why this matters.
- By when, and what stops if it is late.
Write the list once, keep it as your own template, and add to it every time a project stalls on something you forgot to ask for. That accumulating list is worth more than any onboarding advice, including this article.
What to cut
- Your origin story. It was relevant when they were choosing; it is noise now.
- A tool tour for tools they will not touch. If they will never open your project tracker, do not spend a section teaching it.
- Restated contract clauses in legal register. Reference them and move on.
- Enthusiasm as a section. One line of it, meant, beats a screen of it.
This is the one document you can legitimately chase
Most of the time, knowing a document was read is for your own judgement and not for saying out loud. An onboarding document is the exception, because it contains requests. Asking whether the access list reached the right person is a normal, useful question, and the answer changes what you do next.
It is also the document most likely to move inside the client’s company. The person who signed is frequently not the person who will grant you access or attend the standups, so this is the classic internal forward. Nothing in the data ever labels a forward — what you can and cannot infer from a new reader is worth reading before you draw conclusions — but a second reader on an onboarding document is usually the operations person, and that is exactly who you wanted.
A practical note on how to send it: this document is addressed to specific people, so send it as a share addressed to them rather than as an open link. That keeps the reader identity meaningful and lets you grant commenting, which is useful here — an onboarding document is one of the few client documents that benefits from being annotated rather than replied to. Commenting requires a share that grants it and a signed-in reader; the exact boundaries are listed on the features page.
Related: the scope document this one operationalises, and the discovery questionnaire that often travels with it.