Solution guide

Client portals that replace the email thread.

When a client asks "where are we with this?", the honest answer is usually buried across emails, chats and attachments. A client portal gives you and your clients one shared place for requests, proposals, approvals and progress — so decisions are quick, and nobody has to search for what was agreed.

Request a project quote See the client portal concept

Signs a portal would help

Clients regularly ask for status updates you already gave them.
Approvals arrive as "looks good" in a chat message, and later someone remembers it differently.
The latest version of a document is whichever attachment was sent last.
New team members cannot tell what was promised to whom.
You manage several clients at once and the same questions repeat.

If only one or two of these apply, a shared folder and a clear routine may be enough. A portal earns its cost when the volume of back-and-forth is high and the decisions matter.

What a portal gives each side

Your clients get a clear list of what is open, what is waiting for them, and what has been decided. They can review a proposal and respond without writing an email.

Your team gets a single record per request, with its history, so anyone can pick it up. Status questions are answered by the portal rather than by a person.

The same data appears in two views — the client sees the part meant for them; the team sees everything. Designing that split carefully is most of the work.

Questions to settle before anyone designs a screen

Who gets an account, and what can each person do? A client may have several people: someone who approves, someone who only needs to view. Roles should match how decisions are really made.
What does "approved" mean? Who may approve, whether approval can be undone, and what record you need to keep. These definitions have commercial consequences, so they belong to you, not to the software.
What is visible to clients? Internal notes, costs and discussions often should not be. Decide the line before designing the screens.
How are people told something needs them? Email, in-app alerts or WhatsApp — and how often before it becomes noise.
How are files handled? Size limits, version history, who can delete, and how long files are kept.

Try the concept — and read its limits

Our client portal concept shows a request list, a proposal with an approve-or-request-changes step, and an activity history. It uses fictional data, and its history is not a production audit record: nothing is stored beyond the current page session.

Product concept · Fictional data

Read about the client portal concept

Open the interactive demo (English)

What a production portal needs that a concept does not

Proper sign-in, with access limited to each client's own information.
Secure storage and clear separation between clients' data.
A durable activity history, with agreed access and retention.
Notifications and, where useful, connections to your accounting or project tools.
Backups, monitoring and someone responsible for running it after launch.

Portals hold other people's information. In Hong Kong that means thinking about the Personal Data (Privacy) Ordinance from the start — what you collect, why, who can see it and how long you keep it — and taking professional advice where needed.

Where portal projects go wrong

Building the portal before the process is clear, so it hardens a muddle.
Adding every feature at once, when requests and approvals alone would solve most of the pain.
No owner on your side for responding promptly — a portal makes delays visible.
Forgetting that clients must want to use it: it has to be easier than email.

What drives the size of the work: number of roles, files and versions, integrations and reporting. The project cost estimator treats a portal as a web application and shows how those choices move the range.

Frequently asked questions

Do our clients have to log in?

For anything confidential, yes. Sign-in is what lets each client see only their own information. It can be made light — for example a secure link followed by a short code — and we would discuss the right level for your case.

Could we start with something simpler than a full portal?

Yes, and we would usually suggest it. A first release that handles requests and approvals well is more useful than a large system that does everything poorly. Files, reporting and integrations can follow.

Can it connect to our accounting or project software?

Often, yes. Integrations are reviewed during scoping: what needs to be shared, in which direction and what the other system allows.

How is client information kept separate and secure?

Separation between clients, controlled access and sensible storage are core parts of the design, not extras. The exact approach is agreed during scoping and depends on the sensitivity of what the portal holds.

Can the portal carry our branding and both languages?

Yes. Branding, English and Traditional Chinese can all be part of the design from the start.

Planning a client portal?

Tell us who needs access, what they need to review and how work moves through your business.

Request a project quote