Clients never log into your portal. The login is the reason.

The complaint is always the same

Read enough agency threads about client portals and a pattern appears that has nothing to do with software quality. Someone asks which portal to buy. Six get named. And then, reliably, somebody says the quiet part: we set one up, and the client never went in.

In the last month alone: r/Notion, 11 August 2026, "Does anyone use Notion as a client portal for their agency?", seventy points and a comment section that turns quickly from how to build it to whether anyone will open it. r/marketingagency, 27 July 2026, a thread titled simply "Client Portals", fifty-eight points. r/agency running the same conversation a few days later, thirty-three points. Three subreddits, three different tool stacks, one recurring answer.

Notice what the complaint is not. Nobody says the portal lacked a file preview, or that the branding controls were thin, or that the mobile view was broken. The software mostly works. The client just did not use it. That is a different class of failure, and it does not get fixed by buying a better portal.

The category knows, and its fix proves it

Here is the part that should settle the argument: the portal category is entirely aware of this, and has published its remedy for years.

The remedy is to put something the client cannot get anywhere else behind the login. Their invoice. The signed contract. The deliverable itself. Stop emailing copies. Make the portal the only route, so the client has to go in.

Read that as an engineering decision rather than a growth tip and it is a remarkable thing to recommend. It asks you to degrade your own delivery so that a piece of software gets used. The mechanism it relies on is not value, it is withholding. You only need a mechanism like that when the thing you built is not, on its own merits, somewhere anyone wants to go.

Every category has a tell, and this is the portal category's. The advice works, in the narrow sense that people do log in when the invoice is the only thing in there. But a workaround this widely recommended is usually pointing at a design problem, and this design problem is not even hidden. It is the login.

What you are actually asking for

Stand on the other side of the invite for a moment.

A client hired you. They paid. In return they get an email containing a link, a temporary password, and an instruction to set a new one. To read a document that you wrote, for them, about their own business, they must click through, choose a password, store it somewhere they will find it again, and remember which of the four agencies they work with uses which portal. Next quarter they will not remember. They will search their inbox for the invite, fail, and email you asking for the file.

That is work. Small work, but work, and it is being asked of the person who already paid for the thing on the other side of it. The account buys them nothing they did not already have. Everything the login is protecting was theirs to begin with.

Nielsen Norman Group has been blunt about login walls for a long time: the interaction cost is high, and demanding registration before delivering any value inverts the reciprocity people expect. Baymard's checkout research keeps arriving at the same place from the commercial side, where forced account creation is one of the durable causes of abandonment even among users who came specifically to buy. If people will walk away from a purchase they intended to make rather than create an account, the odds on a busy client creating one to read your monthly report are not encouraging.

And the client is not being difficult. Email already does this job. It is searchable, it works on their phone, it needs no password, and it is where the rest of their working life happens. Asking someone to leave a tool that works for one that requires setup, in exchange for nothing, is a losing pitch however good the portal is.

When the login earns its keep

This is where the argument has to be honest, because there is a real case for portals and pretending otherwise would just be selling.

An account is not friction for its own sake. It is identity, and identity is worth paying for when the system genuinely needs to know who is acting. That is the whole test: does the client do something in there, or only receive?

• The client uploads. Tax documents, brand assets, source data, the long back and forth of onboarding. You need to know who sent what and when, and they need a durable place to put it.
• Things get signed. An e-signature is close to worthless without an authenticated identity behind it. The account is the evidence.
• Money moves. Invoices, stored payment methods, billing history. Nobody sensible wants that sitting behind a shared passcode.
• There is a shared workspace. Approvals with an audit trail, threaded comments, tickets, a project the client is genuinely participating in rather than watching.

In those cases the friction is buying something. The client accepts a password because the password protects their own actions, and adoption follows without anyone having to hold an invoice hostage. Copilot, SuiteDash, Moxo, Clinked, Zendo, Taskip and the rest are built for that. If your engagements look like that, buy one, and ignore the rest of this post. Portal suites are not bad software. They are software for a bidirectional relationship.

Delivery is the case that never earns it

The failure is specific, and naming it precisely matters more than the general grumbling.

It is one-directional work. You made a thing. The client reads the thing. Nothing flows back except an opinion. The audit, the monthly report, the strategy deck, the wireframes, the campaign results, the research write-up. This is the bulk of what most agencies and consultancies actually hand over, and it is exactly the case where the account buys the client nothing at all.

There is nothing to authenticate. The client is not acting, they are reading. The system does not need to establish which of the three people at Acme opened it in order to show them a document their own company commissioned. An account here is the shape of a permission system with no permission being decided.

Which is why the pattern holds so consistently. Practices that use a portal for signatures and file collection report that clients do go in, because the client has business in there. Practices that use one purely to hand over deliverables report the opposite, and then quietly go back to email. Same software, different job, and only one of those jobs was ever the software's.

What delivery actually needs

Take the account out and list what is genuinely required to hand a client finished work:

• A private address. Not indexed, not guessable, not public.
• Proof of entitlement proportionate to the sensitivity. Sometimes an unguessable link is enough. Sometimes it should be a passcode. Sometimes it should be restricted to anyone holding an address at the client's company domain.
• One address per client, so the work accumulates in one place instead of scattering across a year of email threads.
• Your name on it, not a vendor's, because the deliverable is the product.
• One version. Revisions land at the same address, so nobody is reading v3 while you are discussing v5.
• Some idea of whether it was read.

Every item on that list is achievable without an account. A passcode is authentication. It is simply authentication scaled to the actual risk, which is a document, not a bank. Other people are arriving at the same place, and the shape they keep describing is the same one: the client gets one secure link, and no account.

Plain disclosure before the next paragraph: this is Stacktree's blog, and Stacktree is built on precisely this argument, so weigh it accordingly.

You publish a deliverable, optionally filing it under a client, and it becomes a private page. A client space collects everything you have published for that client at one address, which you can put on your own domain as acme.youragency.com and serve as a generated portal page with each deliverable at a path underneath. Put a passcode or an email-domain gate on the space and every page under it inherits it: the client types it once and that browser stays in for thirty days, with no account and no login. Filing pages under a client is free on every plan, including the free one, because grouping your own work should not be a paid feature. The paid part is the address: Solo at $19 a month includes one activated space, Studio at $79 includes ten, Firm at $249 is unlimited, and clients are never seats.

What Stacktree does not do is the other half, and it matters that this is said plainly: no file collection from clients, no e-signatures, no invoicing, no payments, no CRM, no project management, no messaging. If the login in your workflow is earning its keep on any of those, keep the portal. Plenty of practices run both, the suite for paperwork and a link for the work itself.

The security objection, answered properly

The predictable reply is that a link is less secure than a login, and it deserves a straight answer rather than a slogan.

A login is not automatically stronger. Most portal accounts are protected by a password the client chose in four seconds, reused elsewhere, and stored in the same inbox where you sent the invite. A compromised email account opens the portal and the link alike. The login is frequently not doing the work people imagine it is doing.

What actually decides the security of a delivery is narrower and more checkable: how guessable the address is, whether it can be indexed, whether a second factor sits in front of it, and how long it lives. An unguessable URL with a passcode in front and an expiry behind it is a defensible posture for a client report, and it is auditable in a way "we bought a portal" is not.

If what you are handing over needs more than that, if it is regulated, or evidential, or genuinely sensitive, use a system built for that and accept its account model without complaint. The argument here is not that authentication is bad. It is that the gate should match the risk, and an account should never be worn as a talisman.

The point

A portal nobody logs into is not underused software. It is a correct answer from your client to a question that was asked badly.

If your client acts inside the system, give them an account and it will get used, because it will be worth using. If your client only receives, take the login out, put the work at an address they can open, and stop treating the deliverable as bait for a tool nobody asked for. The work you did is the thing they paid for. It should not be the hostage.