How We Took an Advisor Portal From Plan to Pilot in Three Months

Yesterday ten advisors at a wealth management firm with several hundred advisors, and five members of its advisory leadership, started a pilot of a portal that at the start of the summer was a set of architecture documents and a development environment.

A build like this would normally take years. Planning and product work ran through the spring. The build itself took twelve weeks, run as six two-week sprints from the end of June, and the minimum viable version went out last week.

Last week I wrote about this pilot in How to Write a Pilot Plan That Ends in a Decision. This is the follow-up, including the parts that are not finished.

What shipped

One advisor portal, and the agents behind it. Other partners own other parts of the firm's platform. This is our piece.

The firm's own leadership described the problem plainly early on: advisors working across page after page of fintech, copying from one screen to the next. The portal puts a single view of each client in one place, drawn from the systems advisors currently jump between.

Around that view sit the agents. One prepares the advisor before a client meeting. One writes up the meeting afterwards, with the recap, the action items and any referral the client mentioned. One scores the conversation for coaching. And a per-advisor view looks across an advisor's meeting history rather than one meeting at a time.

All of it runs inside the firm's own cloud environment. The agents read from the data lakehouse the firm's data team built. The models are called through the firm's own account. Nothing in this build required client data to leave the firm, and their security team had seen the design before the build began.

How it went in twelve weeks

The team was five: me, a technical lead, a data engineer, a full-stack developer and a designer. We build with AI in the loop at every step, from the data mapping to the code, and that is a large part of why twelve weeks was enough.

The clearest example is the data. Every number on every screen has to trace back to a field in a source system. An AI-assisted first pass produced around a hundred candidate matches between the portal's data points and the firm's CRM. None of them was an answer yet. They went to the firm's own experts on that system to validate, and the list kept changing as they did. The machine did the first draft. The people who know the data decided what was true.

The agents went first, in the opening two sprints, because they are the most visible part of the portal. Real CRM data for a first group of five advisors landed in the first week of July, and from then on every screen was live and rough on real clients, refined each sprint while advisors told us what was wrong. The designer ran advisor interviews alongside the build, and the home screen came out of those conversations rather than out of a design review.

Not everything could arrive at once. Access to the firm's planning software was always going to come late, so the screen that depends on it went last, deliberately, where it could not hold up the rest. Our own plan said at the outset that the data mapping figures were estimates rather than a baseline, and they moved exactly as much as that sentence warned.

What changed since last week

Last week I said a pilot needs a decision, a date, a number and a baseline, and that this one had a strong defect protocol and an ending we were still adding together.

It has a date now. The pilot began on Monday the twenty-first, and the decision on a wider rollout follows early next year. That is a longer runway than the few weeks I described last week, and it means the decision will rest on months of real use rather than first impressions.

The pilot advisors are working on their own clients. More than a year of each advisor's own meeting transcripts was gathered for the pilot before they got access, so that what they are judging is output about people they actually know.

The testers still compare the portal against the views they use today and record what is fixed, broken, missing or not working as expected. That will produce a proper defect list.

The number I want read at the decision is the one we added together last week: minutes of preparation for a real client meeting in the portal, against the usual route, and how many separate systems the advisor did not have to open. I have no result to report. Nobody does yet. When there is one, and the firm is comfortable with it being shared, I will publish it with the method attached, whatever it says.

If your pilot starts next week

Three things from this one, worth doing before the testers log in.

Load the testers' own data. A pilot on sample clients tests the software. A pilot on the tester's own clients tests the job.

Put the decision date in the calendar of the person who signs. Not the project plan. The calendar.

Write down now what you will say if it fails. You will not have the nerve to decide that later, and you will not need to, because it will already be written.