Practical Guide · Use the checklist for the needs of the project. The worked onboarding sequence is fictional.
A signed agreement does not necessarily mean a project is ready to move. I may still be waiting for files, access, a decision maker, or a billing detail that affects the first deliverable. I treat onboarding as the point where an agreement becomes an operational project.
The checklist below is for a freelancer, solo operator, or small service business. Copy it into the project workspace. Mark each item done, not applicable, or waiting—with an owner and next check date. Ask for what the work needs, rather than collecting information because the checklist has a box for it.
Before kickoff
- ☐ Agreement and scope: Signed agreement or the required scope confirmation is in place; deliverables, exclusions, and changes are understood.
- ☐ Billing: Payment or invoicing arrangements are confirmed, including any agreed deposit or purchase-order requirement before starting.
- ☐ Main contact: One person coordinates questions; the person with final approval is identified.
- ☐ Objective and deliverables: Record the problem to solve and the concrete work to hand over.
- ☐ Timeline: Record the first milestone, input deadlines, and review dependencies—not just the final delivery date.
- ☐ Communication: Agree on the main channel and where the project record lives.
- ☐ Required inputs: Send one consolidated request for the files, assets, and access needed for the first task.
Access and working setup
- ☐ Accounts and permissions: Obtain the access needed for the agreed work and test that it works. Keep passwords out of ordinary project notes.
- ☐ Shared folders: Confirm both sides can find the current materials and distinguish them from superseded versions.
- ☐ Project workspace: Put scope, milestones, decisions, and waiting-on items in one obvious home.
- ☐ Communication channel: Confirm invitations work and the right contact can see the project conversation.
- ☐ Approval route: Identify who reviews, who consolidates feedback, who approves, and where the decision is recorded.
A workspace need not be elaborate. The guide to a simple client portal explains what is worth putting in one place. A portal is useful only if the client can find and use the material.
Project context
- ☐ Audience and stakeholders: Know who the work is for and who needs to be consulted.
- ☐ Existing materials: Identify the current brief, reference files, brand assets, or other inputs relevant to the deliverable.
- ☐ Previous work: Ask what should be retained, changed, or avoided, and why.
- ☐ Constraints and risks: Record known limits, unavailable inputs, external dependencies, and decisions still open.
- ☐ Definition of done: Agree what must be delivered and approved for this stage to be complete.
Keep the useful answers with the project, not scattered across a welcome form, inbox, and chat. Work documentation should preserve the decision and its context without copying every conversation.
Communication expectations
- ☐ Decisions: Agree where approvals and scope changes will be confirmed.
- ☐ Response times: Discuss a realistic working response window for both sides; distinguish it from urgent issues.
- ☐ Meetings: Set a cadence only if needed, with a purpose for each meeting.
- ☐ Review: Confirm who approves each stage, how feedback is combined, and any agreed review rounds.
- ☐ Escalation: Name the person and channel to use if a blocker puts a milestone at risk.
The ready-to-start gate
Onboarding is complete only when the first meaningful delivery task can actually begin. Before marking it ready, answer these questions:
- What is the first task, and who owns it?
- Are its required information, files, permissions, and agreed commercial prerequisites available?
- Is its output clear, with a reviewer and a review date?
- For anything still missing, is there an owner and a date—and can this first task genuinely proceed without it?
If a missing input prevents that task, mark the project waiting and request the specific item. If only a later stage is affected, record that dependency and start the work that is ready. A completed welcome call alone does not pass this gate.
Fictional example: onboarding a service-page rewrite
Illustration only: Harbor is a fictional client commissioning one service-page rewrite.
- Confirm the job: The agreed scope is one page and one consolidated review round. Harbor’s coordinator supplies materials; its owner approves. Billing arrangements are confirmed before drafting.
- Request the first inputs: Ask for the current page copy, intended audience, agreed service details, and any wording that must remain. Create a shared project folder and test access.
- Record the blocker: The current service details are missing. Mark the project waiting, assign the request to the coordinator, and agree to check the next working day. Do not draft claims by guessing.
- Pass the gate: Once the details arrive, the first task is to draft the page outline. Record who will review it and when. Website publishing access is a later dependency, so it need not block the outline.
- Leave a clear handoff: Put the outline link and the requested approval in the agreed workspace. Record any delayed response against the next milestone.
When the same setup repeats, turn the stable parts into a minimum useful onboarding SOP. Keep project-specific inputs and exceptions visible instead of forcing every client through every possible question.
Updated 6 October 2026: replaced repeated explanation with a usable checklist, ready-to-start gate, and fictional onboarding sequence.
