Needs-based advisory engine

The context

An established insurer selling regulated products through a field advisor force: the sale happens at the customer's kitchen table, not in a branch. Regulation requires a genuine needs analysis before any recommendation, so every session carried compliance exposure alongside sales pressure. Advisors worked in areas where connectivity was never guaranteed, sessions ran about an hour on paper forms and manual math, and compliance teams could only review what advisors happened to write down.

Why normal software was not enough

Form software could digitize the paperwork, but the value sat in the judgment: which needs matter, which products fit, and how to show the customer honest numbers. That logic lived in advisors' heads, applied one improvised session at a time. Automating it meant a decision engine that captures a customer's situation, applies suitability rules, maps products and generates the benefit illustration on the spot, with its reasoning attached, on a device that cannot count on a connection.

The problem

Regulated insurance sales require a genuine needs analysis before a recommendation, and in the field that meant an hour of paper forms, manual math and compliance risk whenever an advisor improvised. Connectivity at the kitchen table was never guaranteed.

What we built

We encoded the advisory logic into a decision engine: structured needs capture, suitability rules, product mapping and benefit illustration generated on the spot, all running offline on the advisor’s device. Every recommendation carried its reasoning, so compliance reviews read the logic instead of reconstructing it.

What production made hard

• Offline was the baseline, not the fallback: needs capture, suitability rules and illustration math all had to run on the advisor's device, with sessions syncing intact whenever a connection appeared.
• Suitability rules read cleanly in a compliance manual, then meet real households: variable incomes, dependents that fit no category, needs that conflict. Every combination had to resolve to a defensible recommendation, not a guess.
• Benefit illustrations are regulated documents, so the generated numbers had to match the insurer's official product math exactly, computed on-device without a server to lean on.
• Traceability had to be a data structure, not a log file: each recommendation stored the inputs, rule versions and reasoning that produced it, so compliance review meant reading the logic, not reconstructing it.
• Product and rule changes had to propagate to devices that were rarely online, without an advisor unknowingly running a stale ruleset.

What a similar project needs

• The rules, written down or extractable: suitability logic, product specifications and the official illustration math. Encoding them is quick; getting senior people to state the tacit rules is the slow part.
• A validation set of past advisory sessions with known-good outcomes, so the engine is proven against history before it faces a customer.
• Compliance in the room from the start, not at sign-off: the audit trail is a design decision, and retrofitting traceability costs far more than building it in.
• A timeline shaped desk-first, field-second: prove the decision logic against historical cases, then harden offline sync and the device experience. Teams usually underestimate the second half.
• Risks to plan for: rules that turn out to be folklore rather than policy, product math that lives only inside a legacy illustration tool, and update paths to devices that are rarely online.