Service Portal Onboarding

The Problem

There is a moment in our journey maps I kept coming back to. A client receives an invoice by email, and before they can pay it they have to work out whether it is real. They check the sender address. They squint at it. The question written on that journey map is “is this a scam?”

That question is the whole problem. The firm does accounting, tax, wealth, audit and advisory work for everyone from individual taxpayers through to enterprise clients, and a great deal of that work was arriving in people’s inboxes. Invoices, agreements, requests for documents. Meanwhile the fraud around it had become very good. The research I pulled together included a finance worker who paid out $25 million after a video call with a deepfake chief financial officer, and a father who heard his son’s cloned voice on the phone. When we mapped what clients told us trust actually meant, one of the things they said was that they needed to be able to verify their relationship with us by checking an email address. That is a fragile thing to hang trust on.

So the business goal was clear enough. Provide a secure digital touchpoint between staff and clients, reduce the risk of sharing data and files over unsecured email, and turn off email attachments altogether. The goal was never the hard part.

The commercial logic ran deeper than compliance, too. In this industry the scarcest resource is fee-earner time. The most rigorous benchmark going, from Kitces Research across nearly 1,000 advisers, puts the average cost of acquiring an advisory client at US$3,119, and 83% of that is the adviser’s own time rather than marketing spend. Every client interaction that arrives as an unstructured email is a slice of that same expensive time, spent unbilled. A portal that turns interactions into structured services attacks cost-to-serve as well as risk.

And here was the tension, sitting between two facts that did not want to agree. The business needed clients online, and it needed that soon, because every month on email was another month of exposure. The research said only about 17% of clients preferred to manage their services online. There is a slide in my deck that says nothing except Business Goal ≠ User Goals, because I kept needing to say it out loud. Designing only against the compliance mandate would have built something clients had already told us they did not want, and adoption would have proved the point for us. Designing only against what clients said they wanted would have missed the risk entirely. The work was finding the version where both could be true.

What 17% actually meant

Everything turned on that 17%. It is an easy number to read as a verdict. Only 17% want this, so why are we building it?

I did not think that was what it said, so I put it against the diffusion of innovation curve. In a normal population, innovators and early adopters together are roughly 16% of people, which means a 17% appetite is about what you would expect for a product that does not exist yet. But this client base is not a normal population. It skews tech conservative, so the curve is negatively skewed. Its genuine innovators and early adopters are closer to 6%, and the group directly behind them is around 9%.

The 17% was never a ceiling on interest. It was the shape of the people we were designing for.

That changed the brief. It meant building for early adopters was a dead end, because there were barely any. Whatever we made had to work for someone who is not confident, is not curious about new software, and is not going to persevere when it gets hard. Build for them and the majority can follow. Build for the 6% and nobody does. Every decision after this one leans on it.

Two scenarios, one shared core

The firm acquires portal users through two distinct paths, and treating them as one flow would compromise both. So I designed a shared account creation core (verify identity, set password, confirm device) and bracketed it with scenario-specific entry and exit states.

Scenario 1. Existing client activates

The trigger is an invitation email. Given that the whole problem started with clients squinting at emails wondering whether they were real, this one had to work harder than most. I led it with the purpose rather than the credential, so the first thing you read is what you are being invited to do, not a password you have to use before it expires. Authentication then moves to phone verification and an optional device trust, which is passkey eligible. Passwords are easy to guess and easy to steal, and a passkey is both safer and faster for someone who does not want to think about it.

Both are recreations. The pattern on the left is the one this project was trying to survive: a no-reply sender, a credential in plain text, and a countdown. For an audience already asking “is this a scam?” it is indistinguishable from phishing.

Scenario 2. New client signs up

A new client arrives and enters the account creation core. They confirm the details we already hold, create a password, verify their phone with a six digit code, and then choose whether to trust the device. Every step has one primary action and nothing competing with it. Help sits on every screen without shouting. Progress is visible the whole way, because for someone who is not confident with software, knowing how much is left is the single biggest thing you can do to lower the temperature.

The four-step account creation core plus its landing state. Recreations.

Try the flow

The screens above are stills. Below is the flow running, so you can judge the thing I was actually designing for: what it feels like to be uncertain and still get through. Try a half-finished email address, a password that is too weak, or the wrong security code. The demo code is 472913, and the shortcuts underneath jump straight to the error and completion states.

Live prototype, keyboard operable throughout. Open full screen ↗