What a Client Portal Actually Needs to Do

A business decides its clients need a portal. Six months later it exists, it looks good, and almost nobody logs in.

The clients still ring to ask where things are, and the portal becomes another thing to maintain that nobody uses.

Why they go unused

Because they were built around what the business wanted to show rather than what the client wanted to know.

A typical portal offers documents, invoices, a message centre and a dashboard. All reasonable, none of it urgent enough to justify remembering a password. The client’s actual question is narrower: where is my thing, what do you need from me, and when will it be finished.

If the answer to those three is not on the first screen without logging in, ringing is faster and the client will ring.

Replace a phone call, not a filing cabinet

The right test for any feature is whether it removes a call somebody was going to make.

Status counts, because that is the most common call in almost every service business. Outstanding items count, because chasing is the second most common. Approving something counts, because it unblocks work.

Document archives do not, because nobody rings to browse. Neither do dashboards nobody asked for. Build the three that remove calls and stop there, because every additional feature dilutes the ones that matter.

Access should not be a barrier

Passwords are where portals die. A client who has to reset a password to check a status will ring instead, every time.

A link that opens the right view, sent when there is something to see, outperforms a login almost universally for smaller clients. Keep the account for people who use it weekly, and keep the link for everyone else.

Where AI makes it worth using

A static portal answers only the questions somebody anticipated when building it. That is why they feel thin.

With AI on it, the client asks in their own words and gets an answer drawn from your live systems. When will this be ready, what is still outstanding on my file, what did we agree about the extra work. Those are the calls your team is taking now, and the answers already exist in the systems the client cannot see.

It also works the other direction. The portal asks for what is missing, checks documents when they arrive, and tells the client what is still needed, so chasing stops being a person’s job.

The result is a portal that removes calls rather than adding a place to look.

What to measure

• Status calls per week, before and after. The only number that matters.

• Share of clients using it more than once. First use proves curiosity, second proves value.

• Time to collect outstanding items, compared with chasing by email.

• Questions asked that it could not answer. The build list for the next version.

Notifications are the product, not the pages

The mistake in most portal projects is thinking of it as a place. It is better understood as a channel that occasionally has a place attached.

Clients do not visit. They respond. So the value sits in what gets sent, and the portal is simply where the link lands.

Something has moved to the next stage. Something is waiting on you. Something needs approving. Those three messages, sent when they are true rather than on a schedule, do most of the work of reducing calls. A client who is told will not ring to ask.

Which also means restraint matters. A portal that sends a notification for every internal event trains people to ignore it, and once ignored it is finished. Send what changes the client’s picture, nothing else.

What to show and what to keep back

Transparency has a limit that nobody writes down and everybody discovers.

Showing status, outstanding items and documents is straightforward. Showing raw internal task lists is not, because clients read normal working states as problems. A task marked blocked for four hours means nothing internally and reads as a crisis to somebody who does not know your process.

Translate rather than expose. The client sees stages in language they understand, not your workflow. That is more work to build and it is the difference between a portal that reassures and one that generates anxious emails.

It has to work on a phone

Almost every check happens on a phone, usually in a gap between other things, frequently while the client is somewhere else entirely.

That is not a design detail, it decides what can be on the first screen. One status, one clear outstanding item, one action. Anything requiring a laptop will be postponed, and postponed means a phone call to you instead.

Build the smallest version and let it grow

Portals fail more often through scope than through anything technical.

Specify six months of features, launch with forty screens, and none of them quite match how clients actually behave, because the specification was written by people imagining what clients want rather than watching what they do.

Ship status, outstanding items and one action. Watch which questions still arrive by phone for a month. Those questions are your build list, and they will not be the ones you would have guessed.

Who it is really for

One question decides most of the design. Is this for your clients, or for your team?

A portal built for clients removes calls. A portal built so your team can point at something removes an argument. Both are legitimate and they produce different products, and confusion between them is why so many end up serving neither.

If the honest answer is that it exists so nobody can say they were not told, build a status page and an audit log. If it exists to reduce the volume of questions, build the three things above and nothing else. Deciding which before you start saves the six months.

AI Optimize builds portals that answer in the client’s own words from your live systems, and collect what is outstanding without anyone chasing. That work sits under Custom Application.