Project management software with a client portal: how to choose and configure it

If a client portal is the main reason you are picking project management software, judge the permission model before the feature list. The portal is only half the product. The other half is the internal board where the work is actually produced, and the two halves have to agree about who can see what.

The useful answer to "which one should I buy" starts with two testable questions: can an outside account be scoped down to specific cards, or only to whole boards? And does that outside account get its own restricted tier, or is it just a full member with a few toggles turned off?

Everything else — review comments, version history, file access — sits on top of that answer. Get the scoping wrong and you spend your setup time hiding internal work instead of shipping it.

Start with the permission model, not the feature list

Most tools can show a board to an outsider. The distinction that matters for creative production is whether scoping happens at board level or card level, and that difference decides your whole workspace structure.

Board-only scoping forces you into one board per client, with every internal card somewhere else. Card-level scoping lets you keep one production board and hand a client exactly the three cards they need to review this week.

In kloudboard, 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. An unassigned card is genuinely invisible to a scoped guest, not merely hidden in the interface. That is the switch we will use for the rest of this article.

Check two things before you commit to a tool:

• Does the external tier have its own permission profile, or does it inherit a member's? Full members can be granted or denied capabilities individually; guests get a restricted tier.
• Is the scoping documented per person and per board? You want both a per-member permission screen and a per-board access setting you can restrict to a named list.

Worked example: a four-person studio, two clients

Assume a studio with an owner, one producer, two freelance editors and two client-side reviewers. Both clients are on the same production board, one brand each.

That roster contains two potentially billable seats: the owner and the producer. The four guests are free and do not count as paid seats. Treat that as a roster read, not a billing verdict — the invoice itself has not been verified, and quantity alone does not prove a charge is correct. Check the actual record in Settings > Billing before concluding anything about what you are paying. There is a longer walkthrough in free client seats versus paid user seats.

Note that the client reviewer and the editors share a tier but not an outcome. Both are guests with view-all off. What separates them is which cards they are assigned to and which folders are shared with them, not which tier they sit in.

Configure client access in this order

Permissions are easiest to reason about when you build them outside-in: create the account first, then narrow it, then verify. Doing this in the reverse order usually leaves one board or folder open by accident.

1. Invite from Settings > Team (or the Invite button). The invitee gets an email link and lands in the workspace after signing up. Do not send the link and immediately start uploading client work into the space they can reach.
2. Set the tier to guest and leave view all cards off. This is the permission that decides whether the scoping below means anything.
3. Restrict the board from the board's own settings if the client should not even see that other boards exist. Boards can be limited to a member list.
4. Assign the cards the client reviews. Assignments are the mechanism, not a nicety: an unassigned card is invisible to a scoped guest, so a missing assignment looks like a broken portal to the client.
5. Enable Drive only if the client uploads. Files attached to a card are stored in the workspace Drive, so a client reference asset or a returned marked-up file lives there too. If you need uploads, pick the guest in Settings > Team, enable Drive, set Drive access to Editor, and share the intended folder. The built-in Guest preset leaves the Drive page disabled, so check the saved setting rather than assuming the preset carried over.
6. Verify with a test card. Create a card you have not assigned to the client, log in as them if you can, and confirm it does not appear. Repeat for the folder you did not share.

Two failure cases are common enough to plan for. First, sharing a folder changes which files the guest can reach but does not upgrade their Drive access from Viewer to Editor — Viewer still cannot upload, though it is not strictly read-only because comments are allowed. Second, without see all files, a guest's Drive visibility is limited to shared folders and to attachments on assigned cards. If your client says a file is missing, check folder sharing before you check anything else.

What the review side has to support

Scoping gets the client to the right screen. The review layer decides whether the round ends.

Look for timestamped comments on video and documents, and @mentions so a note can address a specific person rather than the whole thread. kloudboard's review view supports both on videos and documents. That matters more than annotation variety: a note tied to 00:42 is actionable, a note saying "the middle drags" is a meeting.

Version history is the second requirement. Uploading a new version of the same file preserves the previous ones, and reviewers can switch between versions. That gives you a defensible answer to "which cut did I approve?" — provided you decide your own convention for what counts as current.

Approval itself is a convention you maintain, not an automated guarantee. The reliable pattern is to record the decision twice: change the card status and post a comment that names the approved version and date. A written confirmation in the card history is what survives a scope dispute six weeks later. The fuller version of this loop is in setting up a creative approval workflow with file version history.

Match portal capability to client volume

The same feature set is adequate for two clients and painful for twelve. Use your actual review volume to decide how much structure you need before you migrate anything.

Estimating the monthly volume of feedback is a quicker way to pick a row than counting clients. Multiply deliverables by rounds by notes per round.

Monthly feedback load estimator

Estimate how many review notes and comments your portal has to absorb per month, so you can decide how much scoping and versioning structure you need.

Monthly feedback load is deliverables per month multiplied by review rounds per deliverable, multiplied by notes per round.

Assumptions: Illustrative inputs from your own workflow, not measured benchmarks. Counts written notes and timestamped comments only; excludes replies, internal comments and out-of-band messages.

Worked example: Deliverables per month: 20 deliverables; Review rounds per deliverable: 2 rounds; Notes per round: 8 notes. Estimated monthly feedback items: 320 items.

If that number is in the hundreds, email threads and chat messages will lose items and you need the scoping and versioning described above. If it is under thirty, a lighter setup genuinely works and you should not migrate your whole pipeline for it. This is arithmetic on your own numbers — it is not a benchmark.

Seat and cost questions to verify, not assume

Client portals are usually marketed on guest seats, so check the billing mechanics before you build around them. Guests are free and do not count as paid seats; owners and members do count toward the billable seat calculation.

Two habits to avoid. Do not delete a guest account in the hope of lowering paid-seat charges — guests are not the seat being billed. And do not accept a roster count as proof that an invoice is right, or that it is wrong; invoice adjustments, subscription state and historical seat changes all feed into the real number.

AI features are a separate balance from subscription seats, and generation pauses when the workspace allowance runs out, so keep the two costs mentally separate. Current plan details live on the pricing page rather than in any figure quoted in an article.

What to do today

Pick one live client and rebuild their access in the order above: invite as a guest, confirm view-all is off, restrict the board, assign exactly the cards in play, and enable Drive at Editor only if they upload. Then post a comment on the main deliverable card noting the approved version and who approved it.

That single rebuild tells you whether your current tool supports card-level scoping at all. If it does not, no amount of review features will save you from duplicating boards — and that limitation is worth discovering before you move a second client across. For the permission mechanics in more detail, see giving clients project access without exposing internal work and the client portal overview.