Onboard a new client by settling six things in writing before any work begins: what you are delivering, what you are not, what you need from them and by when, the payment terms and dates, who decides and approves, and how you will communicate. Every dispute that arrives later in a service relationship traces back to one of those six being left implicit at the start.
The word "onboarding" makes it sound like hospitality. It is not. It is the last moment at which you can set terms while both sides are still enthusiastic and nothing is contested, and that leverage disappears permanently the day work starts.
What should you settle before work starts?
Six things, and they take one document and one call. The deliverable stated concretely, the exclusions stated explicitly, what the client must provide and by when, the payment schedule with dates, the single person who approves, and how and how often you will communicate.
The reason to do all six at once is that they interact. A deliverable without exclusions is unbounded. A payment schedule without milestones is untethered from progress. Client inputs without a date are a permanent excuse for delay that becomes your problem. Settling them individually as they come up means settling each one at the worst possible moment, which is when it has already become a problem.
None of this requires a long document. A single page covering those six points, agreed in writing, does more work than a twenty-page contract nobody reads. The thing that matters is that both parties have seen the same words before anyone starts, and that you can point at them without it being an escalation.
What belongs in the scope, and what does not?
Both, and the exclusions matter more. A scope that lists only what is included leaves everything unmentioned in an ambiguous space, and ambiguous space is always resolved in the direction of more work for you.
Write the deliverable as a specific, finishable thing. Not "website improvements" but the number of pages, on what platform, with how many rounds of revision, delivered by what date. The revision count is the single highest-value number in the document, because "until you are happy" is not a scope, it is an open-ended commitment that the client did not realise they were being given.
Then write the exclusions, and make them the things you can already predict will be asked for. Ongoing maintenance after handover. Content and copy the client is expected to supply. Third-party costs and licences. Anything on a different platform. Training. Emergency turnaround. Listing these is not defensive and clients rarely object, because at this stage they are not trying to get free work, they are simply forming an impression of what they are buying. The exclusions are also what let you say yes later, at a price, without it feeling like a refusal.
How do you run a kickoff call?
In half an hour, against an agenda, ending with a written summary you send the same day. Confirm the deliverable out loud, confirm the exclusions out loud, agree the input deadlines, name the decision-maker, and fix the communication rhythm.
Saying the exclusions out loud is the part people skip because it feels awkward, and it is the part that pays. A document nobody read is a weak instrument. A sentence both of you spoke on a call, then confirmed in a written summary an hour later, is a shared understanding, and it changes how the fourth week goes.
The same-day summary is the mechanism that makes all of it durable. Short, plain, sent as an email rather than a document, listing what was agreed and what happens next with dates and owners. It is not a formality. It is the record you will refer back to, and sending it immediately means it goes out while the conversation is fresh and while nobody has any reason to dispute it.
Fix the rhythm too. A named update, on a named day, in a named channel. Clients chase when they do not know when they will next hear from you, and a predictable update removes almost all of that traffic. Silence is what generates anxious messages, not slow progress.
What do you need from the client, and when?
Access, materials and decisions, each with a specific date attached and a stated consequence if it slips. This is the most common cause of a first week that produces nothing, and it is almost entirely preventable.
Ask for it as a short numbered list rather than in prose, because a list gets actioned and a paragraph gets read and forgotten. Logins and permissions for every system you will touch. Brand assets, existing content, and whatever raw material the work is built from. Names of anyone whose sign-off is required. And the one piece of information the whole job depends on, which is different for every trade and which you should have identified while quoting.
Then state the consequence plainly and without threat. If materials arrive a week late, the delivery date moves by a week. Saying it once at the start is a normal scheduling fact. Saying it for the first time in week three, when you are behind and frustrated, sounds like an excuse, and by then the client has usually formed the view that the delay is yours.
When should you collect payment?
The deposit before the kickoff call, and the schedule agreed at the same time. The moment immediately after somebody says yes is the easiest moment in the entire relationship to ask for money, and it never gets easier than that.
There is a diagnostic reason as well as a cash one. A deposit tells you whether the client's payment process works while you have invested nothing but a proposal. A client who pays within a day has a functioning process and treats you as a supplier. A client who queries it, delays it, or asks to skip it has told you something accurate about how the final invoice will go, at a point where walking away is free.
Tie the remaining payments to milestones rather than to dates where you can, so that money follows delivery and your exposure is never more than one stage. The mechanics of the invoice itself, including terms, deposits and what the document must contain, are in how to invoice clients and actually get paid.
What records should you start keeping on day one?
Everything, filed by client and by tax year, from the first message. The IRS's own guidance on record retention sets the baseline at three years, saying to "Keep records for 3 years if situations (4), (5), and (6) below do not apply to you," with longer periods in specific circumstances.
The start of a relationship is when this is easiest and it is when nobody does it. The agreement, the kickoff summary, the invoices, the approvals, and any change to scope should live in one place per client from the beginning, because assembling them retroactively is miserable and because the moment you actually need them is a moment when you will be under pressure.
There is a second reason beyond tax. The written trail is what makes every awkward later conversation straightforward: an approval you can point to, a scope you both signed, a change that was agreed in writing on a date. Operators who never seem to have disputes are usually not luckier. They are just able to find things.
How do you set expectations without sounding rigid?
By framing every term as how the work gets done well rather than as a rule protecting you. The content is identical and the reception is not.
"I keep revisions to two rounds so the feedback stays focused and we actually finish" is the same clause as "two revisions maximum," and it lands as professionalism rather than as a limit. "I send an update every Tuesday so you are never wondering where things are" is a communication term that reads as a service. Clients are not resistant to structure. They are resistant to feeling managed, and the difference between those is almost entirely framing.
The other half is doing the first small thing immediately and well. The same-day summary, the access list arriving within an hour of the call, the first update landing exactly when you said it would. New clients are watching for evidence in the first week, and reliability on small visible commitments is what they use to predict reliability on the large invisible ones. It also sets the standard you will be held to, which is a reason to promise a rhythm you can actually keep rather than the most impressive one.
The honest hard part
The hard part is that good onboarding feels like a delay, and it feels that way to both sides. You want to start the work because starting is progress and because the client is paying. The client wants to see something happen. Spending the first two days on documents and access lists feels like bureaucracy in a small business that is supposed to be nimble.
It is the highest-return two days available. Every hour spent settling scope, inputs and approvals in advance removes several hours of argument, rework and chasing later, and it removes them from the part of the project where you have the least leverage and the most fatigue. The chaotic version of this job is not more efficient. It has simply moved the same work to a worse time and added friction to it.
The second hard part is that it must be the same every time, including for the client you like, the friend of a friend, and the small job that feels too minor to formalise. Those are precisely the engagements that go wrong, because familiarity is treated as a substitute for clarity, and it never is. A process that is skipped when it feels unnecessary is not a process, it is a habit, and it will not be there on the occasion you need it.
If the risk you are most worried about is the work quietly expanding after it starts, that has its own mechanics, and we set them out in how to handle scope creep.
