A list of analytics use cases is the easiest document to produce inside an insurer and the hardest to argue with. Every case on it points upward. Fraud detection saves money, churn modelling saves customers, pricing analytics wins business, and nothing on the page says where any of that would show up in the accounts. A list like that survives every review it meets, because nothing on it is specific enough to disagree with.
A European composite insurance group standing up a group-level analytics function was sent a proposal with one appendix page that did the opposite. Eight use-case archetypes were plotted across four blocks of the insurance chain and wired through to earnings by way of sixteen named financial drivers. Every link carried a direction of effect: a plus, a minus, or a mark meaning it runs both ways. Three links carry that third mark, and those three are why the page is still worth reading.
The challenge
The group was standing the function up across its operating companies, and the shortlist it wanted was one that would be submitted to the board rather than settled in a project committee. A board does not fund analytics. It funds a change in a number it already tracks, and it asks which number, by how much, and against what.
So the example page is built in two layers. The upper layer is the chain: underwriting and policy management, marketing and sales and customer service, claims processing, and support. Four blocks, marked on the page as indicative and with asset management explicitly excluded, which is a small piece of discipline worth noticing. A map that claims to cover everything is a map nobody can falsify.
Eight archetypes sit across those blocks: social trend detection to spot emerging needs early, churn and influence scoring, risk modelling for high-value commercial assets fed by real-time device data, claims behaviour prediction (fraud detection read from the customer side), connected home data used for pricing and loss prevention, next best action timed to where a customer has got to in life, process efficiency mining across the chain, and price sensitivity at the level of the individual customer.
The lower layer is where the argument lives. Earnings are fed by three branches, not two. Revenue carries six drivers: product volume, pricing, marketing effectiveness, distribution effectiveness, personnel, and investment income. Cost and expense carries four: operating cost, management expenses, claim cost, and income taxes. Risk carries six: operational risk, market risk, default risk, non-life risk, life risk, and law and legislation. Sixteen drivers, and six of them are risk.
Putting risk on the same footing as revenue and cost changes which cases look attractive. Most value trees treat risk as a compliance annex priced later by somebody else, which means a case that quietly raises operational risk while lowering operating cost reads as a clean win. The page also notes that risk ownership belongs to every department rather than to a risk function, with the key risks differing by department and technology carrying the key role in mitigating business disruption and systems failure. That is an operating-model statement hiding inside a finance diagram.
The approach
The grid as a whole is less instructive than a single line drawn across it, so take one case end to end. Price sensitivity is the one worth walking, and not because it is the biggest. Some customers are sensitive to price and some are more interested in features that go beyond the bare product. The case proposes estimating that sensitivity at the level of the individual customer, then matching the offer to it: value for money where price is the binding issue, extra service and convenience where it is not and the customer will pay for it. The stated benefit is a better read on when price is actually the objection during a renewal conversation, and therefore better retention.
Now follow the wiring. The case lands on the pricing driver, and pricing is one of the three links in the tree marked as running both ways. That mark is doing real work. If the model is right about a price-sensitive customer, the correct action is often to charge that customer less: a reduction in premium per policy against a gain in the probability of keeping the policy at all. The revenue effect is a mix question, and mix questions are empirical. The retention effect meanwhile reaches product volume, which is marked as a straight plus.
Read the two links together and the case stops being a slogan. It becomes a hypothesis with a shape: volume up, price per policy indeterminate, net effect decided by how the book splits between the two customer types. An insurer can hold that against its own renewal data inside a quarter.
The same reading applies to the other two contested links. Personnel sits on the revenue branch rather than the cost branch, so automating advice-giving work cuts a cost somewhere and may cut a revenue-producing relationship at the same time. Income taxes moves both ways for reasons no analytics case controls. A use case whose links are all plusses and minuses, with nothing marked as contested, has not been analysed. It has been sold.
What the map does not carry is the measurement. A direction on a link is a commitment to find out which way that link went, and that is a data engineering problem before it is a modelling one. The pricing decision has to be logged with the features it saw, the renewal outcome has to be joinable to that decision months later, and the operating-cost link needs the process events rather than a workshop estimate. Our Platform work starts at exactly this join, because a value tree with no lineage under it regenerates the same argument every planning cycle and never settles it.
The outcome
Nothing here was realised, and the honest statement of that matters more than the map.
This was an appendix inside a competitive proposal. The map is labelled as an example, and the authorisation page at the back of the same document was blank when it was sent. No case on that page was built for this group, no driver moved, and no financial benefit was measured. What was offered was a method for arguing about value, not evidence that the method had paid.
The one measured number anywhere near it belongs to somebody else. The process efficiency archetype came attached to a worked example from the support operation of a large financial institution, where mining the usage, click and call data across the end-to-end process cut process steps and, on the authoring firm's own account, took out roughly 25 percent of the cost, about EUR 3.3 million. That is a track record entry for a different organisation, not a forecast for this one, and the gap between the two is what the direction marks exist to defend.
Two things hold up. A use case argued without a named driver is unarguable, and unarguable proposals get funded on enthusiasm and killed at the first budget review. And the contested mark is the cheapest governance instrument in the document, because it forces the sponsor to name the measurement that will settle the question before the money is spent.
One thing would be done differently. A map drawn by hand in workshops ages from the day it is drawn, and the operating-cost link is the least defensible one to estimate in a room, because the events are already in the workflow logs. Process mining gives that link a value with a source attached, refreshed as often as anyone wants. The same argument reaches the current wave of cautious language-model pilots in document handling: a pilot that reads a claim form well is claiming a minus on operating cost, and until the work it removes is visible in the process data it is claiming it in a slide. Our Consult engagements start by asking which driver a proposed case says it moves, and how that movement would be seen.
The eight cases have aged unevenly. The discipline of marking three of the sixteen links as contested has not aged at all.