Can someone pull the quotes for last quarter?
Your pricing analyst wants to know how conversion differs by postcode band, whether a competitor's price change affected one channel, and how claims experience looks for customers quoted at a particular factor level. To start, they need every quote with its answers, the rating factors used, the price, whether it bound, and later whether a claim was made.
They ask engineering for an export. It arrives a week later as a CSV from the policy system, without the rating factors because those are not stored there, and without the channel because that is in web analytics. The analyst spends days joining files, and then the question has moved on.
Why quote data is hard to reach
Quote data is created in the quote journey and rating service, stored partly in the policy system, and outcomes arrive later from payments and claims.
- The policy system stores quotes but not always every answer or rating factor.
- Declined and referred quotes may not be stored at all.
- Channel and campaign information sits in analytics.
- Claims are in another system or with an administrator.
- Pricing does not have direct, safe access to any of it.
Pricing in the dark
Without quote data, pricing decisions rely on bound policies only, which hides the customers who did not buy. Changes cannot be evaluated properly. Every analysis depends on engineering time. Capacity providers ask for evidence behind pricing decisions, and it takes weeks to produce. The pricing team spends its time preparing data rather than analysing it.
A quote data store for pricing
What we build captures quote data once, in a form pricing can use directly.
- Each quote, including declined and referred ones, is recorded at the moment of rating with the answers, enrichment data, factors, rating version and price.
- Channel, partner and campaign details are attached from the quote journey.
- Outcomes are joined as they happen: bound, lapsed, cancelled, renewed.
- Claims are joined to policies from your claims system or administrator data.
- Personal data is separated or removed in the analysis tables, so pricing sees what it needs without direct identifiers.
- The data is available in a warehouse such as BigQuery or Snowflake, or a database your team can query, and connected to the tools pricing already uses, such as Python, R or Excel.
- Standard views are prepared for common questions, such as conversion by factor band or channel.
| Data | Captured from | Available as |
|---|---|---|
| Answers and enrichment data | Quote journey and rating service | Quote table |
| Rating factors and version | Rating service | Quote factors table |
| Channel and campaign | Quote journey | Quote table |
| Bind, cancellation, renewal | Policy system events | Outcomes table |
| Claims | Claims system or administrator | Claims table joined to policy |
Analysis without waiting
Declined and referred quotes matter more than they seem. If a rule declines a band of risks that competitors happily write, you only see it when declined quotes are recorded with their answers. The same goes for customers who were quoted and walked away at the price page: without them, the data only ever shows people who were willing to pay what you asked.
The pricing analyst opens their notebook or spreadsheet, queries last quarter's quotes by factor band and channel, and works on the answer without waiting for an export. Rate changes are evaluated against real quote behaviour. Evidence for capacity providers is a query, not a project. Engineering is not involved.
Does your pricing team have this problem?
- Pricing asks engineering for quote exports.
- Rating factors are not stored with quotes.
- Declined and referred quotes are missing from the data.
- Channel data sits in analytics, separate from quotes.
- Joining quotes to claims takes days.