Financial Services Platform
Rebuilds Quote Generation Around Branching Workflows and API-Connected Decision Logic

Quote generation in this category depends on more than a single form submission. Coverage combinations, branching logic, occupation mapping, and user guidance all affect the path from initial enquiry to a usable comparison outcome.

The core complexity was structural. Unlike a standard web form where every user sees the same fields, this quote journey required the form itself to change based on what the user had already answered. A particular occupation classification might unlock additional coverage questions. A specific sum insured choice might restrict which providers could be queried. The structure of the quote request — not just its values — was conditional. This meant simple form validation logic was insufficient; the platform needed a proper workflow engine that could reshape the question flow dynamically without requiring code changes every time business rules evolved.

Compounding this was the incompatibility between provider APIs. Each coverage provider returned quote responses in a different schema — different field names, different premium structures, different exclusion formats. Presenting these responses side by side for comparison was impossible without first normalising them into a consistent shape. The existing process handled this through manual adviser interpretation, which introduced inconsistency and made it impossible to scale.

The platform also needed to support two fundamentally different user types: members of the public accessing a self-service quote portal, and internal staff using the same underlying engine through an adviser workflow. Both pathways needed to feed the same quote logic and produce the same structured outputs, but with different levels of guidance, different interface affordances, and different handling of edge cases.

We designed a quote engine that supports multiple user journeys, captures structured inputs, and maps those answers into API-ready request logic.

The workflow engine sits at the centre of the architecture and handles branching without code changes. Business rules — which questions are shown, which are skipped, which coverage combinations are valid — are managed as configuration rather than hardcoded logic. This means the business can adjust the quote journey as products or provider requirements change, without a development cycle for each update.

The response normalisation layer was one of the more technically deliberate decisions in the design. Raw API responses from coverage providers could not be used directly — each provider returned data in its own schema, with different field structures, different premium breakdowns, and different ways of expressing exclusions or loading conditions. We built a normalisation layer that receives each raw provider response and maps it into a single consistent schema before it touches any downstream system. This means whether a quote comes from Provider A or Provider D, the internal teams and adviser tools see identical data structures. Comparisons are like-for-like. Downstream reporting is consistent. The business is not dependent on any single provider’s API format remaining stable.

Technology Stack

• Form engine: Structured question flows capture user answers in a way that can support both guided and direct quote journeys, with the form structure itself adapting to prior answers.
• Quote API: Coverage requests are assembled into API-ready payloads so quote responses can be generated programmatically across multiple providers.
• Workflow engine: Branching logic, occupation handling, and dependent question flows are managed as configuration — not code — allowing rule changes without deployments.
• Operational platform: The same engine supports public quote capture and internal adviser workflows, with separate interface layers over the same structured logic.
• Response normalisation: Returned quote data from each provider is mapped into a consistent schema before reaching any downstream system — enabling comparable outputs regardless of source.

Quote generation that previously depended on adviser interpretation and manual data reconciliation now runs through a structured, auditable workflow. The platform handles both public and internal journeys through the same underlying engine, with each pathway producing consistently structured outputs that the business can act on immediately.

The normalisation benefit has had the clearest downstream impact. Internal teams working with quote data no longer need to account for which provider generated a particular response — the field names are the same, the premium structure is the same, the exclusion format is the same. Comparisons that previously required manual reconciliation are now direct. Reporting that previously had to accommodate multiple schemas can now run against a single consistent structure. As the platform adds new coverage providers, the normalisation layer absorbs the schema differences, and nothing downstream needs to change.

The workflow engine’s configuration-driven approach has also shortened the cycle time for product changes. When coverage rules or question flows need updating, the business makes a configuration change rather than raising a development ticket. The quote journey stays current without the overhead of a code release for each adjustment.