What a Client Portal Should Show, and What It Should Not

A client portal is a promise about transparency, and the difficulty is that transparency is not a single setting. A client wants to know whether the work is on track, what is waiting on them, and what has been produced. They do not want the firm's internal risk scoring, its margin position, or a partially drafted deliverable that has not been reviewed.

The design problem is therefore not technical. It is deciding, for each kind of information, whether the client seeing it makes the engagement better or worse, and then making that decision visible in the product rather than leaving it to whoever is publishing.

What genuinely helps a client

Four things repay their cost almost every time, because each one removes a message that would otherwise be sent by email.

• What is waiting on them, with a due date and a name. Information requests are the largest single cause of delay on most engagements, and a client who can see their own list will usually work it down.
• The plan with its current dates, and which milestones have moved. Not the internal work breakdown, but the level a sponsor would recognise.
• Deliverables that have been formally issued, with their version and status. A client should never wonder whether the document they are reading is the current one.
• Decisions the firm needs from them, with the date by which each is needed and what happens if it slips.

What creates work rather than trust

Some information looks like transparency and behaves like a liability. Internal risk ratings are the clearest example. A risk register kept honestly contains items phrased for internal action, including risks about the client's own organisation, and exposing it wholesale converts a management tool into a diplomatic incident.

Drafts are the second. A deliverable that has not passed review is not the firm's opinion, and a client who reads one will reasonably treat it as such. The same applies to time detail: a client who can see individual time entries will ask about individual time entries, which is a conversation about narration rather than about value.

Sharing as an act, not a setting

The most reliable design principle is that client visibility should be conferred by a deliberate act, never inherited by default and never changed as a side effect of editing something else. When a risk becomes visible to a client, that should be because someone chose to share it, and the record should say who and when.

The corollary matters as much: withdrawing should require a reason, because withdrawal is the more consequential direction. A client who saw an item yesterday and cannot see it today will ask why, and the firm should already know the answer.

Access, and the part firms forget

A portal is only useful if the right people can reach it and the wrong ones cannot. That means invitations tied to named individuals rather than a shared link, an access level chosen deliberately, an expiry, and a register showing who currently has access. The register is the part most often missing, and it is the one that matters at the end of an engagement, when the question is who still has access to material they should no longer see.

Two access levels are usually enough: a fuller view for the sponsor and the programme contacts, and a narrower one for subject matter contacts who need only their own requests and the documents shared with them. More levels than that tend to be configured once and never understood again.

Measuring whether it works

The honest measure of a client portal is not logins. It is whether the messages it was meant to replace have stopped. If the sponsor still emails for a status update, the status page is not answering the question they actually have. If information requests still arrive by spreadsheet, the request list is not easier than the spreadsheet.

Review it once a quarter against that test, and be willing to remove pages nobody opens. A portal with four pages people rely on is worth more than one with twenty that dilute attention.