Contents
An assessor looks at a repair estimate for a front-end collision. Six lines, £600. The question in their head is simple, and it has nothing to do with artificial intelligence:
Have we seen this before, and what did it come to?
They already know the answer is somewhere in the system. Twelve years of closed cases, thousands of front-end collisions on that model, every one of them with a final cost and a parts list. The knowledge is sitting right there in the database and there has never been a practical way to ask it a question.
Similar Tasks is our answer to that, and the interesting part is how ordinary it is.
What it puts on the screen
When an assessor opens a task, a panel compares what they've entered against the cohort of closed cases that resemble it. Three things come back.
The items those jobs had that this one doesn't. For anything that's a list, a parts list, a work description, a multi-select, it shows what's missing and how many of the similar jobs included it. Wing trim on seven of ten. Bonnet on six. Radiator on four. Each one has an add button, and there's an add-all, so merging the difference into your own answer takes two clicks.
A check on your number. Your £600 against the range those jobs actually landed at, say £980 to £1,450, with a verdict attached. Below the typical range prompts a review for missed parts. Above it prompts a check for over-quoting. Inside it says so and gets out of the way.
A check on your classification. Where you've picked a single value from a list, severity, damage category, the panel shows what the similar cases were classified as, and speaks up when your choice differs from the cohort.
None of that is a summary an assessor has to read and interpret. It's a difference they can act on.
Somebody has to say what "similar" means
Here's the part I'd expect people to skip past, and it's the whole design.
Similarity is configured by hand. An administrator builds a profile for a task type and chooses which questions define resemblance, and for each one they set how it should be compared:
- Exact match on a string or an integer, for things like model code where close is no use to anyone
- Numeric range, scoring by how far apart two values are against a tolerance you set
- Numeric percentage, the same idea where the tolerance should scale with the size of the number
- Date range, decaying over a number of days
- Prefix, matching the first N characters, which is how postcode districts and reference schemes work
- Token overlap, comparing two sets by how much they share, for free text and multi-value fields
- Option match, for picklists
Each field carries a weight, so vehicle model can count for more than incident date. Any field can be marked required, which drops a candidate outright when it doesn't match. And each one declares what to do about missing data: skip it, penalise it by a configurable amount, or insist the field is present at all.
Then the pool itself gets bounded. Restrict candidates by status, by case relationship, by how far back to look. Drop anything below a minimum combined score. Take the top ten.
That's it. Add up weighted field scores, rank, cut.
Why there's no model in the retrieval
Machine-learned similarity scoring was on the list of things we deliberately left out of the first version, and I want to be straight about why, because it would have been the more impressive engineering.
An assessor who sees a job in the list and thinks "that's nothing like mine" has to be able to ask why it's there. With weighted field matching, the answer exists and it's specific: it scored 0.82, model matched exactly, damage area matched, incident date was four months out and cost you a fraction. You can read the profile and see the reasoning. When the answer is wrong, you change a weight or a tolerance and it's different immediately.
A learned similarity function gives you a better ranking and takes that conversation away. The assessor gets "the model thinks these are similar", the administrator has no dial to turn, and the first time it surfaces something daft the whole panel loses credibility. In an operation where people are already sceptical of software telling them their business, credibility is the scarce resource.
There's also a practical argument. Configured matching works from the first day a profile exists. Learned matching needs training data, evaluation, retraining, and a plan for what happens when it drifts. We can add it later, per profile, where the evidence says it's worth it. Starting there would have bought a worse product several months later.
Your own closed cases, and only those
The cohort comes from one place: cases closed on that installation, by that firm.
This matters more than it sounds. A parts pattern from a bodyshop network in another region describes their labour rates, their supplier relationships and their engineers' habits. The reason the panel is worth reading is that it describes how work actually behaves on your book, with your people and your suppliers.
So there's no shared corpus across customers, and nothing gets pooled centrally to make a better general model. Every install reasons about itself. That's also the answer to the question a procurement team asks about where the data goes, which is a conversation we'd rather have with a short answer.
The same engine, a different profile
Nothing in the design knows what a vehicle is.
The claims profile matches on model, damage area, severity and incident date, and recommends against parts lists and repair cost. A rating appeals profile on the same engine matches on property type, rateable value band and appeal grounds, and recommends against the grounds cited and the reduction sought. An administrator configures the second one without a line of code being written, because the engine only ever sees typed answers, comparison modes and weights.
That generality was a constraint we imposed early. Claims is the deepest vertical we work in, and it's one of seven, so a feature that only works for motor damage is a feature we'd be rebuilding for property in a year.
What happens when it's wrong
Assessors can flag a match as unhelpful, and the flags are recorded against the profile version that produced them. Change the profile and the counter starts again, because feedback about a configuration you've since changed tells you nothing.
Those signals do two jobs. They show an administrator which profiles are producing noise, and they give us evidence about where learned scoring would genuinely beat configured scoring. When a profile keeps getting flagged despite tuning, that's the case for a model, made with data instead of enthusiasm.
The general point
Plenty of what gets sold as AI in operations software is retrieval with a language model bolted on the front. The retrieval is doing the work, and it's the part worth getting right.
Find the ten closed cases most like this one. Show the difference. Let the person decide. A firm with twelve years of history already owns the answer to most of the questions its staff ask every day, and the useful engineering is in making that history reachable at the moment somebody needs it.
Further reading:
- Claims outcome prediction: what gets built on top of the cohort
- UK data sovereignty: where the data lives and stays
- AI resilience: provider-agnostic architecture around the models
- Why we took the percentages off the claims card: presenting this to a busy assessor