Agency client portal: the honest buyer's guide (2026)

A client portal is a perennial agency ask, right up there with "where do I store the GA4 password." It's also a feature that often ships as a half-built afterthought that nobody opens after week two.

This is the buyer's guide we wish existed when we were evaluating the build-vs-buy decision for Phloz. Honest assessment of what an agency client portal needs to do, what it doesn't, which neighbouring tools it gets confused with, and the multi-tenancy footguns most portal products silently get wrong.

What an agency client portal actually has to do

There are six jobs an agency client portal does. In rough order of how often a client will need each:

1. See the work in progress. The portal's real job is answering "where are we at?" without a call. That means stages a client can read at a glance (received, in progress, done, waiting on you) on the items the agency chose to share, with a due date where there is one. One screen, not a Gantt chart, and no internal notes leaking through.
2. Ask for something new. A form for "can you also…" that hands back a reference and a receipt, so the ask doesn't vanish into somebody's inbox and the client can see whether it was taken on.
3. Approve or push back. Creative, copy, a landing page: one place to approve, ask for changes or reject, with the answer recorded against the work rather than buried in a thread.
4. Reply to messages. Either via email round-trip (the agency sends from the portal, the client replies from their inbox, it lands back in the agency's portal) or via a portal-side reply box. Expect plenty of clients to stick with the email round-trip and never log in.
5. Access shared assets. Brand kit links, the Loom recording of the last call, the latest Google Doc. Read-only — no upload from the portal side because then you're suddenly a file-sync product.
6. Self-service contact updates. "I'm leaving, our new marketing lead is Alex." Single form, persists.

That's it. A client portal that does these six things well is doing its job. Anything past them has to earn its place, and contracts and invoices are a different product altogether (more on that below).

What clients explicitly DO NOT want

Whatever the portal runs on — Basecamp, SuiteDash, ClientPortal, a shared Notion page, something built in-house — design against these:

• Not another login. Magic links land in their email; they click through; they see what they need; they close the tab. Username/password is friction.
• Not a notification firehose. Send a few emails at the moments that matter — work started, work finished, your approval is needed, we're waiting on you — each with an easy way to stop them, and keep a page the client can check in between. Not a Slack-style ping per status change.
• Not "your project" page nobody updates. A portal page that says the same thing for three weeks running is worse than no portal — it actively signals the agency isn't doing anything.
• Not a kitchen-sink dashboard. The six jobs above, clean, readable on mobile. Bolting on a Gantt, a budget tracker, a calendar and invoicing is how portals stop getting opened.

The multi-tenancy footguns

This is where the silent bugs live. The risky portals are the ones built either (a) as a single-tenant product retrofitted into multi-tenant, or (b) with the tenant check repeated by hand in every endpoint, so a single forgotten line exposes another agency's clients. Both routes lead to data leaks.

Footgun 1: workspace context bleeds across portal links

Magic-link tokens identify the portal session, but downstream APIs need to enforce which workspace's and which client's data that session can see. If the portal calls a generic /api/messages?clientId=X endpoint that does authorization based on the session user (not the magic-link's scoped client), an attacker who guesses a clientId from a different workspace can read messages.

The right fix is to never take the client from the request. The portal session resolves, on the server, to exactly one workspace, one client and one contact, and it is re-checked on every request (access still on, not expired, not revoked). Every portal read is then scoped to that client and to rows the agency marked client-visible, whatever ids the browser sent. Row-level security on tenant tables is worth having as defence in depth, but check which paths it actually covers: if the portal reads through a server-side connection rather than as its own database user, the server-side scope is the check that matters.

Footgun 2: magic-link tokens that don't rotate

Some portal products issue one magic-link per contact and reuse it forever. That's effectively a permanent password that's been emailed and forwarded and screenshot'd. The consequence: a contact's old assistant can still have portal access two years after leaving the company.

The fix is single-use magic links that issue a session cookie on first use, AND scheduled rotation (the cookie expires in 7-30 days; expired ⇒ re-request a fresh magic link).

Footgun 3: "client-visible" task flags applied at render time

A task with visibility = "internal" is fine — until someone marks it client_visible to share a status update, then later adds an internal note in the same task's comment thread. If the comment-visibility check happens at render-time in the React component (and that component runs on the server but reads from a query that returned ALL comments), the internal note leaks.

The fix: filter at the query level — the portal's API only ever returns rows where visibility = 'client_visible', and only the fields a client should see. Render-time filtering is too late, and easy to forget on a new comment field.

Footgun 4: file uploads from the portal side

Once a portal accepts uploads, it inherits all of: virus scanning, file-size limits, storage quotas per workspace, retention policies, and the legal question of "whose data is this when the contract ends." A portal that ships uploads without handling these is a liability. The pragmatic choice for an agency portal: no portal-side uploads in v1. Clients send files via email (which already has its own attachment limits + virus scanning). Agency uploads agency-side, sharing happens via read-only links.

Footgun 5: portal pricing per contact, not per agency

Some portal products charge for every client contact who can open the portal. Run the numbers for an agency with 30 clients and an average of 3 contacts each: that's 90 billable portal users, so whatever the per-contact fee is, the bill multiplies it by 90. The line grows every time a client adds a stakeholder, before anyone on your team has logged in. That math doesn't work for most agencies. The structural answer is to price the agency's side and leave client access out of the count. In Phloz's plans, client portal contacts never take a seat and viewer seats are free; each plan includes a set number of seats for the staff who do the work, and on the paid plans extra seats are an add-on.

What "good" looks like in 2026

A clean agency portal in 2026 is:

• Magic-link entry, never a separate password. The client clicks the link, lands on their view, doesn't think about auth.
• One canonical "client-visible" surface — requests, shared tasks, messages and shared files — at /portal/[token] or a vanity subdomain.
• Mobile-clean — clients open portal links from email, and a lot of email gets read on a phone. If your portal doesn't render well on iPhone Safari, agencies will get complaints.
• Branded enough to look professional, not so branded that the agency has to maintain a whole theming system. Agency logo at top, agency name in titles, that's plenty for V1. Deeper theming can wait until clients ask for it.
• Isolation that doesn't live in the UI — every portal read scoped on the server to one client and its client-visible rows. Row-level security on tenant tables is a good second layer, but only on the paths it actually covers. Hiding something in the interface is not a security check.
• Quiet, with a page to check. Email for the moments a client has to know about or act on; the portal for everything in between. Each contact switches the routine emails off for themselves: a per-contact preference, not a workspace-wide one.

Build vs buy: how to decide

Honest take:

• Buy if you don't have engineering capacity AND the portal is one part of a larger product (CRM + tasks + portal). Half the value of a portal is that it integrates with the rest of the system you're already using to manage clients. A standalone portal that doesn't know about your task system is a worse experience than no portal.
• Build if you have a strong differentiation idea AND >5 engineering hires AND the portal is core enough to your offering that you'd rather not depend on a third party's roadmap. Build is a 3-6-month commitment if you want it done right (including the isolation work above).
• Build a thin shim if your existing PM tool (Linear / Asana / Monday) gives you most of what you need but you want a custom subdomain. This is the worst long-term path — you end up reimplementing much of the portal anyway as customer-facing tweaks pile up. Skip.

The most common right answer for a sub-50-person agency: buy something integrated with the rest of the CRM stack, configure the six core jobs above, ignore the kitchen-sink features.

Contracts, payments and the portal are three different products

A lot of "which client portal should we buy?" shortlists mix up three different jobs:

• Contracts: the proposal, the scope and the client's e-signature, done once per engagement and again at renewal.
• Payments: invoices, deposits, payment plans and recurring billing.
• The delivery portal: status, requests, approvals and files, every week for as long as the retainer runs.

Tools such as HoneyBook, Dubsado and Bonsai cover the first two jobs. All three send proposals and contracts for the client to sign online, and all three bill on a schedule: HoneyBook with payment schedules or recurring charges, Dubsado with payment plans that split an invoice into instalments, Bonsai with recurring and subscription invoices. Each has a client portal too, where the client finds the documents shared with them and their invoices (HoneyBook, Dubsado, Bonsai). Those details come from each vendor's own pages, read in October 2026; check them again before you buy, because features change.

A delivery portal is a different shape. Its job is the six listed at the top of this guide, and it only works if it reads from the system where the work is actually tracked. Otherwise someone copies status from one tool into another every Friday, and the portal is out of date by Monday.

The practical split:

• Sign and bill in a tool built for it. Contracts and invoices carry legal and accounting weight; don't improvise them in a delivery tool.
• Run delivery where the work lives. The client's view of progress should come from the same tasks your team updates, not a second copy. It's the same reasoning as the pipeline-versus-lifecycle split: buy the shape that matches the job, and this job is delivery, week after week.
• Don't buy an all-in-one before your process repeats. If onboarding and delivery still look different for every client, you'll configure a big tool around a process you don't have yet. Get the first 30 days of a new client running the same way twice, then decide.

Phloz sits on the delivery side. It has no contracts, e-signature or invoicing, on purpose.

How Phloz's portal works

Brief plug — the portal we ship is the one we wished existed:

• Magic link, no password. A sign-in link works once, expires after 60 minutes and opens a 30-day session. When the session lapses, the client asks for a fresh link at /portal/login — no password, ever.
• Requests with a reference and a receipt. A client files a request (a title and the details) and gets a reference in the agency's own series, like KELD-R17, plus an emailed receipt. The team accepts it with an assignee, declines it with a reason the client sees, or marks it a duplicate, and the client is emailed the decision. More on tracking client requests by reference.
• A progress bar the client can read. A shared request shows Received → Accepted → In progress → Completed; a shared task shows Planned → In progress → Completed, with its due date and any approval waiting. On a shared task the client never sees the description, assignee, priority, subtasks or comments.
• Approvals. When the team asks, the client approves, requests changes or rejects from the portal.
• Email at the moments that matter. When a shared task or request moves to In progress or Completed, or the team asks for the client's approval, the client is emailed in the agency's name. Other status changes send no progress email; Blocked, for one, reads as In progress to the client. Each of these emails carries a "Stop these updates" link, and each contact can switch them off in the portal.
• Ask for an update. While an item is open, the client can ask for an update once every 48 hours; it goes to the assignee or, failing that, to the workspace's owners and admins. On a shared request marked Completed, they can say "This isn't finished".
• Waiting on the client. When the team marks a shared request or task as waiting on the client, the client is emailed what's needed and answers on the item's page in the portal. Without an answer, reminders follow 3 and 7 business days later; a request closes 21 days after the ask, while a task never closes on its own.
• What else the client sees: a dashboard summary, their conversations, shared files and plans, a tracking-health summary they can sign off, their own contact details to edit, and a way to report a problem. Mobile-clean. Your agency's name, logo and colour on every plan; on Business and up, your own domain and no "Powered by Phloz".
• Isolation checked on every request. Every tenant table has RLS, but the portal has no database login of its own: each portal request re-checks the session (access still on, not expired, not revoked), and the server scopes every read to that one client, returning only its requests and what the agency marked client-visible — never internal notes.
• No portal-side file uploads. The agency adds files on its side and chooses which ones the client sees; a request takes no attachment either.
• Client contacts never take a seat. Viewer seats are free too.

See Phloz's agency client portal for the full tour, or start a free workspace to test it against your own client.