Do small agencies actually use a client portal?

What the thread said

The question, posted to a community of marketing agency owners on 10 September: do you actually use a client portal, or do you stick to email, Drive, Slack and WhatsApp, and if you use one, what for? The poster had noticed the split themselves: some people swear by portals, others think they are "another thing clients have to log into."

The replies sorted into three camps. One camp likes the idea of Basecamp or Notion but only for clients with larger teams; for one-to-one work it felt like too much effort. A second camp does not use one at all, has never been asked to, and runs retainers on email with some Slack and WhatsApp. A third camp had the most useful answer, and it was about maintenance rather than features: the portals that die are the ones somebody has to update by hand.

Two things stood out about the thread. Nobody defended the portal as a product. And nobody mentioned the option that sits between "a portal" and "an email attachment", which is the one we build, so this post fills that gap rather than arguing with anyone.

Why portals die

The mechanism described in the thread is worth spelling out because it is the whole story. Work gets tracked where the team already works: a board, a spreadsheet, a chat. The portal asks someone to retype the status into a second place. That becomes one more thing to do on a Friday. Then it stops getting done, the client opens the portal and sees stale information, the client stops opening it, and everyone concludes clients do not want portals.

The conclusion is wrong; the design was. As the same reply put it, the ones that stick are a read-only view of whatever the team already works in. The team updates the board as normal and the client sees it. The only real decision is which fields the client gets to see.

We wrote about the same failure from the other side in clients never log into your portal: the recurring complaint in the category is not a missing feature, it is that the client never went in. A login is a cost the client pays every time, and a hand-updated portal gives them nothing for it.

When a portal starts paying

The thread was also clear about the case where a portal is right. It starts paying when the same "where are we on this" question arrives every week from four or five clients on four different channels. At that point a single read-only place to look saves real time on both sides. Below that threshold, and for one-to-one relationships in particular, nobody asks, and building one is effort spent on a problem the client does not have.

There is a version of that need that is not really a portal at all: a client with several deliverables in flight who wants one address to find them. That is a folder with a link, not a login, and it is covered below.

What clients were asking for

Strip the category language away and the thread describes two client needs. Where is the work, and can I see it. Both are satisfied by a page the client can open, kept current by the people doing the work, without anyone typing a second status anywhere.

Our own data says the same thing from the delivery side. In our last snapshot of pages on Stacktree, more than half had a passcode added on top of the private link, which is what a report, proposal or audit looks like when it is going to one client rather than to the internet. Those pages are the deliverables a portal was supposed to hold. Their owners skipped the portal and sent the page.

The link-per-deliverable pattern

Each deliverable becomes a private page with its own unguessable link. The client opens it in a browser, on their phone, from the email you sent, with no account. If the content warrants a gate, you add a passcode they type, or an email-domain gate so anyone at the client's company can open it and nobody else can. When the work moves on, you update the page in place and the link they bookmarked shows the new version. You see when it was opened, and on paid plans how far it was read, which is the status question answered without a portal.

When one client accumulates several pages, a client space gives them one address, on your domain if you want, that lists everything you have sent them. That is the read-only view the thread asked for, produced as a by-product of sending the work rather than as a second job. The full pattern, with costs, is on the client portal alternative page.

What to leave in Drive and email

The thread's best answer ended with a boundary worth keeping: leave files, invoices and chat out of it, because Drive and email already do those. A deliverable page is not a file system and should not try to be. It is the thing you would have sent as an attachment, made into something the client can open, that you can update, and that tells you it was read. Everything else stays where it already works.