Client Onboarding Checklist for Freelancers: From Yes to Project Start

A useful client onboarding checklist confirms the agreement, payment arrangements, people, inputs, access and first milestone before delivery starts. I would keep those decisions in one short project record, with a named owner and an honest status for anything missing.

You do not need a client portal to do this well. A shared document and a clear email can be enough for a small project. The point is to make the next action obvious to both sides, not to give your client another system to learn.

This guide covers a freelance service project after the client has agreed to proceed. If you are still deciding scope and price, start with my freelance proposal template. This is an operating checklist, not a contract, regulated identity-check procedure or legal-compliance assessment.

The client onboarding checklist

Before the first delivery task, I would check these eight things:

1. The agreement: both sides are working from the same scope and terms, with the right contracting parties identified.
2. The money: invoice recipient, purchase-order requirements, payment dates and any agreed upfront payment are clear.
3. The people: there is one day-to-day contact and a named person authorised to approve work and changes.
4. The inputs: the brief, source materials and factual claims needed for the first milestone have been supplied and checked.
5. The access: the correct people can reach the necessary files or systems with suitable permissions.
6. The timetable: dependencies, feedback windows and the first milestone date are understood.
7. The working rules: communication, included revisions and the route for extra work are agreed.
8. The finish: everyone knows what files, instructions, approvals and access changes will complete the handover.

I would not mark a project ready because an email asking for these things has been sent. “Requested”, “received” and “checked” are different states. A missing logo may not block an interview; a missing brief may block writing. Record which task each gap affects.

Copy the project-start record

Download the editable client onboarding template. It is a plain-text file you can edit or paste into your own document, without signing up. The core record is below.

PROJECT-START RECORD
Project and agreed scope version:
Freelancer and client contracting names:
Client contact / final approver:
Invoice recipient / purchase-order requirement:
Agreed start conditions and payment status:
First milestone / intended delivery date:
Communication channel / normal response window:

For each requirement record:
Item | Owner | Needed by | Status | Evidence or next action

Status: not requested / requested / received / checked / blocked / not applicable

Scope and terms:
Payment/start condition:
Brief and factual inputs:
Files and permissions:
System access, if needed:
Feedback and approval process:
Handover expectations:

Decision: ready / partly ready for named tasks / not ready
Open blockers and their effect:
Next action / owner / date:

Link to the agreed document version instead of copying the scope into several places. I would keep a record of who confirmed an important decision and when, then update the next action when something changes. For terms that are still unclear, use the freelance contract checklist before relying on this record.

Ask only the intake questions this project needs

A discovery call asks whether the work is a good fit. An onboarding questionnaire gathers what is needed to carry out the agreed work. I would avoid making the client repeat answers you already have.

These six questions are a starting point:

1. Which agreed problem and deliverables are we starting with?
2. Who will consolidate feedback, and who has final approval?
3. Which source materials and factual details are ready, and which are missing?
4. Which existing files or systems do I need, and who can grant the appropriate access?
5. Are there fixed dates, other suppliers or internal approvals that affect delivery?
6. What must be included in the final handover for your team to use the work?

For copywriting, I would add questions about the audience, service details, evidence for claims and tone. For a design project, I would ask about required formats and authorised brand assets. I would not ask every client for a full customer export simply because a form has space for it.

Where answers include personal data, collect enough for the stated task but no unnecessary extras. That reflects the ICO's data-minimisation guidance. A shorter, relevant questionnaire is also easier to complete.

Send a welcome email with one clear next action

I would put the immediate action near the top and link to the record for supporting detail. This is a project email, not a reason to enrol the client in a promotional newsletter.

Subject: Starting [project]: next steps and first milestone

Hi [name],

Thanks for confirming [project / scope version].

The next action is [specific action] by [date]. Here is the project-start
record with the agreed scope, responsibilities and open items: [link].

Before I begin [delivery task], I need [required input] and confirmation
that [agreed start condition] is complete. Please do not email passwords;
use the agreed account-invitation or secure-access process if needed.

You will coordinate feedback, and [name/role] will approve the work.
The first milestone is [deliverable] on [date], assuming [dependencies].

Please send questions through [channel]. My normal response window is
[realistic working-hours window], rather than an immediate reply.

If an input will be late, let me know so we can agree the next workable date.

Thanks,
[name]

Replace every bracketed field before sending. Do not promise a start date while an essential input is unresolved, or invent a response commitment that you cannot maintain. My client-boundaries guide has scripts for keeping those expectations practical.

Worked example: a small website-copy project

This is a fictional example, not a client result. A freelancer is preparing two website pages for a UK service business for an agreed £600 fee. The example assumes the freelancer is not VAT registered, so no VAT is charged. The agreed payment schedule is £300 before work starts and £300 due seven calendar days after the final files are delivered.

The project includes one briefing call, up to 1,000 words across the two pages, one consolidated revision round and an editable handover. Website publishing and ongoing marketing are not included.

My decision here would be partly ready. The briefing conversation can take place, but drafting that depends on unchecked claims or unconfirmed material permissions waits. The first-draft date should be confirmed once those dependencies are resolved.

The same discipline applies to money. “Invoice sent” is not “payment received”. Use the invoice guide for the request itself, then check the actual payment record where an upfront payment is a start condition.

Keep access and client information proportionate

I would ask for the least access needed for the agreed task. A writer preparing copy in a document may not need website administration at all. If a platform supports named invitations, use an appropriate role rather than putting the owner's password in the onboarding form.

The ICO advises organisations to limit access to those who need it and consider multi-factor authentication. Its small-business security guidance is a useful starting point. Record who owns access removal at the end of the project; the checklist is not a place to store credentials.

Personal-data responsibilities need a separate check. Where a controller engages a processor to process personal data on its behalf, the ICO explains that a binding written arrangement is required. Use its controller-processor contract guidance and obtain appropriate advice for the actual relationship. An onboarding checklist is not a substitute for that agreement.

What to do when an input is late

I would name the missing item, explain the affected milestone and give the client a decision to make. Avoid silently absorbing the delay and then working an unplanned weekend to conceal it.

Hi [name], I am still waiting for [input], which is needed for [task].
The original milestone assumed it would arrive by [date].
If it arrives by [new date], I can offer [revised delivery date], subject
to confirmation. Otherwise, I will confirm the next available slot.
Would you prefer that timing, or should we agree a smaller first stage?

Use dates you can genuinely offer and follow the agreed terms. If the client asks for a new deliverable instead, record its effect on scope, fee and timing and obtain the required approval before doing it. A project-start record should reveal a changed agreement, not quietly replace one.

Plan the handover at the beginning

For the fictional copywriting project, I would prepare a short end record like this:

This is an example of what to record, not evidence that a real project was completed. Portfolio use is a separate permission question. If you later want to describe the work publicly, use the portfolio case-study guide and check what you may show.

Start with the lightest useful system

For an occasional project, I would begin with this record, a document folder and a calendar. Add software only when the repeated administration becomes a genuine problem: missed dependencies, multiple approvers or difficulty finding the latest agreed version.

If the issue is recording work for an hourly agreement, use the billable-hours template. Do not assume every onboarding or administrative hour is chargeable; the agreement determines that. If the issue is an unclear scope, another app will not resolve it.

My final check is simple: can the client and I each name the next action, its owner and what must happen before delivery begins? If not, I would resolve that gap before adding more process.

Spot something that needs correcting? See the corrections process.