What a client portal should achieve
A client portal provides bounded access to information and actions a client needs for collaboration: progress, documents and specific feedback. A useful portal does not show as much as possible; it enables the next meaningful step.
Make deliberate choices: which status will the client understand? Which file is the current basis for work? Who may give feedback? The portal is not automatically the internal workspace. Internal notes, calculations and unresolved options need their own boundary.
Three states that must not be confused
| State | Meaning in the workflow | What it does not imply |
|---|---|---|
| Visible | Selected content is made available to the client | The client has read or accepted it |
| Commented on | Feedback has been received | Everyone involved agrees |
| Decided | The responsible person has answered a specific question | Another version or extra work is also approved |
Example: a clear decision page
The team presents two design options. If both simply sit under “Files”, it is unclear whether they are for information or selection. Ask a specific question instead: “Which option should be the basis for the mobile design?” Include version names and the decision-maker.
The internal task also contains effort estimates and technical risk discussions. The client needs the relevant impact, such as an option requiring extra development. Internal detail notes do not automatically become part of the client view.
After the decision, record the selected version. Give later changes a new reference. This prevents a comment on an old version from being mistaken for approval of the current one.
Check before inviting a client
Project boundary
Test that invited access reaches only the intended project and its shared content. Include direct file and API URLs in the technical check.
Clear orientation
Show the project name, current state, open question and next action. Internal ticket codes alone rarely help clients.
Responsibilities
Distinguish reading, commenting and deciding. With multiple contacts, make clear who consolidates feedback authoritatively.
Revocation and closure
Define how access ends when staff change or a project closes, and what happens to files already downloaded.
A portal does not replace coordination
Not every discussion belongs in a comment thread. Complex decisions may need a conversation. Record the outcome against the specific project state afterwards; otherwise, a parallel, incomplete history grows alongside the portal.
Technical access control and organisational approval rules are different tasks. A hidden button does not prove secure authorisation; a technically permitted action does not prove contractual decision-making authority.
Frequently asked questions
Does each contact need their own account?
Individual accounts are a sensible starting point for attributing decisions to people. Check whether and how the selected product supports this. Shared accounts make feedback harder to attribute.
How does this differ from a client data room?
A data room focuses on documents and their exchange. A portal can also include progress and tasks. Scope depends on the system; evaluate both against the actions you actually need.
Experience the change in perspective.
Try the steps in the OOKI demo: tasks, client view, time entries and invoice draft with fictional data. No login required.
Try the demo (DE)