Giving clients a portal they'll actually use

You send a client a link to your shiny new portal. Two days later they email you a photo of a bank statement taken on their phone, with the subject line “here you go.” They never opened the portal. They could not remember whether they had signed up, could not find the password, and had a document to send right now — so they did what they always do. Email won.

Most client portals fail this way. Not because the idea is wrong, but because they ask the client to do more work than the thing they replaced. A portal only earns its place if opening it is easier than opening the inbox.

Why portals go unused

A client at an audit or accounting firm is not a power user. They log in a handful of times a year, usually under time pressure, often on a phone. Every point of friction between them and the upload button is a reason to give up and revert to email.

The usual culprits are familiar:

• Another password to create and forget. For an occasional user this is the single biggest barrier. The reset link arrives, the reset fails at nine in the evening before a deadline, and the client falls back to attaching the file to an email.
• A dashboard that explains itself to the firm, not the client. Tabs, filters, project codes, internal jargon. The client opens it, cannot see what they are supposed to do, and closes it.
• No answer to the only question they have. The client wants to know one thing: what do you still need from me. If the portal cannot say that plainly, it has failed at its main job.

Fix those three and adoption stops being a fight.

No password to forget

Clivanta’s portal is passwordless by default. A Client User gets a magic link — a time-limited, single-use link that logs them in without a password to create, store, or reset. If a client prefers a direct login they can set a password later, but nothing forces them to. The design choice is deliberate enough that we wrote about it separately in passwordless by design: every password you ask an occasional user to create is a reason they will go back to email.

Access is still logged. The point is not to be casual about security; it is to remove the one obstacle that reliably sends clients back to the inbox.

A view built around “what’s needed from me”

Once inside, the client sees their Engagements and, within each, a plain layout of state: what needs their action, what is with your firm awaiting review, and what is done. No project management vocabulary. No status they have to interpret.

At the centre is a simple “what’s still missing” summary, and it is trustworthy because it reads from the same stored, audited per-item status your own team works from. Outstanding means a Request Item is genuinely requested or needs revision — not a guess derived from whether a file happens to exist. The client is never chasing a ghost, and neither are you. When the reminders go out, they name the specific items still outstanding rather than a vague “please send your documents”, so the client can act without opening a thread to work out what you mean.

Each item carries the instructions and, where useful, a sample format, so the ask explains itself. Half of what looks like a late document is really a client who did not understand what was wanted. Putting the instruction on the item removes that round-trip before it starts.

Upload the way clients actually send things

Clients do not all behave the same way, so the portal does not assume they will. A careful client answers item by item: open the Request Item, drag the file in, done. A busy client dumps everything at once — one upload of a dozen files against a single ask, or a pile to be sorted. Both are supported. Bulk upload takes the pile; per-item upload takes the tidy answer. Files hang off the specific ask, with full version history, so when a client sends a correction the previous attempt is retained rather than lost.

The whole flow is drag-and-drop and works on a phone, because the phone is where a lot of these uploads actually happen. A client photographing a document in a car park should be able to finish the job there, not be told to find a laptop.

And it works in English and Greek, with browser-language detection choosing the right one. A Cyprus firm’s staff often work in English while many clients are more comfortable in Greek, and the same Request Item has to be clear to both sides. The client sees their language; your team keeps one workflow and one record.

One client, several people

Real clients are rarely one person. There is the finance manager who handles most things, the director who signs, the bookkeeper who has the actual files. Clivanta models this with a Client Owner — the single primary contact and default escalation recipient — who can invite colleagues into the Client’s space.

That raises a practical question: who sees what. The team-visibility model lets a Client User see either all of the Client’s requests or just the ones assigned to them, so a bookkeeper is not wading through matters that are not theirs, and the Client Owner keeps the full picture. The firm sends one set of requests; the right people on the client side pick up their parts.

The test of a good portal

A good client portal is measured by a single, unglamorous outcome: the client uses it instead of email, without being nagged into it. That happens when logging in is frictionless, the asks are obvious, the “what’s still missing” answer is honest, and uploading works the way people already behave.

That is the whole design brief behind the Clivanta portal. It is not trying to impress the client. It is trying to be the path of least resistance, so the documents come in through the front door and land on the right Request Item, already in the record.

The best portal is the one a client never has to think about.