Published in Articles
Client onboarding workflow: workspace setup for creative teams

Client onboarding usually gets written up as a contracts problem: scope, deposit, signature. That is the business half. The operational half is the 90 minutes of setup that decides whether the next four weeks run on a board or in your inbox.
An operational client onboarding workflow is the fixed sequence of setup actions you run when a client signs: create the workspace, choose the right role for the client contact, configure permissions, build the board, route the first brief, and close the first review round with a recorded decision. Run it in the same order every time and the third client takes half as long as the first.
If the contracts and scope side is not done yet, that is a separate job — start with how to onboard new freelance clients. This article assumes the paperwork is signed and you are now setting up the work itself.
What operational onboarding covers (and what it doesn't)
In scope:
- Creating a workspace for the client's work and inviting the right people.
- Deciding whether the client contact is a guest or a full member, and what that decision changes.
- Board structure and the first cards.
- Routing the first brief so an editor can start without a kickoff call.
- Running one review round so the approval gate is defined before the first disagreement.
Out of scope: pricing, contracts, invoicing, payment terms, and anything about how the client pays you. Those belong to the business checklist, and mixing them into workspace setup is how setup tasks quietly turn into a week of admin.
Worked example: a three-person studio, one new client, 90 minutes
Three people run the studio: a producer who owns the workspace, and two editors. The new client is an ecommerce brand buying four short-form videos a month with one revision round on each.
The setup budget is 90 minutes, planned like this:
| Setup step | Planned time | Done when |
|---|---|---|
| Create workspace, invite client contact | 15 min | Client appears in Settings > Team |
| Build board structure and first cards | 25 min | Four cards exist, one per video |
| Configure permissions, verify visibility | 15 min | Client reports seeing one test card, not two |
| Write the first brief into card 1 | 20 min | An editor could start without asking a question |
| Set the review round and approval gate | 15 min | The card states who approves and what "approved" means |
| Total | 90 min |
These are planning estimates for your own setup time, not measured benchmarks. A single freelancer with one client can compress the same sequence into about 30 minutes.
The checklist below is the order to run it in.
Client workspace onboarding checklist
Takes a signed client from paperwork to a working project space where the first deliverable can move without email.
Step 1: create the workspace and pick the client's role
A workspace (also called a project) is the shared home for one team — boards, chat, Drive, Brain and the economy area are all workspace-scoped and shared by its members. One workspace per client is the simple default. The tradeoff is more places to check each morning, so some studios group three small retainer clients into one workspace and separate them with board restrictions instead. Pick one convention and keep it, because inconsistency is worse than either choice.
Invite people from Settings > Team or the Invite button. Invitees get an email link and land in the workspace after signing up.
The role decision is the one people get wrong by default:
| Client contact | Role | What they see | Seat effect |
|---|---|---|---|
| Approves work, never uploads | Guest without "view all cards" | Only the cards assigned to them | Guests are free and do not count as paid seats |
| Uploads their own raw assets | Guest with the Drive page enabled at Editor | Shared folders plus assigned cards | Same as above |
| Runs their own production inside your board | Member with individual permission toggles | Whatever you grant | Owners and members count toward the billable seat calculation |
For most agency clients the first or second row is correct. Check the current plan and seat details on the pricing page rather than assuming the number on your last invoice — a roster alone does not prove a charge is right, because subscription state and seat changes over the month also matter.
Step 2: configure permissions and verify exactly what the client sees
Configure per-member permissions in Settings > Team: pick the person, adjust their permission toggles. Per-board access lives in the board's own settings, where a board can be restricted to a member list.
Card visibility is enforced server-side. Owners and members with the "view all cards" permission see every card; a guest without it sees only the cards assigned to them. That single toggle is the difference between a client seeing four finished videos and a client reading your internal notes about which editor is behind.
Verify rather than assume. Create two cards: one assigned to the client contact, one assigned to nobody. Ask them to confirm they can see exactly one. An unassigned card is invisible to a scoped guest, so this test catches both over-sharing and under-sharing in a single message.
If the permission model is the part you keep getting wrong, giving clients project access without exposing internal work goes deeper on the ordering.
Step 3: build the board around deliverables, not clients
One card per video, per post, per episode. The card carries everything: brief, source files, current cut, comment thread, approval, and versions. Client-level boards fragment that and force you to hunt across three places for one decision.
Seven columns is enough for most client work:
- Brief
- Script
- Edit
- Internal check
- Client review
- Approved
- Scheduled
A column should answer "who does what next". Avoid states that describe feelings — "polishing" and "final final" both hide the fact that nobody owns the next action. Project boards hold this structure once and you copy the pattern to the next client.
Two mechanics worth setting up on day one:
- Files attached to a card are stored in the workspace Drive, so an editor's upload can be reorganised later without breaking the card link.
- Uploading a new version to the same file keeps the old ones, and reviewers can switch between versions. That is what makes "which cut did you watch?" an answerable question instead of a debate.
Dragging and dropping a file onto a card uploads it into workspace storage, which is the path to prefer over transfer links for anything under review.
Step 4: route the first brief and close one review round
The first card is a test of the setup, so put the safest deliverable there — the simplest format, the least ambiguous creative. Every first card needs five things written into it: the brief text, the source assets, one named reviewer on the client side, a deadline, and the number of revision rounds included.
To run the review, open the board card and use the Review action beside the attached media file or PDF. The review view supports timestamped comments and @mentions on videos and documents, which is what turns "the intro drags" into a note attached to a specific second. There is more on the mechanics in how to use Review.
Define the gate in the card, not in a call: "Approved" means one named person has said so, on this version, and the card moves to Approved. Anything else is a comment, not a decision.
Two limits are worth stating to the client up front. External chat bridges — Slack, WhatsApp, Discord, Telegram syncing — are not available in this app, and in-app audio and video calls are unavailable. If your client lives in email, keep email for scheduling and route every decision back onto the card. Assigning a task to someone else creates an in-app notification unless that person has disabled the added-to-card preference; self-assignment notifies nobody. Do not promise the client an email when you assign a card.
What breaks in week one, and the 48-hour handoff
The same five failures account for most first-week onboarding problems:
- The client sees too much. They were granted "view all cards", or invited as a member out of habit.
- The client sees nothing. The board is restricted to a member list and their card was never assigned to them.
- The client cannot upload. The built-in Guest preset leaves the Drive page disabled, and workspace presets can differ — check the saved settings, not the label. If they must upload, enable Drive and set Drive access to Editor, then share the specific folder. Viewer access permits viewing, downloading and adding comments, but not uploading. See sharing files with freelance editors without full Drive access for the folder-sharing steps.
- Feedback splits across channels. With no chat bridge available, decide now that the card thread wins and say so in writing.
- Versions get confused. Someone sends a transfer link instead of uploading a new version to the same file, and the review history detaches from the card.
Then run the handoff as two days of work:
Day 1. Paste the brief into card 1, attach the source assets, assign the client contact the card, and send one message naming the card they should watch. If you want an internal second pair of eyes, assign an editor too — but leave the client as the single named approver.
Day 2. Upload the first cut as a new version on the same card, open Review, and leave the first timestamped comment yourself so the format is obvious before the client tries it.
By day 8 you have a real signal. If the client has commented in the workspace at least once without being chased, the setup worked and you can reuse it. If every note still arrived by email, the problem is not the tool — it is that nobody stated the approval gate on the first card, and that is a ten-minute edit, not a new platform.
Related articles
The workspace for creative teams
Manage projects, pay your team, and ship content faster.
Start for free
