Client portals: what they do and whether your business needs one
Client portal is a vague term that covers everything from a login page to a full self service system. Here is what one actually does, and an honest look at when you do not need one.
Client portal is one of those terms that means something different to everyone who says it. For some it is a login page with a document list. For others it is a full self service system where clients place orders, track progress and pay invoices without contacting anyone.
That vagueness matters, because it makes the decision harder than it needs to be. This post defines the term properly, then looks honestly at when building one pays for itself and when it does not.
What a client portal actually is
Strip away the marketing and it is a private area where each of your clients can see their own information and act on it, without needing to ask you.
The defining characteristic is not the technology. It is that the client serves themselves. Everything a portal does could be done by someone in your business answering an email. The portal exists so nobody has to.
The admin it removes
The clearest way to judge whether you need one is to look at the messages your team answers repeatedly. Most businesses have three or four questions that arrive constantly.
- Where are we up to? Status questions about an order, a job, a case or an application.
- Can you resend that document? Invoices, reports, certificates, contracts, anything you have already sent once.
- What do I owe, and has my payment landed? Account and billing queries.
- Can we change the date? Rescheduling, which usually takes several messages to settle.
Each of these is quick to answer individually, which is exactly why they get overlooked. The cost is in the volume and the interruption. Fifteen of them a day at five minutes each is over an hour, every day, spent on questions the client could have answered themselves.
When a portal is worth building
Three conditions tend to appear together in businesses where a portal pays for itself.
Clients interact with you repeatedly over time
Portals suit ongoing relationships. A client who deals with you monthly for years will learn and use one. A client who buys once and disappears will never log in, and asking them to create an account adds friction to the only transaction you get.
The same questions arrive constantly
If your inbox is mostly status requests and document resends, that is exactly the work a portal absorbs. If your inbox is mostly genuine discussion that needs a human, a portal will not help much.
The information already exists somewhere
A portal displays data from a system you already run. If the status a client wants lives only in someone's head or a WhatsApp thread, there is nothing to display, and the real problem is upstream. Fixing that comes first, as covered in five signs you have outgrown spreadsheets.
When you do not need one
This section matters as much as the last one, because portals get built for businesses that would have been better served by something simpler.
- You have a small number of clients. With fifteen clients you know by name, a good email habit and a shared folder genuinely does the job. A portal adds a login for everyone to forget.
- Interaction is infrequent. If clients hear from you twice a year, they will not remember the portal exists, and you will end up emailing them the information anyway.
- Your clients will not use it. Be realistic about this rather than optimistic. A portal nobody logs into is worse than no portal, because you now maintain two channels.
- The underlying data is not reliable yet. A portal showing wrong statuses damages trust faster than no portal at all.
A portal makes existing information visible. It cannot create information that your business does not already track.
What a good first version contains
If it does make sense, resist building everything. The first version should cover the two or three questions that actually arrive most often, and nothing else.
- Current status of whatever matters most to them, in plain language rather than internal codes.
- Their documents, downloadable without asking, including historical ones.
- A history of what has happened, so they can answer their own questions about last month.
- One clear action, whichever is most common for your business: approve something, request a change, or make a payment.
That is genuinely enough to remove most of the repeat admin. Features beyond this should wait until real usage shows what people actually want, which is rarely what anyone predicted.
The security side
A portal means client data is now accessible over the internet, which raises the bar on getting access control right. The essentials are individual logins rather than shared credentials, strict separation so no client can ever see another client's data, and a log of who accessed what.
That last one is not just good practice. If you handle personal data, being able to demonstrate who accessed what is part of your accountability obligation under UK GDPR, and it is the first thing you will need if something goes wrong. Our GDPR guide covers the wider picture.
One practical note: think carefully about what a portal exposes by default. Internal notes, margins and staff comments have a habit of ending up on screens they were never meant for.
Frequently asked questions
A focused first version covering status, documents and one action typically falls into the same range as any single workflow project, roughly six to fifteen thousand pounds depending on how much of the underlying data already exists in a usable system. Building on top of a system you already have is considerably cheaper than building both.
It depends almost entirely on whether it saves them time. Clients use portals that answer their questions faster than emailing you would. They ignore portals that require a login to see something they could have received in an email. Reducing friction on first access matters more than any feature.
Usually yes, provided the data a client would want to see already lives somewhere structured. A portal is largely a presentation layer over existing information, so the work depends on how accessible that information currently is rather than on the portal itself.