How to run a client portal that reduces your email volume

Most agency client portals fail the same way. You set one up, tell clients about it, they log in twice, and then they email you anyway — and now you're maintaining two systems instead of one. Email volume goes up, not down.

The portals that work don't start with software. They start with a week of your actual inbox, sorted into categories, because you cannot replace a channel until you know what the channel is carrying.

Sort a week of email first

Take one normal week and categorise every inbound client message. Not by client — by what the client wanted. A hypothetical week of 60 inbound client emails at a small agency:

What the client wanted	Emails
Status: where is this, is it on track, when will I see it	22
Files: sending assets, asking for a deliverable, wrong version	14
Approvals: feedback, sign-off, "one small change"	10
Scope: new requests, questions about what's included	8
Admin: invoices, scheduling, contracts	6
Total	60

The first three categories are 46 of 60 — a bit over three quarters — and they are the ones a portal can genuinely absorb, because they're all questions about state that a shared surface can answer without a human writing a sentence.

Scope and admin are different. Those need a person, and a portal that tries to handle them just adds a form nobody fills in.

Be realistic about the hit rate. Not every status question stops just because the answer is visible somewhere; some clients will always prefer to ask. If you convert half of that 46, you remove 23 emails a week — a 38% cut in inbound volume, and a bigger cut in the mental load, because those 23 were the interrupting kind.

What that's worth

Assume each of those emails costs four minutes end to end — reading it, finding the answer, writing back, and the cost of having been interrupted at all. That's 92 minutes a week, about an hour and a half.

At a loaded cost of $95 an hour, that's roughly $146 a week. Across 46 working weeks, around $6,700 a year of capacity — for one agency, on one week's sample. The number is illustrative, but the shape is right: the cost of answering "where are we at?" is invisible per instance and substantial in aggregate.

The three things the portal must do

Given the categories, the requirements are narrow and specific.

Answer the status question without anyone asking it. The client needs to see, without logging a request, what's in progress, what's waiting on them, and what the next date is. If a client has to click three times to find out whether you're on schedule, they'll email instead — and they'll be right to.

Be the only place deliverables live. One canonical location, with versions, where the latest thing is obviously the latest thing. The moment you email a file "just so you have it," you've reintroduced the ambiguity the portal existed to remove, and you'll spend the next month answering "is v3-final the newest one?"

Make approvals trivial and traceable. A clear ask, a clear button, a timestamped record of who approved what. Approvals scattered across email threads are how scope disputes start, because six weeks later nobody can find the message where the client said yes.

Notice what's not on that list: chat, task management, comment threads on everything, dashboards of charts. Those are features that impress in a demo and get used for a fortnight.

Why clients abandon portals

Their question isn't answered there. They log in, don't find the thing they wondered about in ten seconds, and revert to email permanently. First impression is close to the only impression.

Nothing pushes. Portals that require the client to remember to visit are dead within a month. The portal should email them when something needs their attention, with the substance in the email and a link for the detail. This sounds like it defeats the purpose; it doesn't. You're replacing 23 emails you had to write with a handful that write themselves.

Too many logins. Every additional password is a reason not to bother. If your clients need separate accounts for files, approvals and invoices, they will use none of them.

You don't use it either. If your own team still sends deliverables by email because it's faster, the client learns that the portal is theatre. This is the most common cause of death and it's entirely self-inflicted.

Migrating without a fight

Don't announce a new process to all clients at once. Nobody has ever been excited by an email titled "Introducing our new client portal."

Start with new projects only. A client who has never worked with you any other way just accepts it as how you operate, and you get to find the rough edges on one project rather than fifteen.

For existing clients, move them at a natural boundary — a new phase, a renewal, a new stakeholder joining. Never mid-project. Changing where the files live in week seven of a ten-week build creates precisely the confusion you're trying to eliminate.

And when a migrated client emails you a status question anyway, answer it — then add one line: "I've also put this on the project page, which is always current if you want to check between updates." Answer first, redirect second. Redirecting without answering reads as a brush-off and guarantees they never log in again.

What still belongs in email

Be explicit about this, or you'll frustrate people. Bad news, judgement calls, anything sensitive, and anything requiring a genuine conversation belongs in email or on a call. "The launch date has to move" is not a portal notification.

The portal handles state. Humans handle change, disagreement and everything with emotional weight. Agencies that try to route difficult conversations through a system are, in the client's eyes, hiding — and that costs far more than 23 emails a week is worth.

Do this week

Don't buy anything yet. Open last week's inbox and tag every client email into the five categories above. It takes about twenty minutes for a week's volume.

Two things usually fall out. First, the actual split is rarely what you assumed — plenty of agencies discover their volume is mostly file-shuffling rather than status. Second, one client is generating a wildly disproportionate share, and that's not a portal problem at all. It's a working-agreement problem, and it's worth a conversation this week regardless of what software you end up with.