Client portals that partners will actually use

Most branded client portals fail the partner test. The firm pays for it, the client logs in once, and the workflow goes back to email. The portals that survive past month three share three things: they replace a workflow the partner already wanted to drop, they answer one urgent client question better than email, and they do not ask the partner to learn a new tool. We have built and watched several across Melbourne professional services firms.

The partner test, and why most portals fail it

The partner test is simple. Three months after the portal goes live, are the partners using it without being asked? If the answer is no, the portal is a parallel system the firm pays for and clients ignore. If the answer is yes, the portal has earned its keep.

Most client portals fail this test. The reasons are almost always the same.

The portal was sold to the firm before the partner workflow was understood. A vendor walked in, demoed a clean UI, showed the secure document exchange, named two competitors, and left a quote. Nobody asked the partner who handles the most complex matters how she actually works through her morning. The portal that gets bought looks great in a demo and breaks against the partner’s real day.

The portal added a step instead of replacing one. The client still emails, the partner still emails back, and now there is also a portal where some documents end up because the practice manager pushes them there. The portal becomes a second copy of the source of truth, which means it is the wrong source of truth half the time. The partner’s correct response is to keep using email and let the practice manager reconcile.

The portal demanded the partner learn a new tool to do something she could already do. Logging into a portal to upload a statement is more work than dragging the file into an email reply. If the portal does not pay back that extra friction with something the partner actively wanted, the partner stops paying the friction. This is not laziness. It is correct economic behaviour.

A successful client portal flips each of these. The partner workflow is the design constraint, not the demo. The portal removes a step the partner already hated. And the partner gets back something she was previously paying for in admin time, like the end of “where is my tax return up to” emails.

The three signals of a portal that will be used

When we run the two-week pilot before a portal build, the three things we look for are concrete.

The partner already wants to stop doing the workflow the portal will replace. A wealth principal who is tired of emailing the same SOA cover note out every review cycle is a partner who will use a portal that handles it. A partner who is comfortable with email-as-workflow because that is how she has practised for decades is not. The portal does not change the partner’s mind. It rewards the partner who has already changed it.

One urgent question gets a better answer in the portal than in email. Pick the one question clients ask the firm most often. For an accounting practice it is usually “where is my BAS” or “did you get the bank statements.” For a law firm it is “what is the status of my matter.” For a wealth practice it is “when is my annual review and what does it cover.” If the portal answers that one question faster and more accurately than the partner can in an email reply, clients will adopt it. If the portal cannot, they will not. We have seen portals with twelve features fail because the answer to the one urgent question was still hidden two clicks deep.

The partner can ignore the portal and her workflow still runs. Counter-intuitive but important. A portal that punishes the partner for not logging in is a portal the partner will resent. A portal that quietly handles the client side, posts statements, accepts uploads, sends reminders, and only pings the partner when she actually has to make a decision is a portal she will tolerate, then come to rely on. Adoption follows tolerance, not pressure.

If the pilot cannot find all three of these signals, we say so and recommend not building yet. The right portal at the wrong time is still a wrong portal.

What to keep in email and what to move to the portal

Not every client interaction belongs in a portal. The portal should hold the workflows where structure pays off, and email should hold the conversations where it does not.

What belongs in the portal:

• Document exchange. BAS workpapers, engagement letters, SOAs, trust statements, signed forms. Files that need a record of who uploaded what and when, that the firm has compliance reasons to retain, and that clients will need to find again.
• Status visibility. The “where is my matter, return, review” question. The portal that answers this without an email is the portal that earns the partner’s quiet trust.
• Structured requests. Information requests, missing-document chases, approval flows. The partner sees the queue, the client sees what is outstanding, and nothing gets lost in an inbox thread.
• Audit trail. Anything where the firm has to prove who saw what, who approved what, who was sent what and when.

What stays in email:

• The conversation. The phone call follow-up, the “quick question”, the partner’s professional view on the client’s situation. Email is where judgement is communicated. A portal that tries to absorb all conversation produces sterile, lawyered prose because every message feels like it is on the record.
• The relationship. Birthday notes, condolences, congratulations on the new role. The portal is for transactions. Email is for the texture around them.
• The first response to a problem. When something has gone wrong, clients want to hear from a person fast. The portal is too slow, too formal, and too document-shaped for that first message.

A common mistake is trying to move every interaction into the portal because the portal is the thing the firm bought. The right answer is to move the workflows the portal is good at and leave the rest in the channel that already works. Fewer features, more adoption.

Branded vs vendor: when the difference matters

Most professional services firms have access to a portal already. LEAP ships one. Xero has Xero Files. Xplan, HUB24 and Netwealth all have client-side portals. SuiteFiles, FYI and ShareFile sit alongside. The first question is usually whether the firm needs anything beyond what is already turned on.

The honest answer is that the built-in portals work well in straightforward cases. One-system clients, standard matter flow, documents that fit the vendor’s shape. The cost is already paid as part of the licence. The IT lift is minimal. For a firm that fits the vendor’s idea of a workflow, the built-in portal is the right answer.

The points where a branded custom portal earns its keep are specific.

The brand experience is yours, not the vendor’s. For firms whose value proposition is the calibre of their advice, presenting clients with a portal that says “powered by HUB24” or that lives at a vendor’s URL undercuts the positioning. A branded portal at portal.yourfirm.com.au is the firm’s surface. The client experience matches the brand the rest of the firm has invested in.

The cross-system view. A wealth practice needs to show the client a single picture of advice plus platform statements plus the annual review pack. The HUB24 portal shows the HUB24 holdings. The Xplan portal shows the planning artefacts. Neither shows the firm’s complete view of the client. A custom portal sits over the top and presents one picture, which is what the client wanted in the first place.

Document types the vendor does not model. A law firm running a wills and estates matter has document types LEAP knows about and document types it does not. The vendor portal handles the modelled ones. A branded portal handles the rest without forcing the firm to misuse a “general document” bucket.

Workflow gates the vendor cannot enforce. Information requests with structured responses, approvals that route through two partners before the client sees them, document expiry that triggers a reminder email at thirty and seven days. Vendor portals have shapes for some of these. Custom portals can shape them around the firm’s actual practice.

The decision is rarely “all custom or all vendor.” The pattern that works is the vendor portal carries the workflows the vendor models well, and the custom portal carries the rest. Where the line falls depends on the firm’s mix of clients and matters, which is where the pilot earns its money.

The two-week pilot we run before any portal build

We do not start a portal build with a quote. We start with a two-week pilot whose only deliverable is a written recommendation. The recommendation is sometimes “do not build.”

Week one is observation. We sit with the partner who handles the highest-volume client workflow, not the partner who is keenest on technology, and watch how she works through a real day. Every email, every system she touches, every “quick” admin task that turned into twenty minutes. Mid-week we shift to the practice manager and one front-line staff member. The practice manager knows where the firm leaks. The staff member knows where the practice manager is wrong about which leaks matter. Both views are needed because partners describe a workflow that is half memory and half aspiration.

Week two is the model and the recommendation. We pick one workflow, model what a portal would do for it end to end, and walk it back to the partner. We are not selling. We are testing whether the partner sees the same problem we saw and whether the proposed shape would change her day. If she does not, the portal will not be used. The week closes with a written recommendation. Sometimes it is “build a small portal around the one workflow that hurts most.” Sometimes it is “the vendor portal will do this once you turn on the feature you have not configured.” Sometimes it is “do not build yet, the workflow is not stable enough to model.” We have made each of these calls.

The pilot costs are explicit and small relative to the build. Most firms find the recommendation pays for itself even if they decide not to proceed, because the partner shadowing surfaces things that change how the firm runs the next month regardless of the portal decision.

The staff portal matters here because it determines whether the client portal works. If the team has to log into three systems to answer a question that arrives through the client portal, the client portal becomes another inbox the firm cannot keep up with. We cover that side in the staff portal piece. For now, the question is whether the partner will use the client side, and the pilot answers it before the firm spends the money.

A custom client portal earns its keep when the partner test passes, the urgent question gets a better answer than email, and the firm has the staff portal in shape to keep up with what the client portal generates. Two of three is not enough. The firms with the highest portal adoption have all three. The ones who skip the pilot tend to find out which of the three they were missing about six months in, by which point the portal is the thing nobody opens.

If you want to walk through the partner test for your own firm, our client and staff portals work is the place to start. The pilot is part of how every portal build begins. For law firms the test usually centres on matter status. For wealth practices it centres on the annual review pack and platform statements. The shape changes. The test does not.