A self service journey for changing the agent attached to an insurance policy, live across almost every US state at about eight thousand submissions a month.
A large insurer in the United States writes policies in almost every state, a great deal of that business sold through agents rather than directly. Every policy has one agent attached to it, and those agents are small businesses. That agent earns on the policy for as long as they stay attached, and the customer can move to a different agent at any point. When they do, one small business stops earning on that policy and another starts. The commercial rules are confidential. The shape is what matters here, and it is why this is not an administrative preference.
I owned the facilitation platform underneath both of them. It is an operations interface and a set of APIs, not a system of record. It runs the validations that determine whether a change is legitimate and writes the result into the policy administration system that holds the record. Compensation is calculated from its own record of those moves, which is why that record has to be complete as well as correct.
The agent channel was asynchronous by design. Requests queued, a batch validated them twice a day, and a confirmation came back about twelve hours later. Against a three day service level that was comfortable, and the delivery plan was to reuse the pattern for the customer portal. It was a non functional requirement that had been inherited rather than decided.
An agent filing on behalf of a client is at work, and a queue is acceptable to them. A customer changing something on their own policy will not hold for twelve hours to find out whether it worked, and over a weekend twelve hours becomes two days. I took it to leadership and the design changed to synchronous.
Synchronous changed when the customer received an answer. It did not change where the answer was produced. The validation set stayed exactly where it had always sat, at submission, which is the last step of a ten step journey. The customer selected a policy, selected an incoming agent, reviewed the request and submitted it. Only then did they learn that the agent currently attached to the policy could not be changed at all, or that the agent they had chosen held no valid licence in the state governing that policy.
Every rule executed correctly. Every rule executed after the customer had already made every decision the journey asked of them.
customers a month completed the full journey and were declined at the final step.
Twenty six percent of submissions failed validation. Live from the end of November 2025, one state for ten days as a controlled rollout, then all but two states from the first of December.
Product manager for the facilitation platform, which owns the validation logic and the write to the policy record. The portal interface belonged to another team. So did the integration layer between us. What was mine was the argument: the case for synchronous over batch, the diagnosis of why customers were failing, and the redesigned journey that came out of it. That then had to be specified by me and delivered by three teams that did not report to me, across an integration contract I did not control.
With the capability live and failing, I ran a funnel analysis across the whole journey rather than across submissions alone. The twenty six percent everyone was quoting has submissions as its denominator, so by construction it can only see customers who reached the submit step. Every customer who abandoned before that point sat outside the measure entirely.
A representative month before the remap. 10,589 customers started an agent change and 6,014 completed one. Of the 4,575 who did not, these were the two largest groups, and the larger of them was the one nobody was measuring.
The second finding is what reframed the problem for leadership. A failed submission is not a neutral event costing the customer thirty seconds. It generates duplicate records on my platform and manual handling at the contact centre, and it leaves a customer with less confidence in the channel than before they used it.
The redesign changed no validation rule. It changed the point in the journey at which each rule is applied, so that a customer meets a constraint at the moment of the choice it governs rather than at the end.
fewer customers a month are rejected at the final step.
At roughly 8,000 submissions a month, 26% was more than 2,000 declined at the last step. Under 2% is fewer than 160.
The failures were not edge cases or system errors. They were choices the customer was permitted to make and should never have been offered.
Remove the ability to select an ineligible option and the failure it would have caused cannot occur.
Read the shapes rather than the endpoints. Before the remap the journey was almost lossless for two steps and then broke three times running, worst of all at the very end. After, the losses bunch up early, where a customer has spent two clicks rather than ten, and the tail runs close to flat.
About sixteen percent of customers who start a change still do not complete one. That will be some mix of abandoned sessions, timeouts and connection failures, and I hadn't instrumented the journey finely enough to separate them. I can tell you what the funnel did. I can't yet tell you why every customer left it.
Where a constraint is enforced is a product decision. It only looks like an engineering detail because engineering is where it gets implemented.
Not one thing about the eligibility logic changed between the version that failed a quarter of the time and the version that fails under two percent. Same rules, same rejections in principle. What changed is that a customer now meets each rule while the choice is still open.
I pushed back hard on the asynchronous design and I was right to. Twelve hours isn't real time and no customer will accept it. But having won that argument I treated the resulting design as sound, and the sequencing flaw sat inside it, untouched.
The programme was fast tracked and I didn't have room to run research ahead of the build. I made the latency call on judgement and it happened to be right, but I had no evidence about how a customer would actually move through the journey. I instrument a journey before it ships now. And when discovery gets squeezed out of a plan, I state out loud which decisions are therefore being made on assumption, so the risk sits on the record rather than in my head.
For four months the number in every status report was the submission failure rate. It was a real number measuring a real thing, and it was incapable, by construction, of seeing the 2,271 customers a month who abandoned at agent selection, because they never reached the step it measures. Any rate whose denominator is people who already got most of the way through will flatter you, because the customers it hurt worst have been removed from it.
So I now ask one question of any funnel metric before letting it become the headline. Who has already fallen out of this denominator, and would I still be comfortable with the number if I put them back in?