task-ops
The contract is signed and the deal moves from a pipeline to a project. That is the moment most small teams improvise. Someone emails the client asking for logins. Someone else opens a folder. A kickoff call gets booked for the following Tuesday because that is when the room is free. Three weeks later the work has still not started, and nobody can say which of the four people involved was supposed to chase the brand assets.
A client onboarding checklist exists to remove that improvisation. Not to make the relationship feel corporate, and not to produce a document nobody opens. The point is narrower: to fix the order of the steps, name the owner of each one, and make the two or three items that actually block delivery visible on day one rather than day twenty.
What follows is the sequence in the order it runs, the parts that reliably stall, and the question of where the checklist should live so that it gets used a second time.
It helps to be blunt about the output. Onboarding is finished when four things exist, and it is not finished when the kickoff call is over.
A scope everyone reads the same way. The proposal said "website refresh". The client heard "including the blog migration". The team heard "five templates". If onboarding does not force that gap into the open, delivery will.
Access that works. Analytics, the CMS, the domain registrar, the design files, the brand kit, the ad accounts. Every one of these is owned by a person who may have left the client's company. Requesting them on day one is what makes the difference between a two day delay and a two month one.
A named person on each side. Not a committee. One person at the client who can approve, and one person on the delivery side who owns the relationship. Projects with two approvers take roughly twice as long to get a decision, because each approver waits to see what the other says.
A schedule the client has agreed to in writing. Including the dates the client owes something. Most slipped deadlines in agency work are client side, and almost none of them were written down as client obligations at the start.
Everything in the checklist below serves one of those four outputs. If a step does not, it is ceremony and can be cut.
Two things belong here and almost never happen here. The first is the internal handoff from whoever sold the work to whoever will deliver it. The seller knows things that are not in the proposal: what the client is anxious about, who on their side was sceptical, what was promised verbally in the third call. Written down in ten minutes, that becomes the most useful document in the project. Left in the seller's head, it becomes the source of the first three misunderstandings.
The second is the access list. Send it with the contract, not after. A list of the accounts that will be needed, described in plain terms, with a note about why each is required. Clients treat requests attached to a contract as part of signing. Requests sent afterwards go to the bottom of an inbox.
The intake questionnaire is the one part of onboarding that small studios tend to over engineer. Forty questions produce forty thin answers and a client who resents the form. Twelve questions produce twelve usable ones.
Keep it to what changes the work: who the audience is, what has already been tried, what the hard constraints are, who has veto power, what "done" looks like, what the client considers a failure. Ask for examples of work they admire and work they hate. The second question is more informative than the first.
Send it with a deadline and a reason for the deadline. "Before the kickoff so the call can be about decisions rather than background" is a reason a client accepts.
This is the part that should be mechanical, and the part that most teams rebuild by hand every time. A project space, the standard task list for this type of engagement, the folder structure, the shared inbox rule, the time tracking codes, the billing schedule entered before anyone forgets it.
If the studio does three kinds of engagement, there should be three templates, each containing the tasks that engagement always needs. Duplicating a template takes a minute. Remembering what a brand identity project needs at week four takes experience nobody has at 9am on a Monday. Tools differ a lot in how well they handle this, which is worth checking before committing; the side by side comparisons make the difference in template and duplication behaviour fairly easy to see.
Run it after the intake is returned, not before. A kickoff held without the questionnaire back is a background briefing, which is a waste of the client's most attentive hour.
Cover four things and nothing else: confirm the scope in the words both sides will use from now on, walk the schedule including the dates the client owes something, agree the communication channel and the response expectations on both sides, and name the approver. Twenty minutes of that is worth ninety minutes of introductions.
Send the notes the same day. Not a transcript. Five bullets of what was decided and who owes what by when. That document is what gets referred to in week six when memory has diverged.
Onboarding does not end at kickoff, and treating it as though it does is why so many projects have a quiet, expensive third week. Two checkpoints matter. At the end of week one, confirm that every access request has actually been granted and tested, because access that was promised is not access that works. At the end of week two, deliver something small and visible, even if it is not the real deliverable. A sitemap, a moodboard, a first draft of the content inventory. Clients who see nothing for a month start to wonder what they bought.
Across most agency work, the same three items are responsible for the majority of onboarding slippage, and all three are client side.
| Blocker | Why it stalls | What shortens it |
|---|---|---|
| Account access | The account owner left, or nobody knows who the owner is | Request at contract signing, with a named fallback contact |
| Brand and content assets | The client assumes assets exist; they turn out to be scattered or missing | Ask for a specific file, not "the brand kit", and offer to audit what exists |
| The approver's calendar | Approval sits with someone who was never in the sales conversation | Name the approver in the kickoff and book their review slots in advance |
The pattern is the same in all three cases. The delay is not caused by the client being slow. It is caused by a request that was vague, late, or aimed at the wrong person. A checklist that fixes those three things earns its existence even if the rest of it is ignored.
One more note on access. Test each credential the day it arrives. A login that has been handed over but sits untested for a fortnight is a login that will fail at the exact moment the work depends on it, and by then the person who issued it has moved on to something else.
A checklist that lives in a document gets read once. A checklist that lives where the work happens gets used. The realistic options for a small team look like this.
| Where it lives | Works well for | The cost |
|---|---|---|
| A written document or wiki page | Explaining the process to a new hire | Nobody ticks anything; no record of what was skipped |
| A spreadsheet copied per client | Small teams, very cheap to start | Versions drift; no notifications; no link to the actual work |
| A duplicated board or project template | Repeating the same engagement type | Requires a tool where templates are genuinely reusable |
| A dedicated onboarding platform | Firms onboarding dozens of clients a month | Another subscription and another system to keep in sync |
For an agency running a handful of concurrent projects, the third row is usually the right answer. The onboarding checklist becomes a board that is duplicated per client, sitting alongside the delivery work rather than in a separate system. The steps have owners and dates because they are tasks, not bullets. The kickoff notes are attached to the card they belong to. When a step gets skipped, the skip is visible.
That also solves the second use of a checklist, which is improvement. After ten projects, the board shows which step is always late. A document cannot tell anyone that.
Two practical requirements follow. The tool has to let a template be duplicated without a paid upgrade, and it has to hold the conversation next to the task, because onboarding is mostly correspondence. A project workspace that keeps chat, dates and the checklist in the same place removes the step where somebody copies an email into a task comment.
Often enough to plan for, the intake turns up something that changes the job. The analytics have not been tracking conversions for a year. The content the proposal assumed existed does not. The previous supplier left the site on a platform version that cannot be upgraded without a rebuild. The brand guidelines are three contradictory PDFs.
The instinct is to absorb it quietly and get on with the work. That instinct is what turns a profitable engagement into a loss, because the extra work is invisible to the client and therefore unbillable in their mind.
The alternative takes an hour. Write down what was found, what it means for the schedule, and the two or three options for handling it, with the cost and the consequence of each. Send it as a short note before the kickoff rather than raising it in the call, so the client has time to think rather than react. Most clients accept a scope change presented as a finding. Very few accept one presented as a complaint in week five.
Two details make this work. Put a decision date on the note, because an open question left with a client stays open indefinitely. And record the finding on the onboarding board itself, not only in email, so that the reason the schedule moved is still discoverable when someone asks in three months.
Three numbers are enough, and they take about ten minutes a month to maintain.
Days from signature to first deliverable. The single most useful number. It captures access delays, intake delays and kickoff scheduling in one figure, and it is hard to argue with.
Number of steps skipped per project. Recorded honestly, this points at the steps that are not worth having. A step skipped in nine projects out of ten is not a discipline problem. It is a step that should be deleted.
Client side items delivered on the agreed date. If this is low, the problem is usually that the dates were never framed as commitments. Naming them in the kickoff and writing them into the notes moves this number more than any amount of chasing.
Avoid measuring onboarding by client satisfaction surveys sent at week two. Clients are polite early. The honest signal arrives later, in whether the project shipped near its original date.
Take the next contract and do one thing differently: send the access list and the intake questions with the contract itself, before anyone thinks about a kickoff date. That single change moves the most common source of delay two weeks earlier in the project.
Then, after that project, turn whatever sequence was actually followed into a duplicable template rather than a memory. If the team does not have a place to keep it, Pinateca is free for up to five people and ten boards, which is enough to run the onboarding board for several clients at once.
For a small studio running a defined engagement, signature to first visible deliverable in two weeks is a reasonable target. Longer than four weeks usually points at account access or an unnamed approver rather than at the amount of work involved. Measuring the gap for a few projects will show which of the two is the real cause.
It depends on volume. Firms bringing on dozens of clients a month get real value from software built for it, because the automated reminders and client portals do work that a person would otherwise do. A team running a handful of concurrent projects usually gets the same result from a duplicated board template inside the tool they already use for delivery, without adding a second system to keep in sync.
Around twelve questions, all of which change the work: audience, previous attempts, hard constraints, who holds veto power, what done looks like, and what the client would consider a failure. Asking for examples of work the client dislikes is often more informative than asking what they admire. Anything that could be answered from the proposal should be cut.
One named person on the delivery side, usually whoever will run the project rather than whoever sold it. Shared ownership is the most common reason steps get skipped, because each owner assumes the other handled it. The seller still has a role, which is the written internal handoff before the contract is countersigned.
Customer onboarding usually means getting a self serve user to their first success inside a product, and it is often automated. Client onboarding is the start of a service relationship, where the blockers are access, scope and approval rather than product comprehension. Advice written for software onboarding tends to over weight email sequences and under weight the access list, which is the part that actually delays agency work.