Contents
There is a temptation, in claims-AI, to make the AI do the impressive thing: agree the value, set the offer, close the case. It demos beautifully. It looks like the future. It also breaks every Consumer Duty principle the FCA has written into the rulebook in the last three years.
So we don't do it. Switchboard, the AI agents layer that runs at Laird Assessors on real total-loss conversations, never agrees a value. Never sets an offer. Never negotiates. Every value the AI presents is a value a named engineer set. A customer who disagrees goes back to a person. Every decision lives in the case file with a human attribution, time-stamped, exportable.
This is not because we're cautious. It's because we've thought about what total-loss actually is, and what the AI is for.
The conversation that breaks the audit trail
A total-loss valuation is not an information request. It is a regulated decision with a real customer impact and a named human accountable for getting it right. When a customer hangs up, the value they have agreed to becomes the basis of a settlement. If the customer later thinks they were pressured, misled, or shown only the evidence that supported the offer, they have a complaint. That complaint can land at the FOS. The FOS will ask for the file.
What is in the file matters.
If the file shows the customer agreed to a value the AI presented, with the same comparable evidence pack a human handler would have used, with both sides of the market shown, and the AI escalated cleanly when the customer pushed back, the file holds up.
If the file shows the AI generated a value, negotiated downward, or selectively withheld comps that exceeded the engineer's number, the file does not hold up. There is no human owner. There is no anti-detriment evidence. There is no defensible record.
So the question isn't "can we let the AI agree the value?" It's "who pays when it goes wrong?"
The design we made instead
The flow is in our HITL design, but the short version is four steps:
1. Engineer sets the value. Before the AI calls the customer, a named engineer assesses the vehicle and enters the total-loss valuation as a structured field on the case. Comparable market evidence goes on the case with it. The case is marked ready for customer contact. The engineer's name is now on the value, in the file, with a timestamp.
2. Switchboard presents. The AI calls the customer. It explains the assessment, presents the engineer's value, and walks through the comparable market evidence. It does not improvise the value. It cannot.
3. Customer responds. The AI writes the customer's answer to fields on the case. Agreement is logged. Disagreement is logged. The AI does not push back, haggle, or try to convince. It listens, records, and either carries on or puts the caller through to your team.
4. Disputes go back to a person. Continued disagreement is not a problem the AI is allowed to solve. The disagreement sits on the case for the engineer who set the value, and a customer who wants a person now gets put through to your team. The dispute is resolved human-to-human, with the call's summary and outcome as the record.
That's the loop. The AI runs the conversation. The engineer owns the decision. The case file owns the record.
Symmetric disclosure: the anti-detriment principle
The most important design decision is invisible in a demo. When the AI shares comparable market evidence (typically valuations from real-time market data feeds), it shares them in both directions.
Comps below the engineer's value get shown. Comps above the engineer's value get shown. The customer sees the full distribution of comparable valuations, not the half that supports the offer. The AI does not curate, summarise selectively, or "lead" the customer toward agreement.
This sounds like a small thing. It's the whole game.
A claims-AI that withholds comps above the offer, whether by design, by accident, or because someone wrote the prompt that way, is doing selective disclosure. Selective disclosure of comparable evidence in a regulated settlement conversation is, on the FCA's own framing, a Consumer Duty failure. It's also a fair-treatment failure under any reasonable reading of PRIN 2A. And it shows up cleanly in the audit log, because a transcript will tell the FOS exactly which comps the AI shared.
We made symmetric disclosure a standing rule for the agent. The customer always sees both sides. The AI does not decide which evidence to surface.
What the AI actually does
Once you take "agree the value" and "negotiate the offer" off the AI's job list, what's left? A lot, actually:
- Looks up the case: by registration, phone, postcode, name.
- Verifies identity: the caller must match a second, different detail before the AI reads anything. The AI cannot share case detail with someone who hasn't verified.
- Presents the value: with the engineer's name, the assessment date, and the comparable evidence.
- Captures the response: as structured fields on the case, with a summary and outcome of the call kept in Switchboard.
- Drafts email replies: when a customer writes in, the AI drafts the reply. None of which auto-send. All of which land in a human approval queue before going out.
- Puts the caller through: when the customer asks for a person, or when its rules say to. A straight transfer to your team.
This is what tool-using AI looks like in regulated work. The intelligence is in the connection between conversation and case file, not in the decision-making.
When the AI puts the call through to a person
Switchboard puts the caller through to your team when they ask ("I want to speak to a person"), or when the agent's rules say a call like this should go to someone. It's a straight transfer to the number set for that agent.
The person who picks up gets no briefing on screen. The case already holds whatever the AI wrote to it, and the call's summary and outcome land in Switchboard when it ends.
The audit trail
Every human action lives in Timeline, our audit logger. Actor, timestamp, resource, outcome, severity. Filterable. Exportable. Per case. Per second. Each change the AI makes arrives through SwiftCase's API and is logged on the case as an API request, showing who sent it and what.
This means there is no "the AI decided" entry. Every value the AI presented is one a named engineer set. Every email it drafted was approved by a named handler. Every workflow change was made by a named manager. SMCR maps cleanly onto Timeline entries, the personal accountability framework the FCA expects, mapped to actions, by design.
When the FOS asks for the file, there's a clear record to hand over: the call recording, attributed actions, decisions with human owners, the comparable evidence the customer was shown. The audit trail is a side-effect of normal operation, not a separate compliance project.
Why this is also good for the customer
The temptation, when reading this, is to see HITL as the boring, cautious, slower option. That's not how customers experience it.
A customer talking to Switchboard during a total-loss conversation hears the engineer's value and both sides of the market evidence, gets their questions answered, and, if they disagree, gets put through to your team. No haggling. No phone-tree. No queue of handlers giving them slightly different versions of the same number.
The conversation is calmer because nobody is trying to convince anyone. It's faster because the AI reads the value and the evidence straight off the case. It's fairer because the AI doesn't selectively withhold comps to defend the offer.
If the customer agrees, the case closes cleanly. If they disagree, the disagreement is on the case for the engineer. Either path produces a defensible outcome.
What this isn't
This isn't a chatbot with extra steps. Switchboard is tool-using AI: it makes real API calls during conversations, looking up cases, verifying identity, updating fields, creating new cases. The "extra steps" are the design constraints that make those tools safe in regulated work.
This isn't slow either. The conversation runs at human conversational pace. The AI has no decision overhead because the decision was made before the call started. Latency lives in speech-to-text and text-to-speech, not in deliberation.
And this isn't theoretical. It's the production behaviour at Laird Assessors, today, on real total-loss conversations. Out-of-hours intake, outbound bodyshop chasing, total-loss valuation chats. The exact engineer-sets-value flow described above. We didn't bolt accountability onto an existing AI feature; we designed the AI feature around the accountability the regulator expects.
The pilot question
Insurers and assessors who want to see this in their own operation can start with a 30-day pilot. Pick the noisiest conversation in your claims operation: overflow FNOL, out-of-hours intake, the bodyshop chase queue, or routine TL valuations. Measure against your existing SLA and cost-per-claim. No platform migration. No long lock-in.
If it works, if the audit trail tightens, if the engineers free up, if the customers come away calmer, you scale into more. If it doesn't, you've spent a month.
What you won't do, in the pilot or after it, is hand the AI the decision. Because that was never the problem worth solving.
Further reading:
- Human-in-the-loop AI for claims: the design philosophy, end-to-end
- Total-loss settlement automation: the operational walkthrough
- Timeline: the audit logger: the per-case, per-agent, per-second evidence trail
- Specialist motor insurer case study: insurer-scale operations on the platform
- Laird Assessors year in review: production proof