Most client portals in legal tech are document dumps clients open once. Here's what changes when the portal is built around how the work actually moves.
Most law-firm client portals are unused. Not "underused" — actually unused. The client opens it once, looks at the document, downloads it, replies in email. The portal becomes the place files live; the work happens everywhere else. There's a reason for this, and it isn't that clients are bad at technology. It's that legal-tech portals have been built around what's easy to store, not what the client actually wants to do.
Pick a typical engagement. The attorney sends a draft. The client opens it. What does the client want to do, in order?
Now look at a typical legal client portal. It shows the document. It might have a comments field. It probably emails the attorney when a comment is posted. Everything else on that list happens outside the portal. The discussion with the GC happens in Slack or email. The change request gets relayed verbally on a call. The approval is a "looks good, please proceed" reply. The "see what happened next" is the client refreshing their inbox.
It isn't a portal. It's a viewer with a comments form. That's why clients stop opening it.
The change that makes a portal usable is structural: the document and the conversation about the document have to be on the same screen, in the same timeline, accessible without switching contexts.
When a client opens an active engagement, they should see the document on one side and every message, approval request, change request, and prior version on the other. They shouldn't have to remember whether the latest note from the attorney was in email or in the portal — there's only one place it could be.
This is harder than it sounds. It means the portal is responsible for the conversation, not just the file. Which means notifications, threading, and reply UI all have to actually work. Most legal-tech vendors didn't build for that because file storage is the easier problem.
The second structural problem with most legal client portals is that they assume one client = one user. The attorney invites someone with an email address. That person gets access. Everybody else on the client side is implicitly out.
In real engagements, the person who handles the contracts associate work is not the same person as the GC who approves the final version. The deal owner who's actually trying to close the deal might be a third person again. All three of them need to see the same document, send the same kinds of requests, and operate from the same shared understanding.
When the portal only supports one user per client, two things happen. The first is that the one invited person becomes a forwarding service — they get the email, they forward to the team, the team replies to them, they paste back. Everything goes through one bottleneck. The second is that the team eventually gives up on the portal and just works in email, because email at least supports a real CC list.
A real client portal has to support multi-user access from the start. The contracts associate can be invited. The GC can be invited. The deal owner can be invited. Each gets their own login, sees the same work, and can act independently.
Clients are one half. The attorney is the other. If the portal is built right for the client but wrong for the attorney, it still doesn't get used — because the attorney won't move their work to a tool that costs them time.
For the attorney, the portal has to be visible from inside their main workspace. The same conversation thread the client sees should also be on the attorney side, in context with whatever else they're doing on that doc. If the attorney has to open a separate "client portal admin tool" to see what the client said, the friction kills it.
The attorney also needs the portal to capture time. Every minute the attorney spends responding to a client question on the portal is billable work that historically got lost. If the portal lives in the same surface as the editor, the attorney's time-tracker is already running on the right doc, and the work that used to evaporate is now invoiceable.
And the attorney needs to be able to close the loop without ceremony. Approve a doc and the client sees it. Send a doc out for client review and they get notified. Request a small change and it shows up in the client's timeline. None of this is novel; all of it has to actually work end to end.
"Real-time chat" is a feature nobody asks for in a legal portal. What clients actually need are three first-class actions:
Each of these actions also has a side effect on the attorney's view. An approval flips the doc to customer_approved. A change request reopens it for editing. A close moves it to the Closed section. The attorney doesn't have to read between the lines to figure out what the client meant. The intent is structured.
The honest answer is that the existing CLM and document-management vendors didn't have an incentive to build it. Their customer is the in-house legal department, who treats the client portal as an export surface — a place to publish the executed contract. The clients on the other side of those portals aren't the buyer of the software, so the experience for them never has to be good.
For outside counsel and small firms, the calculus is different. Your client is the user. Their experience of the portal is your experience of your practice. If the portal is bad, the client thinks the firm is bad. If the portal is great, every interaction with the firm reinforces the value you're providing.
This is why a client portal built specifically for outside counsel can be structurally different from one bolted onto a legacy CLM. The audience is the same audience that's paying the bills, which means there's actual product pressure to make the experience work for them.
If you want to know whether your current portal is good, ask your most engaged client one question: when was the last time you opened the portal voluntarily — without an email from us telling you to?
If the answer is "I can't remember," the portal isn't a portal. It's storage with a login.
If the answer is "I check it every morning to see what's new," you've built — or you're using — something that actually changes how the engagement runs.
See what changes when the document, the conversation, and the workflow are all on the same screen.
Multi-user portals · Attorney-built · 14-day free trial