Other applications

A1. Early third-party intervention alerts

The sooner a not-at-fault third party is contacted and offered a replacement vehicle and repair, the less likely the claim is to go to credit hire and a claimant-chosen garage. Industry figures put the difference at several thousand pounds per claim, and late notification is the main cause. Postbot already reads every new incident notification. This idea adds a rule set that spots a likely third-party vehicle claim, starts a clock, alerts the handler, and prepares One Claim's intervention letter from its template.

Rules

Alert timing, escalation if no contact within set hours, template selection, reporting on time to contact

Inference

Reading third-party details, damage and circumstances from the driver's or broker's free-text notification

Needs

Phase 1 Postbot; One Claim's intervention process and templates

A2. Credit hire checker

Hire agreements, rate evidence and invoices arrive as attachments. Claude reads them into facts: hire company, start and end dates, vehicle group, daily rate, extras, whether the hire falls under the General Terms of Agreement. Rules then compare the daily rate with One Claim's rate tables, hire length with repair time and engineer dates, the vehicle group with the claimant's own vehicle, and flag the gaps. The handler gets a one-page challenge summary with page references.

Rules

Rate comparison, duration against repair dates, vehicle-group matching, arithmetic checks on invoices

Inference

Reading varied hire documents into fixed fields

Needs

Rate tables One Claim is permitted to use; engineer dates from the claim file

A3. Repair estimate, engineer report and lead-time tracking

Estimates and engineer reports are read into line items: labour hours and rates, paint, parts with prices, calibration of driver assistance systems, total, and repair or total loss decision. Rules check labour rates against agreed rates, arithmetic, parts priced above set levels, and repeated items. Separately, the dates in each document build a repair timeline, flagging claims where the vehicle has been waiting longer than a set number of days, since repair delays drive hire costs.

We would not build our own damage-from-photos estimator. Specialist image tools already do this well; if One Claim wants that capability, the sensible route is to connect to a specialist provider and have Postbot pass photos to it and read the result back.

Rules

Rate and arithmetic checks, thresholds, timeline and delay alerts

Inference

Reading estimate layouts that vary by repairer and estimating system

Needs

Agreed labour rates and thresholds; sample estimates to test layouts

A4. Total loss valuation consistency

Following the regulator's findings on total loss settlements, every total loss offer can be checked by rule: valuation sources recorded, settlement at or above the guide values, any deduction for pre-existing damage backed by evidence on the file, and salvage category recorded. This is useful as evidence of fair treatment for fleet own-damage claims, if One Claim handles them.

Rules

All checks

Inference

Reading valuation reports and engineer notes into fields

Needs

Confirmation that One Claim settles own-damage total losses

A5. Liability evidence pack

Fleet managers widely believe their drivers are wrongly blamed, and brokers report insurers relying more on video and data for liability. For each disputed claim, the tool assembles everything received (driver statement, third-party account, photos, police information, witness statements) into a dated chronology, and lists where the accounts agree and differ, quoting each. A rule table of common accident types (rear-end, lane change, junction emergence, reversing, car park) proposes the usual starting position, and the handler makes the liability decision.

Rules

Chronology ordering, missing-evidence checklist, accident-type table, chasers for missing items

Inference

Reading statements into facts (positions, directions, speeds, sequence) and comparing two free-text accounts

Needs

One Claim's liability guidance; handler sign-off always required

A6. Telematics and dashcam evidence retrieval

Many fleet vehicles carry telematics and cameras, but the evidence is often lost because footage is overwritten before anyone asks for it. At first notification, a rule identifies the client's telematics provider and immediately requests the event data and footage for the vehicle, time and place of the incident, either by email template or through the provider's interface where one exists. Speed, braking and location data are read as numbers and compared with the accounts; the handler watches the footage, which the tool has already located by timestamp.

This is ambitious because it depends on each fleet client's provider and their consent, but it is one of the few ideas that could change liability outcomes, not just speed up handling. It would also be a service Capulus and the broker partners could offer fleet clients.

Rules

Provider lookup, request timing, comparison of telematics data with stated speeds and times

Inference

Little; mostly structured data. We would not rely on automated analysis of video for liability.

Needs

List of client telematics providers; client consent; provider access, one provider at a time

A7. Injury claims outside the portal

Larger injury claims carry the biggest individual costs. Extending the medical report reader to medical records, rehabilitation reports and schedules of loss would give handlers a dated medical chronology with citations, a check that every figure in a schedule of loss adds up and is supported by a document on file, and prompts where rehabilitation should be considered early under the industry's Rehabilitation Code.

Rules

Arithmetic, supporting-document checks, rehabilitation prompts, deadlines

Inference

Reading medical records and reports into a chronology

Needs

Phase 2 in place; data protection assessment extended to wider health records

A8. Offers, deadlines and court timetable

Postbot already recognises court documents and offers. This idea adds a deadline diary: settlement offers and their acceptance periods, portal deadlines, court directions and hearing dates. Each is read from the document, calculated by rule, entered in a diary, and escalated as it approaches. Missed litigation deadlines are among the most expensive errors a claims handler can make.

Rules

All deadline calculations and escalations

Inference

Reading dates and directions from court orders and letters

Needs

Phase 1; ideally writing diary entries into SiteView

A9. Links and anomalies across One Claim's own claims

Every phone number, address, email, vehicle, representative, garage, hire company and bank account that Postbot reads is stored. A rule-based link check shows when the same details appear across unrelated claims, and simple checks catch reused photographs (identical or near-identical images across claims) and photos whose embedded dates do not fit the incident. Flags go to a handler with the links shown; the tool never labels a claim as fraudulent.

Detecting AI-generated or edited images is an active problem across the industry, but detection is not reliable enough to act on alone. We would treat it as one weak indicator at most.

Rules

Entity matching, image fingerprinting, date checks

Inference

Only the extraction of details from documents, already done elsewhere

Needs

Enough claim history; industry databases (such as the Insurance Fraud Bureau's) need separate membership and access

A10. Payment protection

Any email that supplies or changes bank details, or asks for payment to a different party, is held and flagged for call-back verification using contact details already on file. Rules also check that the payee on an invoice matches the party on the claim and that a payment falls within the handler's and the client's authority limits.

Rules

All checks

Inference

Recognising a bank detail change written in prose

Needs

Phase 1; authority limits (see A14)

A11. Vulnerability and dissatisfaction signals

Industry reviews of Consumer Duty reporting have picked out claims handling and support for vulnerable customers as weak areas. Postbot reads every inbound email, so it can record signs of vulnerability (bereavement, illness, disability, financial difficulty, distress) and dissatisfaction, route them by rule to a trained handler, and keep a record showing how each was dealt with. This is already partly in Phase 1; this idea makes it a reported, evidenced process.

Rules

Routing, follow-up timing, reporting

Inference

Recognising vulnerability and dissatisfaction in free text

Needs

One Claim's vulnerability policy

A12. Complaints clock

Complaints have fixed regulatory timescales for acknowledging, resolving and sending a final response. Once Postbot identifies a complaint, rules start the clock, set the diary, prompt for the right letter at each stage from One Claim's templates, and report on timeliness.

Rules

All timescales and templates

Inference

Recognising a complaint that does not use the word

Needs

Clarity on whether complaints are handled by One Claim or by the insurer client

A13. File quality review

Instead of a supervisor sampling a few files a month, every open file is checked against a written checklist: first contact within the target time, reserve reviewed after new information, third party contacted, diary set, correspondence answered. Most checks are rules over claim data and the audit log; Claude reads file notes where a check depends on what was written. The output is a monthly quality report per handler and per client, useful for insurer audits and for Consumer Duty evidence.

Rules

Checklist items that can be read from data

Inference

Checklist items that depend on file notes

Needs

Read access to SiteView notes and reserves (option A or C on the Keylane page)

A14. Client handling instructions as rules

Each insurer or fleet client usually has its own claims handling instructions: authority limits, when to refer, approved suppliers, reporting requirements, reserve rules. These live in documents and in handlers' memories. Turning them into rules in the rule editor means every payment, reserve and referral can be checked against the right client's instructions automatically, and a change to an agreement can be dry run against open claims.

Rules

All checks, once the instructions are captured

Inference

A one-off first draft of rules from the instruction documents, checked by a supervisor before use

Needs

The client handling agreements; payment and reserve events from SiteView

A15. Insurer and capacity provider reporting

Delegated claims handlers and managing general agents report claims to insurers in fixed formats, and at Lloyd's in a standard core data set. Building these reports from claim data by rule, validating every field before submission, and keeping each submission on record removes a recurring manual task and reduces rejected returns. With Capulus in the same group, a consistent reporting layer may serve both businesses.

Rules

All mapping and validation

Inference

None needed

Needs

Report specifications per insurer; SiteView data access; confirmation of which formats One Claim or Capulus submit

A16. Fleet risk insight for clients and underwriting

This is the most ambitious idea here and potentially the most valuable to the group. Claude reads every incident description and records the accident type (reversing, parked, rear-end, junction), location type, time and conditions as facts. Rules and plain statistics then show each fleet client where its claims come from: which depots, vehicle types, drivers, times and manoeuvres. Claude writes a short plain-English commentary on the figures for the account review, with every number coming from the statistics rather than the model. The same data, with appropriate governance, could inform Capulus's fleet underwriting and give brokers a reason to place business with the group.

Rules

All statistics and thresholds

Inference

Classifying free-text circumstances; drafting commentary from computed figures

Needs

Several months of Postbot data or historic claims; agreement on data sharing within the group and with clients

A17. Proactive status updates to brokers and clients

Chasers are a large share of inbound email. A weekly update per broker or fleet client, built from claim data and templates, listing each open claim's stage, last action and next step, should reduce them. Postbot's own chaser counts show whether it works.

Rules

Content, schedule, recipients

Inference

Optional short summary of recent activity on complex claims, reviewed before sending in early use

Needs

Claim status data; client agreement

A18. Claim summary and chronology on demand

When a file changes hands, is escalated, or goes to solicitors, the handler asks for a summary and gets a dated chronology of everything received and sent, with each line linked to its source document. This is inference, because it is summarising, but every statement is cited so it can be checked.

Needs

The claim's correspondence, which Postbot already holds from Phase 1 onward

A19. Procedures and instructions assistant

Handlers ask a question ("what is the authority limit for this client?", "which engineer do we use in Wales?") and get an answer quoted from One Claim's procedures and client instructions, with the source. It answers from documents only and says when it does not know. Where the answer is already a rule (A14), the rule is shown instead.

Needs

Up-to-date procedure documents

A20. First notification intake into SiteView

New incidents arrive as broker emails, fleet forms and phone calls. Postbot already reads them into facts; the next step is creating the claim in SiteView with those facts, rather than a person re-keying them. Third-party and vehicle details could also be completed from commercial data services, as the wider market is starting to do. Phone notifications would need a separate speech-to-text service to produce a transcript first.

Rules

Validation, duplicate detection, required-field checks, client-specific set-up

Inference

Reading free-text notifications and transcripts into fields

Needs

Write access to SiteView (option A on the Keylane page)