A spreadsheet from pricing, a ticket for engineering
Your pricing analyst works out a change: a new factor for a postcode band, a revised base rate, a different loading for a claims history band. They send a spreadsheet to engineering with the new values. It joins the sprint backlog behind product work.
An engineer copies the values into the code or a configuration file, writes a test, and ships it. Two weeks later a quote looks wrong, and it turns out one value was pasted into the wrong row. Pricing cannot easily check what is live, because the live rates are in the code.
Why rating ended up in code
At launch, rating was built quickly as part of the quote service. It was one product with a few factors. Since then the product has grown and pricing has become a team, but the rating is still where it started.
- Rating tables live in code or configuration files only engineers change.
- Changes have no effective date, so timing depends on the release.
- There is no easy way to test a new table against past quotes before it goes live.
- The record of which rates priced a given quote is incomplete.
- Pricing and engineering use different formats for the same table.
Slow changes and quiet errors
Pricing moves at the speed of the engineering backlog, which is too slow when a segment is performing badly. Copying values introduces errors that are not spotted until quotes look odd or claims come in. When a capacity provider or auditor asks what rates applied to a policy, the answer means reading the code history. Engineers resent being a data entry step.
What your rates should be is your pricing team's and capacity provider's business. The build is about getting their decisions live accurately.
A rating service your pricing team can drive
What we build separates the rating logic, which engineers own, from the rating tables, which pricing owns.
- The rating calculation is moved into its own service with a clear input and output, so the quote journey calls it rather than calculating inline.
- Factors and tables are held as data, with a version and an effective date.
- The pricing team edit or upload tables in a controlled screen that validates shape and ranges.
- Before release, a new version is run against a sample of past quotes, and pricing see the change in premium by segment.
- A second person approves, and the version is scheduled for its effective date.
- Every quote stores the rating version used, so any policy's price can be explained later.
- Engineers change the rating logic only when the structure of the calculation changes, not the numbers.
| Change | Who makes it | How it goes live |
|---|---|---|
| New factor values | Pricing | Upload, test, approve, schedule |
| New rating table for existing factor | Pricing | Upload, test, approve, schedule |
| New factor in the calculation | Engineering with pricing | Code change, then pricing adds values |
| Emergency rate change | Pricing with approval | Immediate effective date, same tests |
A rate change after the rebuild
The pricing analyst uploads a new table, runs it against recent quotes, reviews the impact by segment, and asks for approval. It goes live at midnight on the chosen date. Engineering is not involved. When someone asks a month later why a quote was priced as it was, the quote shows the rating version and the factors applied.
Is your rating like this?
- Rate changes are engineering tickets.
- Pricing sends spreadsheets to be copied into code.
- Changes cannot be tested against past quotes.
- You cannot easily show which rates priced a given policy.
- Rate changes go live when the release goes out, not on a planned date.