A client portal exists to make the "where do things stand?" email unnecessary. The three levels, what each costs to run, and when not to build one.

There's one type of email every service business receives, every week: "hi, just following up, where do things stand?" Nobody bills for it, and it still costs ten to fifteen minutes each time.
A client portal is the structural answer to that email. It's a protected space online, reached by a login or a private link, where the client goes and finds the information they were asking you for. Done well, it hangs off the site you already have (our services start there) instead of adding one more tool to the pile.
Done badly, it's a filing cabinet with a password: nobody logs in, and the follow-ups keep arriving. The whole thing rests on one decision, the one this article is about: which question, exactly, is this portal meant to make unnecessary.
A client portal is a protected online space where your clients check the status of their file, their documents and their invoices without having to email you. There are three levels, and they don't cost the same to keep alive: a shared folder (Drive, Dropbox), which isn't a portal because it shows no status; a status page reachable by private link, which is enough for many small businesses; and a real authenticated space with accounts, permissions and history. The trigger isn't company size, it's how often you get asked "where do things stand?". Under roughly twenty active files, a disciplined follow-up cadence does the same job for less. And the real cost of a portal is never the build, it's keeping the information fresh. On compliance, Quebec's Law 25 requires reasonable security measures (s. 10), and the Commission d'accès à l'information recommends granting access only to staff whose duties make it necessary.
"Where do things stand?" keeps coming back because the information only exists on one side. You know the file has been waiting on a signature since Tuesday. Your client has no way to know that except by asking you. And the cost of asking is split very unevenly: thirty seconds for them, ten to fifteen minutes for you, once you've reread the file, checked with whoever is handling it, and written a polite reply.
As long as the asymmetry exists, the question gets asked. There are only two ways to close it. Push the information out: a weekly update, a status line at the end of every exchange. Or make it self-serve: the client pulls it when they need it. The difference is one of scale. Pushing costs time in proportion to the number of files. Self-serve costs a build, then almost nothing per additional file.
Do the arithmetic with your own numbers before deciding anything: active files, times follow-up questions per month, times your real answer time. That total is what justifies the spend, or what makes it absurd. No other reason counts, least of all the fact that a competitor has one.
A shared folder is not a portal. A Drive or Dropbox link answers "where is the file?", never "where do things stand?". It has no status and no next step. Useful, but it replaces nothing. Plenty of businesses think they have a portal because they have a shared folder, then wonder why the follow-up emails never dropped.
The first real level is the status page on a private link. One unguessable address per file, no account to create, no password to reset. It shows the current step, the next step, the date of the last update, and the file's documents. The build is modest, support is near zero, and adoption is excellent because there's nothing to remember. Its limit is obvious: whoever holds the link holds the access. So nothing sensitive goes there.
The second level is the authenticated space: named accounts, several contacts per client, invoices, forms, history, permissions. That's what most owners picture when they say "portal", and it's the one whose running cost gets underestimated every time. That cost isn't development. It's the account lifecycle (arrivals, departures, forgotten passwords), and above all the discipline of updating. A portal whose status is three weeks old produces exactly the email it was supposed to remove, plus one sentence: "the portal still says step 2".
My honest read, having seen both: most small businesses asking for level 2 would have been well served by level 1, and would have known within six months whether level 2 was worth it.
The contents of a portal should be derived from your sent folder, not from a feature list. Open the last three months of outgoing email and sort the questions you answer most often. That's your spec.
In practice four things cover almost everything. The status of the file, written in human language and dated: "step 3 of 5, waiting on your approval since August 12". The date does half the work, because it turns a vague claim into something checkable. The documents clients lose over and over: contract, quote, report, certificate, photos. The invoices, with payment status, usually the second most frequent question and the most awkward one to ask. And the forms you spend your life chasing: onboarding details, approvals, decisions.
One entry point, too. A portal that sends people off to three other tools has only moved the friction somewhere else.
One mechanism gets forgotten: notification. A portal with no alerts is a place nobody thinks to visit. The behaviour that works is the opposite of the intuition: email doesn't disappear, it changes direction. Instead of a client writing to ask, you send three lines when the status changes, with a link to the detail. The portal becomes the source, email becomes the alert. It also makes staleness visible: if nobody has received an alert in three weeks, everyone understands the file is asleep, including you.
A portal turns your site into a place that holds personal information about your clients. Law 25 is explicit: a person carrying on an enterprise must take the security measures necessary to ensure the protection of the personal information collected, used, communicated, kept or destroyed, and that are reasonable given the sensitivity of the information, the purposes for which it is to be used, the quantity and distribution of the information and the medium on which it is stored (s. 10 of the Act respecting the protection of personal information in the private sector). "Reasonable" is proportional: a portal showing progress on a renovation and one holding medical files don't call for the same protections.
Three habits cover the essentials for a small business. Isolation first: each client sees only their own file, and you can test that in thirty seconds by changing the identifier in the URL and confirming you get an error rather than the neighbour's file. It's the most common flaw in portals built in a hurry. Access management next: in its January 2026 guide on preventing confidentiality incidents for businesses, the Commission d'accès à l'information recommends granting access rights to personal information only to staff whose duties make that access necessary, and logging those accesses so irregular situations can be detected. That applies to your team and to the client-side contacts who change jobs. Minimization last: the law allows collecting only the information necessary for the purposes determined before collecting it (s. 5), and requires the information to be destroyed, or anonymized for serious and legitimate purposes, once those purposes are achieved (s. 23). The safest document is still the one you never uploaded.
We covered the rest of the foundations in website security for a small business: backups, updates, authentication. A portal inherits all of those questions, in a more serious form.
Under roughly twenty active files, a portal is almost always premature. An honest follow-up cadence costs less and works better: a Friday recap email, or a systematic status line at the end of every exchange. The portal becomes interesting when volume makes that discipline impossible to sustain.
Second case: one-off clients. If your typical relationship is a single transaction, nobody will build the habit of logging in, and you'll be paying to host an empty space. A portal assumes a relationship that lasts, which is why it pairs naturally with a subscription model rather than with a project delivered once.
Third case, and the important one: if nobody in the company clearly owns keeping the information current, don't build it. A stale portal is worse than no portal, because it costs you trust in the tool and in you at the same time.
Once the status of a file lives in one place and is structured, something other than a human can read it. An AI agent connected to that same source can answer "where do things stand?" in the channel the client already uses, in plain language, without them logging in at all. That's the portal's sequel, not its replacement: an agent with no source of truth invents, an agent connected to current data quotes. We worked through the reasoning in our article on AI agents in customer service, and the general mechanics on our agents page.
The same access rules apply to the agent as to people: it should see only the file of the person asking, and its lookups should be traceable. An agent is one more user in your permission system, and it gets managed like one.
A client portal isn't justified by the word "portal". It's justified by a question you get too often and by an arithmetic you can do today. Then comes the condition that sinks most of these projects: somebody has to keep the information current. Start small, one status page per file, and let usage tell you whether the rest is necessary.
At Peich, we build client portals as add-ons to the subscription websites we host. If you want to work out which of the three levels fits your situation, let's talk.
→ Let's talk about your client portal
This article explains legal obligations to help an SMB ask the right questions; it is not legal advice. The text of the Act respecting the protection of personal information in the private sector and the positions of the Commission d'accès à l'information govern: for your specific situation, consult a lawyer.
Written by