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, and I did not need our own client research to prove that: I cited two widely reported cases to the team, both public, neither one of ours. A finance worker paid out $25 million after a video call with a deepfake chief financial officer. A father 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.

The business goal itself was clear enough: give staff and clients one secure place to meet, take the risk out of sending data and files over unsecured email, and eventually turn attachments off altogether. The goal was never the hard part.

The harder thing to say out loud was that none of this was an interface problem. Relationships with those 250,000 clients ran through people, through scheduled meetings and phone calls and email and the occasional text message, so every exchange was bespoke, high-touch and personally attended, and even the most routine request landed on someone’s desk as a back-office task. Service delivery had been welded to personal relationship management, which works beautifully at ten clients and collapses at a quarter of a million. You cannot standardise that with a better screen. You standardise it by rebuilding the service around the jobs clients are trying to get done, rather than around the way the organisation happens to be arranged inside.

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. And there was that 17% again, sitting on the other side of the ledger this time: not a segment to court but very nearly the whole population the business was asking to change its habits for. 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

Everything starts with an invitation email, which, given that the whole problem began with clients squinting at emails wondering whether they were real, 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. From there I moved authentication 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 with no history to lean on, so I built the account creation core to carry them through cold: confirm the details we already hold, create a password, verify a phone with a six digit code, then choose whether to trust the device. I gave every step one primary action and nothing competing with it, put help on every screen without letting it shout, and kept progress 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 ↗