What a client portal for agencies actually needs
What a client portal for agencies must do: strict isolation per client, visible dates, approvals on the record, and how to judge one on trial.
· 5 min read · Client delivery
A client emails on a Tuesday morning: where are we with the homepage? The answer exists. It sits in a card on a board, or in a thread from three weeks ago, or in the head of delivery's memory. Someone spends half an hour reconstructing it, writes a careful reply, and the client is satisfied until Thursday, when they ask about something else.
Multiply that across nine or ten retainers and you have created a job nobody applied for: full-time narrator of work that is already happening.
A client portal is supposed to end this. Go shopping for one and you will find a crowded market of tools promising roughly the same screenshot. The differences that matter are not visible on the screenshot. They are structural, and it is worth being fussy about them, because a bad choice costs you twice: once in the subscription, and again when your clients quietly decline to use it.
Isolation per client is the foundation
The first requirement is the least glamorous. Each client must see their own work and nothing else. Not hidden behind a filter someone set up on a Friday afternoon, but actually separated, with the separation enforced by the system rather than by the discipline of whoever configured it.
This matters because the failure is not hypothetical embarrassment. If a client can stumble into another client's requests, they can see who else you work for and how their own account compares. One misconfigured permission and a conversation about renewal becomes a conversation about trust. A portal where isolation depends on a checkbox is a portal where the worst day is always one click away.
So when you evaluate a tool, ask precisely how separation works. If the answer involves views, filters or tags, keep looking. The right answer is a hard boundary per client, enforced on the server, with no configuration path that removes it.
Status and dates the client can see without asking
The second requirement is the reason most agencies go looking in the first place. Clients do not chase because they are difficult. They chase because they cannot see. The question about the homepage is not a demand. It is a symptom of a blindfold.
A portal earns its keep when every request carries a date the client can see, and when that date moves, the client learns the new date and the reason before they have to ask. That last clause is the whole game. A date that silently slips is worse than no date at all, because the client discovers the slip themselves, usually at the worst possible moment. A date that moves in the open, with a reason attached, reads as competence. The work is identical. The experience is entirely different. This is why landing dates deserve to be a first-class feature rather than a field somebody occasionally fills in.
Your own team needs the operational side of the same picture: a filterable list, a board, and a view that answers the only question that matters at nine in the morning, which is what is overdue, what is due today, and what is due this week.
Approvals on the record
Sooner or later a client will say a thing was never approved, or was approved differently, or was approved by someone who had no authority to approve it. If your approvals live in email threads, that conversation is unwinnable. Not because you are wrong, but because the evidence is scattered across four inboxes and a phone call nobody wrote down.
A portal should hold approvals the way a contract holds signatures: feedback attached to the deliverable itself, with named approvers and a timestamped decision. When that exists, disputes get short. There is a fuller argument in a client approval workflow that holds up, but the requirement fits in one sentence: if an approval is not on the record, it did not happen.
The tool your clients refuse to open
Everything above is what a portal must do. Here is what it must not become: another system your clients decline to log into.
This is the quiet killer of portal projects. The agency buys a serious tool, migrates everything, sends the invitations, and six weeks later the clients are back in email because the tool asked too much of them. Heavyweight ticket systems are built for internal teams who are paid to tolerate them. Clients are not. A client will not reset a password to leave a comment. A client will not learn a workflow to ask a question.
Two things prevent this. First, the client should never be chased for logins. Email must keep working, so that a message sent to the workspace becomes a request without the client changing behaviour on day one. There is a longer migration argument in stop running client work from your inbox. Second, the portal should look and feel like yours, not like software you rent. A client who trusts your brand will extend that trust to a portal wearing it.
When you trial a portal, judge it against a short list:
- Isolation enforced by the system, not by configuration.
- A visible date on every request, with movement explained.
- Approvals recorded against the deliverable, with names and timestamps.
- A way in for clients that requires no new habits.
- Pricing that does not punish you for inviting client users. Per-seat charges for clients are a tax on the exact behaviour you want to encourage, so check how the pricing treats client users before anything else.
Then run a real client through it for two weeks. Not a demo project. A live retainer, with the actual client. If they use it without being nagged, you have your answer. If they drift back to email, no feature list will save it.
Where HoopoeHQ fits
HoopoeHQ was built inside a working agency, replacing a heavyweight ticket tool that clients refused to log into, which is why the requirements above read the way they do. One strictly isolated workspace per client, a visible landing date on every request, reviews with named approvers and timestamps, and client users free and unlimited. If that matches the shape of your problem, you can start a 14-day trial with no card and put a live client through it.