A Repeatable Client Onboarding Process for Small Studios

Why a small studio needs a process, not a checklist in someone's head

In a studio of two to ten people, onboarding often lives in the head of whoever sold the project. That works until two projects start in the same week, or the person who usually runs kickoffs is on leave. Then a client waits a week for a login request, or nobody asks who signs off on design, and the project starts with a gap that shows up later as a delay.

A repeatable process fixes this by making onboarding the same every time, no matter who runs it. It does not need to be long. It needs to answer four questions for every new client:

1. Who is involved, and who decides?
2. What do we need to agree at the start?
3. What do we need from the client, and how do we get it safely?
4. How will we keep each other informed?

The rest of this article turns those questions into four parts you can reuse.

Part 1: Confirm the people and their roles

Most projects that stall do so because a decision has no clear owner. Before the kickoff, write down who is involved on both sides and what each person is responsible for.

Atlassian's roles and responsibilities play describes a team session for exactly this: list the responsibilities, assign each one, resolve overlaps and pick up any task nobody owns. For a client project you can do a lighter version in a shared document.

A one-page roles table:

Responsibility	Client side	Studio side
Final approval of work	Name	Name (presents the work)
Day-to-day questions and feedback	Name	Name
Supplying content and brand material	Name	Name (requests and tracks it)
Technical access (hosting, domains, accounts)	Name	Name
Contract, scope changes and invoices	Name	Name

Two things to watch for:

• More than one final approver. If two people on the client side can each approve work, you will eventually get two different answers. Ask the client to choose a single person, and agree how everyone else feeds their views to them.
• Responsibilities nobody has claimed. Content supply is the common one. If nobody on the client side owns it, plan for delays now.

Part 2: Run the kickoff conversation

The kickoff is the first working meeting of the project. Its purpose is to leave both sides with the same picture of the work, not to repeat the proposal.

A 45 to 60 minute agenda that covers the essentials:

1. Goals in the client's words (10 minutes). Ask what success looks like at the end of the project and how they will judge it. Write the answers down.
2. Scope walk-through (10 minutes). Go through what is included and, just as important, what is not. Confirm the number of review rounds if your agreement includes a limit.
3. Roles (5 minutes). Confirm the table from Part 1, especially the final approver.
4. Timeline and dependencies (10 minutes). Show the main dates and point out the ones that depend on the client, such as content delivery or review windows.
5. Materials and access (10 minutes). Walk through the list of things you need, which you will send as requests straight after the call.
6. Communication rhythm (5 minutes). Agree the points in Part 4.
7. Questions and next steps (5 minutes).

Send a short summary the same day: the goals as the client stated them, the confirmed approver, the first dates and the list of what you need. If you post it as the first update in the client's portal, it stays easy to find for the whole project.

Part 3: Collect access and materials without chasing

Collecting material is where onboarding usually slows down. Clients do not ignore requests on purpose; they get a long email with ten items in it, answer three and lose track of the rest.

A better approach is one item per request:

• Brand material: logo files, color and typography guidelines, existing templates.
• Content: page copy, product details, images the client owns or has licensed.
• Access: hosting, domain registrar, analytics, content management system, social accounts, as relevant to the work.
• Context: past research, competitor examples the client likes or dislikes, internal deadlines you should know about.

Give each item a short explanation of why you need it and a due date. In Ayebridge, requests appear as a checklist in the client's portal. The client can reply, attach files and mark an item done, and an overdue reminder goes out automatically when a request with a due date slips. On Agency plans and above, a request can include a short form, which is useful when you ask every client for the same details.

Handle credentials with care

Access details deserve their own rule. Passwords pasted into email stay in inboxes indefinitely and are hard to rotate later. Better options, in order of preference:

1. The client invites you as a user on the service, with your own login. When the work ends, the client deletes your user and nobody's password has to change.
2. The client shares the credential through a password manager. The UK National Cyber Security Centre's guidance on managing passwords recommends password managers and turning on two-step verification.
3. As a last resort, a private channel agreed with the client, with the password changed once the work is done.

Write down which access you received and from whom. You will need that list at handoff.

Part 4: Agree how you will communicate

Many client frustrations come from mismatched expectations about communication rather than the work itself. One side expects a reply within the hour; the other checks email twice a day. Agreeing this at the start avoids the friction.

Atlassian's working agreements play helps teams set shared norms for channels, meetings, decisions and escalation. The same idea works between a studio and a client. Cover these points:

• Where things go. Work for review, updates and requests go in the portal. Urgent problems go by phone or a named channel.
• Response times. For example, replies to questions within one business day, and review feedback within an agreed number of business days.
• Update rhythm. A written update on a fixed day, plus a short call at an interval that suits the project.
• Review windows. How long the client has to review a round of work, and what happens to the timeline if feedback arrives late.
• Escalation. Who to contact on each side if something is blocked or going wrong.

A short template to send after the kickoff:

How we will work together Updates: every Thursday in your project portal. Review windows: three business days for each round. Questions: we reply within one business day. Urgent issues: call [name] on [number]. Decisions and approvals: recorded in the portal so we both have the same record.

Adjust the numbers to your studio. The point is to write them down once, so nobody has to guess.

The first two weeks

Onboarding ends when the project is running on its own rhythm. Use the first two weeks to show that the process works:

• Post the first regular update on the agreed day, even if there is little to report. A dependable updates timeline is how clients learn where to look.
• Share something small for review early. A moodboard, a sitemap or a content outline gives the approver a low-stakes first decision and tests the review process before the larger rounds.
• Follow up on overdue requests individually. If an item is still missing after its due date, ask the named owner directly and explain what it is blocking.
• Check the roles table against reality. If someone new is giving feedback, find out where they fit before their comments start overriding the approver's.

Make the process reusable

The value of a process comes from reusing it. A few ways to make that easy:

• Keep a master document with your standard list of requests, a kickoff summary outline and the communication template, and work through it when you set up each new client. If you have not set up the portal side yet, the client portal setup guide covers structure and the first invite.
• Keep the roles table and kickoff agenda in one document that anyone at the studio can run from.
• Review after each project. Ask what was late, what was missing and which questions the client asked that onboarding should have answered. Adjust the template, not just your memory.

Onboarding at a glance

Step	Owner	When	Output
Roles confirmed	Project lead	Before kickoff	Roles table with one final approver
Kickoff held	Project lead	Week 1	Summary posted as the first update
Materials requested	Project lead	Same day as kickoff	One request per item, with due dates
Access received	Client owner, tracked by studio	Week 1 to 2	Access list for handoff
Communication agreed	Both sides	At kickoff	Written working agreement
First update and first review	Studio	Week 1 to 2	Rhythm established

Run the same steps for every client and onboarding stops depending on who happens to be available. That consistency is what clients notice, even if they never see the template behind it.