Tractable · PRD

Migrating a Multi-Brand Insurer to Full Platform Parity

TL;DR

Enable Tractable's Estimating and Total-Loss Triage use case for one of Europe's largest motor insurers and its digital-first subsidiary brand, who share a single legacy claims stack. This PRD scopes the migration to full feature parity across both brands, plus a licence-plate matching capability requested as part of the move.

PRD Owner

Prateek Raina

Design Owner

Product Design

Stakeholders

Regional, Commercial (both brands), Operations & Product Analytics leads

Status

[Internal Status]

1. Introduction

Goal: Migrate both the client and its digital-first subsidiary off their shared legacy claims stack onto Tractable's current platform, with full feature parity for each brand and the licence-plate matching capability they've requested as part of the move.

Scope: The feature-parity work for both brands, the claim-handler and policyholder workflows, the case-status lifecycle, and the new VRM/licence-plate matching capability. A broader document-verification package beyond licence plates (grey card, VIN-document checks) is tracked separately and out of scope here.

2. Background

Customer Profile

The client is one of its country's largest motor insurers, operating alongside a digital-first subsidiary brand that targets a younger, app-native customer base. Both brands share a single backend and claims stack, though each has its own customer-facing capture experience.

The Use Case: Estimating & Total-Loss Triage

The client uses Tractable's Estimating use case to generate an AI repair estimate and a Total-Loss eligibility verdict at the moment of intake, so claim handlers can move straight to a cash-settlement decision. Eligible claims are triaged automatically; the rest are routed back for manual handling.

2.1 User Personas

Policy Holder

Primary policyholders under either brand's coverage

Primary goalGet indemnified as fast as possible after an accident

Key interactionOpens a claim by phone (both brands) or in-app (subsidiary only), then captures vehicle photos via the Tractable web app

Claim Handler

Employees of either brand responsible for managing a claim from first report to final settlement

Primary goalCash-settle as many claims as possible, as quickly as possible

Pain pointInaccurate assessments lower the odds of a cash settlement, and expiring links force manual escalation

Claim Handler Manager

Manages a team of Claim Handlers

Primary goalProcess every claim as fast as possible, with full visibility into the team's cash-settlement conversion rate

Key interactionUses the Tractable portal to check out-of-scope cases and regenerate expired links

The subsidiary brand's persona nuances weren't broken out separately in the source document; where its workflow differs (app-based intake, no VIN or dashboard capture), that's called out inline in the system specs and feature checklist below.

2.2 Legacy Feature Parity

Before migrating both brands onto Tractable's current platform, every feature already live on the primary brand's legacy stack must be accounted for. The subsidiary brand's own checklist wasn't completed in the source document; known differences for it are flagged inline where applicable.

Applicable for the client 28

API HIL, ~50% of low-confidence cases Search Filters & sort Estimate shown in UI Image gallery Licence-plate match status shown in UI Configurable table columns View by status (tabs) Create new case Case ID field Registration number field Accident date field Accident-circumstances field (250-char limit) Point-of-impact diagram Damage capture Corner capture VIN capture (primary brand only) Dashboard photo (primary brand only) Mileage capture Completion screen Repair value / vehicle value % PDF download Information side panel Image download as ZIP Advanced photo gallery controls Additional damage flagging Default sort by creation date

Not applicable for the client 18

STP License plate capture Vehicle condition questions Estimate as PDF Car damage diagram Multiple vehicle brands Parsed bodyshop estimate in UI Original bodyshop estimate in PDF AI review flags, agree/disagree per flag Agree/disagree with all flags at once Editable labour-hours on AI flag Line-number reference to bodyshop estimate "Mark as reviewed" button with notes Inline estimate editing Multiple estimate versions View-only mode Manual case-status update Expedited payment flow

3. System Specifications

3.1 FNOL Input Portal for Claim Handlers

When a policyholder contacts either brand, claim handlers use this portal to capture initial claim data and send it to the client's backend, which runs an initial eligibility check to determine whether the case qualifies for Tractable processing.

3.2 Client Backend

Triages initial claim data for eligibility, then sends the vehicle's VIN and accident date to Tractable in exchange for a claim-specific link. Delivers that link to the policyholder to start the photo-capture journey, then ingests the AI-processed results back via API or portal integration to finalise the claim.

3.3 Tractable Backend

Generates the claim-specific link on request, then calculates the repair estimate and Total-Loss eligibility once the policyholder completes capture. Makes both available through three channels: API, email, and the portal.

3.4 Tractable Input Capture App

Guides the policyholder through a sequence of prompts to capture the required vehicle images, with secure transmission to the Tractable backend for automated AI processing.

3.5 Subsidiary's Input Capture App

A brand-specific variant of the Input Capture App for the digital subsidiary, with its own visual styling and an auto-redirect step once the policyholder finishes the flow.

4. Workflow & Designs

End-to-end business workflow, rebuilt as a swimlane diagram from the original whiteboard. Scroll horizontally on smaller screens.

Lanes represent each actor in the workflow; arrows follow the path of a single claim from intake to cash-settlement decision.

5. Pain Points & Areas of Improvement

Portal

No clear visibility into why a claim is marked out of scope, and the capture link expires after three days, forcing users to start a brand-new claim submission under the same claim ID just to regenerate it.

Capture App

Users have to tap multiple times to capture photos within the same bucket instead of doing it in one continuous flow, and there's no clear feedback explaining why they can't proceed when the minimum image requirement isn't met.

6. AI Assessment & Configuration Rules

Out-of-Scope Reasons

Every claim that doesn't qualify for automated processing is tagged with a specific out-of-scope reason. The full reason-code list wasn't finalised in the source document; tracked internally rather than reproduced here.

Licence-Plate (VRM) Matching

Runs whenever a claim has both a registration number and at least one four-corner photo, classifying the result as Matched, Not Matched, or Unable to Assess (occluded, blurry, or no plate visible). If the plate-recognition call itself fails, the system treats it as Unable to Assess rather than blocking the estimate. Surfaced as a label in the portal and claim-handler emails today; configurable per brand to also force an out-of-scope decision when the plates don't match.

7. Claim Status Lifecycle & Constraints

Awaiting InfoAwaiting Info

Case ingested and pre-processing — the Input Capture App link has been generated and is awaiting the policyholder's photos and vehicle information.

Link ExpiredLink Expired

The Input Capture App link expired before all information was received. Expiry is configurable (default three days); if the policyholder already submitted some information, they resume from their last completed step on the new link.

ProcessingProcessing

Tractable is processing the claim.

Ready For ReviewReady For Review

The Tractable estimate is ready for the claim handler to review.

FailedUnable To Process

Tractable processing failed. Surfaced to Level 1 Support and the CSM team to debug the failure.

8. User Stories

A representative sample below; the rest are grouped by section and condensed where several rows describe one continuous flow.

Data Intake & Enrichment

Data Intake

As the Tractable system, I should be able to receive the car's VIN and accident date, so I can generate a claim-specific link for the policyholder.

Exists in KTLO

Data Intake

Tractable logs this as a new, independently stored and retrievable case, and generates the claim-specific link to send to the insurer for the workflow.

Exists in KTLO

Input Capture App

Input Capture

As the Input Capture App, I should recognise the claim-specific link and walk the policyholder through the brand's screen sequence: the primary brand's flow includes a dashboard photo and a VIN photo that the subsidiary's flow skips.

Exists in KTLO

Capture App

The app submits the policyholder's details back to Tractable so the platform can continue the workflow.

Exists in KTLO

Tractable Backend

Backend

As the Tractable platform, I should generate the AI estimate and Total-Loss triage verdict, so I can share it with the necessary stakeholders.

Exists in KTLO

Backend

Distributes the estimate and triage results via email, API, and the portal, generating the email content itself before sending it to the relevant stakeholder.

Exists in KTLO

List View Page

As a user, I should be able to search all cases by Claim ID or registration number, so I can quickly find a specific case.

Exists in KTLO

List View

Cases can be grouped into status tabs, filtered by vehicle or creator, sorted by creation date, and paginated at 50 per page with clear page position and navigation.

Exists in KTLO

List View

Clicking a row opens the full case and estimate detail.

Exists in KTLO

List View

A "Create New" button opens a modal to capture Claim ID, accident date, registration number, and an optional accident-circumstances note (250-character limit). The create button stays disabled until required fields are filled; submitting routes to the new case's detail page.

Exists in KTLO

List View

A date-range picker filters claims by accident date, and a profile menu gives access to account info and logout.

Exists in KTLO

Details Page

As a Claim Handler, I want to see the AI assessment results, so I can review the estimate and decide on the cash settlement.

Exists in KTLO

Details Page

A widget lets the claim handler copy the Input Capture link, and generate a fresh one if the previous one expires, without creating a new case.

Improvement

Details Page

The page tracks the policyholder's step-by-step progress through the Capture App: Awaiting Info, Link Expired, Processing, Ready For Review, or Failed.

Exists in KTLO

Details Page

A car diagram highlights damaged panels and recommended operations with colour codes, including a point-of-impact view for spotting discrepancies.

Exists in KTLO

Details Page

A repair-cost-to-vehicle-value bar shows at a glance whether a case is near or at total loss, alongside a flag for likely additional damage.

Exists in KTLO

Details Page

An image gallery supports zoom, rotate, invert, panel-based filtering, and opening images full-resolution in a new tab.

Exists in KTLO

Details Page

The estimate is shown directly in the UI for cash-settlement decisions, non-editable unlike some other implementations, with a Download PDF option for offline use.

Exists in KTLO (static version)

Details Page

Shows whether the vehicle is repairable, approaching total loss, or total loss, so the handler can proceed quickly.

Exists in KTLO

Details Page

A side panel surfaces key case details, with a dedicated button to open full vehicle details, and an Export Images button to download all images as one ZIP file.

Exists in KTLO

Details Page

The claim ID, current status, and VIN are always visible while handling a case.

Exists in KTLO

HIL

As the Tractable platform, I want to integrate human-in-the-loop review into the current process, so we can capture more claims and reduce the out-of-scope rate.

Improvement