The nine hours I chose not to automate

This insurer runs two policy estates side by side. A current platform, and a legacy one being migrated onto it, each holding its own records for a book of business written across almost every US state. Agents account for a large share of it. Every policy names one agent, and that agent is a small business whose income depends on the name staying where it is.

So the field is not an attribute sitting on a policy. It is the thing an agency earns on.

Every one of those changes had to be found and brought back in, and that reconciliation fell to the enterprise operations team. Every fortnight they extracted agent changes from my platform and the five others into a single document, reconciled them, then re keyed the missing ones by hand so that what compensation could read was complete.

Volume stayed flat and the backlog kept growing anyway. The process was the constraint, not the demand.

None of that arrived as a complaint, and none of it arrived as a ticket. The operations team were sending my platform twenty to twenty five inquiries a day, every one a variation on the same question. Has this policy already been changed here, or do I need to enter it?

Nobody was counting them. There was no ticket queue and no owner for the volume, because as far as the operations team were concerned the asking was part of the work. I could see it only because the inquiries landed on my platform, so rather than estimate I tallied them myself across two fortnightly cycles.

Product manager for the facilitation platform. The operations team are my users. The five other systems belong to other product managers and I had no authority over any of their roadmaps. It was not on a roadmap, it had no sponsor, and no one had asked for it. I picked it up because those 22 people were my users, and the fact that they'd never framed their situation as a problem didn't stop it being one.

I didn't take this to anyone as an idea. I ran it as a proof of concept first: map the systems, their integrations and their write paths, and measure what the operations work was actually consuming. What came out of it was an architecture diagram of how the estate behaved as opposed to how everyone assumed it behaved. Only once I could state the problem precisely did I put it in front of engineering, and only once we had a solution did it go on a roadmap.

That same unpicking produced the best decision in the project. Examined individually, three of the five systems were doing the same thing. The other two were duplicating my own platform, and existed only because customer support was making agent changes by hand, one through a web channel and one through phone and chat.

1. A single licensing standard. I specified one standard and worked with the other estate's product manager to get it applied consistently, so no agent move on either estate completes without the same validation. I had no authority to put anything on their roadmap, so I framed it as a regulatory exposure scaled to the volume of policies involved. That is an argument no product manager can decline on the grounds of priorities.
2. One write path for agent changes. A hard business rule now prevents the other systems from altering the agent field on a policy. They carry on handling everything else they always did, endorsements and renewals included. One field is constrained, through one route. The legacy estate keeps its own utilities untouched, since it is being migrated onto the current platform anyway and rebuilding controls on a system you are retiring is wasted effort.
3. Two systems retired. The two redundant paths came out, and both support channels, web and phone, now route their agent changes through my platform.
4. A proper interface for the human work. The judgement based categories were being re keyed out of a spreadsheet. They now have reason codes, workflow notes and process logs, and the platform writes directly to the current estate instead of acting as a staging area somebody types into twice.
5. Deliberate asynchrony. The write runs as a batch rather than synchronously. That is a design choice, not a limitation. These are judgement calls entered by hand, and the window between entry and execution is exactly what allows someone to correct their own input before it reaches the policy record.

Volume did not fall. These moves still run at an average of around 979 a week and the backlog still grows, because the backlog is not a defect. It is the product of business events: agents leaving, agents behaving badly, customers requesting changes that get denied. What changed is where a move originates. It is entered in the platform in the first place now, rather than made elsewhere and chased afterwards, so reconciliation collapses into ordinary data entry. The work became tractable instead of compounding.

The nine hours that remain are genuine judgement. Corrections driven by business rules that keep changing, affecting compensation in ways you cannot automate without stripping out the review those rules exist to require. That was a deliberate stopping point rather than a wall I hit.