Client Collaboration Software: Test the Client Lifecycle, Not the Demo

Client collaboration software is the software that lets people outside your core team, reviewers, approvers, a client-side editor, see, comment on and approve specific work without seeing the rest of it. Every tool can demonstrate that once, on a demo file, with two friendly test accounts. The agency question is whether it still holds for every client on the roster, whether cost tracks your headcount or your client count, and whether you can remove one client without leaving a live link behind.

What follows is the full client lifecycle, invite, isolate, review, remove, with the seat arithmetic that decides most purchases and a test you can run on one real client before you sign anything. If you are configuring a tool for a single production rather than evaluating the platform, client collaboration tools: how to choose and configure them is the better starting point. If you are auditing an existing stack capability by capability, the five-capability audit before you switch already covers that ground.

Access is two grants, not one

Client access rarely comes from a single switch. It comes from two independent grants, which is also why offboarding is where most teams leave something behind.

Membership decides the ceiling of what a person can reach. A workspace (sometimes called a project) is the shared home for one team, and boards, chat, Drive, Brain and economy are all workspace-scoped. Full members can be granted or denied capabilities individually; guests get a restricted tier. You configure this per person in Settings > Team.

File access is granted separately, folder by folder. A guest can upload to a folder shared with them when their Drive access is set to Editor. Viewer access allows viewing, downloading and adding comments, but not uploading, so it is not strictly read-only either. The guest tier does not grant file access on its own, and the built-in Guest preset leaves the Drive page disabled. Presets and saved settings can differ, so check what is actually saved rather than trusting the preset name. The step-by-step version of this is in how to give clients project access without exposing internal work.

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 they are assigned to. That is the mechanism that lets two client reviewers sit inside the same workspace and never encounter each other's work: client A's reviewer is a guest with no view-all permission and no access to client B's board. Boards can also be restricted to a named member list, which gives you a second, coarser layer above the card.

One limit worth testing honestly rather than discovering later: connected accounts (YouTube, X and similar) belong to the workspace, not to a client. If a client's channel is connected inside a shared workspace, the team shares that connection. If that is unacceptable for your roster, per-client workspaces are the alternative, at the cost of duplicated setup.

Seat math as the roster grows

Guest seats and paid seats behave differently, and the difference compounds as you add clients. Guests are free and do not count as paid seats. Owners and members count toward the billable seat calculation. Put your own roster through that:

• An agency with 1 owner, 8 team members and 30 client-side reviewers, where all 30 reviewers are guests, contains 9 potentially billable seats.
• The same 30 reviewers as full members: 39.
• Grow to 25 clients with 3 reviewers each, 75 guests, and the billable count is still 9 unless you hire.

That is the scaling argument in one line: with a guest tier in place, cost follows internal headcount rather than client count. Two cautions on the arithmetic. A roster is a planning estimate, not proof that an invoice is correct, because invoice adjustments, subscription state and historical seat changes also matter. Verify against the actual billing record before you budget from it. And do not remove a guest to reduce a paid-seat charge; guests were never the paid part of the bill.

Current plan details and the definition of a billable seat live on the pricing page. If you want to audit an existing roster against an invoice, free client seats vs paid user seats walks through that comparison.

Recurring review cycles across clients

The demo shows a comment landing on a frame. Running review across a roster requires three things to survive the round: which version the client actually watched, whether the notes are anchored to that version, and whether approval is recorded against it or just said out loud on a call.

kloudboard keeps file version history, so uploading a new version to the same file preserves the earlier ones and reviewers can switch between them. The Review action beside a media file or PDF on a board card opens the review view, which supports timestamped comments and @mentions on videos and documents. The part software cannot do for you is write the approval down.

Take a Tuesday where three clients each have one deliverable in review:

• Client A, episode 14, v3. Two timestamped comments at 00:12 and 01:47 on v3, one marked resolved. The approver writes "approved for publish, v3" on the card.
• Client B, brand spot, v2. Notes land on v2, and v1 stays reachable, so nobody re-opens a cut that was already retired.
• Client C, podcast clip, v1. Feedback arrives verbally on a call. Nothing is written against v1, so next week's v2 restarts the same conversation.

Client C is where review cycles multiply. The fix is a convention, not a feature: an approval is only an approval when it names a version and lives on the card. A verbal "looks good" attached to no version disappears the moment the next upload happens. More on running rounds that terminate in the video review and approval process, and the feature itself is described under review and approval.

Offboarding one client cleanly

Client removal is two revocations, not one: the guest's team membership under Settings > Team, and any Drive folders shared with them, including upload-enabled folders. Do one without the other and you leave a path in.

Workspace deletion is not a client offboarding tool. It is owner-only and permanent: it removes the workspace for every member, boards, chat, Drive files and financial history included, and it cannot be undone. Non-owners see "Leave workspace" instead, which is a different action with a different result. If a workspace holds more than one client, deletion is the wrong lever entirely.

Before you cut access, settle the money and archive the work. Financial records live with the workspace, so an open payout or payment request is easier to resolve while the record is still in front of you. See economy and payouts. Then move or download the final approved files somewhere your team still controls, because a removed guest cannot share them back to you. Finally, verify rather than assume: sign in as the removed account, or ask a colleague to, and confirm the card and folder links no longer open content.

Client offboarding checklist

Remove one client's access completely without leaving live links or losing the record of what was approved.

The lifecycle test: invite, isolate, review, remove

Run this once on a real client and a real video. It takes under an hour and it is deliberately unglamorous.

1. Invite the client's reviewer as a guest, not a member. Note what the invite flow asks you to decide and whether the restricted tier is the default.
2. Assign them exactly one card and create a second, unassigned card beside it on the same board.
3. Upload a video to the assigned card, open Review, leave one timestamped comment, then upload a second version and check the first version's comments are still reachable.
4. Sign in as the guest. Their assigned card and file should be visible; the unassigned card and any other client's board should not be.
5. Compare the seat count before and after the invite. It should not move. Confirm the billable-seat definition on the pricing page rather than trusting the demo account.
6. Remove the guest's membership and shared folders, then sign in again and confirm the links fail.
7. Check the connected accounts you rely on and decide whether workspace-wide connections are acceptable for this roster.

Two failure signals to watch for. If a guest can reach a board they were never given, isolation is documentation rather than enforcement, and it will not hold at 25 clients. If comments slide between versions with no record of which cut was approved, your recurring cycles will keep restarting no matter how clean the interface looks.

What the test will not tell you

Two structural decisions sit outside it. The first is one workspace versus many. A single workspace with a strict guest tier is simpler: one set of templates, one place for the team to work, one place to check connected accounts. Per-client workspaces buy stronger separation, at the cost of duplicated setup and split connections. Neither is wrong, but they fail differently as the roster grows.

The second is chat. Team chat lives inside the workspace with channels and DMs, but external chat bridges are not available, so you cannot sync a client's Slack or WhatsApp into it. Client conversations have to move into the workspace, or stay outside and be linked manually. Decide which before onboarding, because it changes client behaviour rather than your software.

To act on this today: take your most recent live client, create the two-card setup from the lifecycle test, and run their next review round through it. Check the seat count before and after the invite, then remove the test access and confirm it is genuinely gone. If all three hold, the platform question is mostly answered, and the remaining decisions are convention, not software.