Sanjeev Sharma.
Selected work

Six systems,
one quote.

Replacing legacy quoting macros with a rules engine — so that people joining through an acquisition could do insurance work without first learning a legacy system's language.

Organisation
Zurich Financial Services
Role
Lead Technical BA & Product Owner
Context
OnePath Life acquisition from ANZ
Outcome
Six operations systems reduced to one

The context

Zurich had acquired the OnePath Life business from ANZ. A large book of policies was moving across, and with it the people who would service it — into an operations environment that hadn't been built for that volume or that mix of products.

The problem

Quoting an endorsement on an existing policy ran on legacy macros. The macro scraped data out of the main policy administration system, and someone had to drive it by hand — which meant knowing the system rather than knowing the insurance. The screens spoke in system fields, not in the terms a life insurance professional actually uses.

It also broke down exactly where you'd least want it to. Complex scenarios fell outside what the macros could handle, and policies sitting on other legacy platforms weren't covered at all. Point solutions had been built to fill those gaps — which is how operations staff ended up moving between six systems to answer a single enquiry.

Because the macros scraped the policy admin system directly, they also surfaced data inconsistencies that a specialist team then had to investigate and resolve manually. End to end, a policy change took three to four days.

How I thought about it

The obvious framing was that the quoting tool was bad and needed replacing. Taken at face value, that produces a seventh system.

What changed my thinking was the acquisition. We were about to bring across a group of people with no history on these legacy platforms and no reason to learn their internal language. So the real constraint wasn't quoting speed — it was that the tools demanded system knowledge as a precondition for doing insurance work. That's a tolerable tax when your staff have been in the building for fifteen years. It's a serious one when you're onboarding a whole new population at once.

Which led to the question the design actually turned on: where should the translation between system language and business language live? If it lives in people's heads, every new joiner pays for it, and they pay for it forever. If it lives in a rules engine, you pay for it once.

What we built

I led a proof of concept for a Salesforce-based quoting portal, designed around that decision:

  • It pulled policy data from the underlying systems through APIs, rather than scraping the policy admin system the way the macros had.
  • It passed that data to a newly built pricing and rules engine, so pricing lived on one platform instead of being re-implemented inside each point solution.
  • The translation from system language into standard insurance terms happened inside the rules engine — so the product people actually used spoke the business's language.
  • The manual reconciliation loop disappeared, because the rules engine handled the inconsistencies the macros had been flagging for a specialist team to chase.
BEFORE AFTER Operations staff Sys 1 Sys 2 Sys 3 Sys 4 Sys 5 Sys 6 manual · each in its own system language Specialist team chases inconsistencies Operations staff insurance language Quoting portal translates + prices Rules engine pricing · product rules via API Same 6 source systems Specialist team — freed up
Before, staff queried six systems by hand, each in its own language, and a specialist team chased the inconsistencies that surfaced. After, one portal in insurance language sits in front of the same six systems — the rules engine absorbs the translation and the reconciliation work.

The outcome

6 → 1
Systems operations staff needed to handle an enquiry or customer request.
<15 min
Policy-change turnaround, down from three to four days of largely manual work.
One platform
Pricing and product rules centralised, laying the foundation to centralise those functions across the enterprise.
A team back
The specialists who had been reconciling data inconsistencies by hand were freed for higher-value work.

The result that mattered most to me wasn't the time saved. It was that staff arriving through the acquisition could work in insurance language from their first day, instead of spending months learning the internal dialect of systems that were on their way out anyway.

See the rest of the work