Claims (理賠)

Learning Objectives

• Take a claim notification correctly the first time, including the documents to request on the phone and what to tell the client happens next and by when.
• Assemble a claim form and supporting medical documentation in the shape the adjuster expects, so the file is not bounced for administrative reasons.
• Trace the adjuster workflow and the claim status state machine, explain to the client what each status actually means and who is responsible for the next action, and distinguish third-party claims from own-account claims — including motor third-party (乙部/第三者) versus own-account (車主自身/自身利益) treatment, and why the two follow different documentation and payment paths.

In practice: the majority of "the claim is stuck" complaints are not underwriting decisions at all. They are a missing document, a missing signature, or a status the agent mis-described to the client. The skill this lesson builds is reading the claim file and knowing whose turn it is.

---

Why Claims Are Where the Product Breaks

Selling is fast and claims are slow. A sale closes in an hour; a claim can run for eighteen months. That asymmetry is why claims are the module that most reliably damages the client relationship — not because insurers act in bad faith, but because the status vocabulary differs between the agent, the adjuster and the client.

An agent says "佢而家喺度審". The adjuster's system says ASSESSING. The client hears "審" as "there is a problem with my claim". In practice ASSESSING is the normal state for a claim that is going to be paid.

The gap between these three vocabularies is the single largest source of avoidable escalations, and closing it is a learnable skill.

Client complaint        Agent's word        Adjuster's state     Reality
─────────────────────────────────────────────────────────────────────────
"個 case 死咗"        "仲喺度等"         NOTIFIED              Waiting on client
"成個 promise 唔算數"  "佢哋唔肯批"       ASSESSING            Normal, 6-12 weeks
"成個 process 好慢"    "資料唔夠"         AWAITING_DOCS         Agent's fault
"我朋友都批咗"         "咁係 bonus 呀"    DECLINED              Fair, explainable

The last row is the hard one. A declined claim is very often correct, and the agent's job is to explain why it is correct in terms the client already agreed to at application stage.

---

Section 1: The Claim Lifecycle End to End

In practice: every claim follows the same seven beats. Knowing which beat you are in tells you immediately whether the next action is yours, the client's, or the carrier's.

stateDiagram-v2
    [*] --> NOTIFIED: agent/carrier logs notification
    NOTIFIED --> SUBMITTED: claim form + documents received
    NOTIFIED --> WITHDRAWN: client withdraws
    NOTMITTED --> DECLINED: no form within time limit

    SUBMITTED --> AWAITING_DOCS: adjuster requests more
    AWAITING_DOCS --> SUBMITTED: documents received
    AWAITING_DOCS --> DECLINED: docs never supplied

    SUBMITTED --> ASSESSING: adjuster opens assessment
    ASSESSING --> REFERRED: needs medical/peer review
    REFERRED --> ASSESSING: review complete
    REFERRED --> DECLINED: peer review negative

    ASSESSING --> APPROVED: benefit within sum assured
    ASSESSING --> DECLINED: outside terms / exclusion / late

    APPROVED --> SETTLING: payment instruction raised
    SETTLING --> SETTLED: payment confirmed

    SUBMITTED --> REOPENED: new evidence within 12 months
    REOPENED --> ASSESSING

    DECLINED --> REOPENED: internal review upheld/declined
    WITHDRAWN --> [*]
    SETTLED --> [*]

Two features of this machine drive everything else in the lesson.

First, it is mostly a waiting machine. The AWAITING_DOCS state is the longest-lived and the most controllable. It is the one state where the agent has direct leverage, because the documents come from the client. Every hour spent chasing documents at notification stage is an hour removed from the ASSESSING clock.

Second, DECLINED is not terminal in spirit. REOPENED exists because insurers have an internal reconsideration step — a different reviewer, sometimes medical evidence the first pass did not request. An agent who tells a client "declined, game over" is advising them to give up something they may well be owed.

---

Section 2: Taking the Notification

In practice: the notification call is the highest-leverage three minutes in the whole claims process. Get it right and the file assembles itself; get it wrong and every subsequent step takes longer than it should.

What to capture

The cause field deserves special care. The adjuster will later send the client's statement to medical records and to, potentially, the third party. Wording that assigns blame creates a liability problem for the client in a third-party claim. Capture facts, not conclusions.

type ClaimNotification = {
  claimId: string;              // assigned by carrier, may be null at first contact
  internalRef: string;          // our own reference, always present
  policy: {
    policyNumber: string;
    productCode: string;
    productVersion: string;     // terms in force at the EVENT date, not today
    inForceAtEventDate: boolean;
    effectiveDate: string;
    expiryDate: string;
  };
  insured: {
    name: string;               // as on the policy
    hkId: string;               // last 4 characters only in any list view
    dateOfBirth: string;
  };
  event: {
    eventDate: string;          // YYYY-MM-DD — THE critical field
    firstTreatmentDate: string | null;
    causeNarrative: string;     // client's own words, factual, no blame
    lossType: 'INJURY' | 'ILLNESS' | 'DEATH' | 'PROPERTY' | 'THEFT' | 'LIABILITY' | 'MOTOR_TP' | 'MOTOR_OWN';
  };
  clinical: {
    hospitalName: string;
    hospitalCode: string | null;
    department: string;
    treatingDoctorName: string;
    isConfinement: boolean;     // drives the daily cash / hospital cash benefit path
  };
  estimatedAmountHkd: number | null;
  thirdParty: ThirdPartyInfo | null;
  notifiedAt: string;
  notifiedBy: 'AGENT' | 'CLIENT' | 'CARRIER' | 'HOSPITAL';
  documentsRequested: DocumentRequest[];
  documentsReceived: Document[];
  nextActionOwner: 'CLIENT' | 'AGENT' | 'CARRIER';
  nextActionDue: string | null;
};

type ThirdPartyInfo = {
  isThirdParty: boolean;
  thirdPartyName: string;
  thirdPartyVehicleReg: string | null;   // motor only
  thirdPartyInsurer: string | null;      // motor only
  thirdPartyPolicyNumber: string | null; // motor only
  injurySeverity: 'MINOR' | 'MODERATE' | 'SEVERE' | 'FATAL';
};

The productVersion field is the one most agents never think about. A claim is assessed against the policy terms in force on the event date, not today's terms and not the version the client remembers buying. If the product was re-versioned in the intervening year, a client reading today's benefit table will believe they are owed more than they are. Catching this at notification stage prevents a fight at settlement stage.

What to tell the client at notification

Four sentences, in this order. Agents routinely give them in the wrong order and create expectations that the claims team then has to walk back.

1. Acknowledge and anchor. "收到，我已经開咗個 case，編號係 XXXXX。"
2. Name the clock. "一般住院 claim 由交齊文件開始計審核，大約六至十二個星期。" — anchor to the document-complete date, never to today.
3. Name the ask. "而家我需要你去醫院拎兩樣嘢：出院摘要同埋第一次睇症嗰日嘅醫生紙。"
4. Name the next contact. "如果十日之內我冇打畀你，我會主動搵你。"

What not to say: any estimate of the payout, any promise of approval, any statement about whether a specific expense is covered. Under Hong Kong's Code of Conduct, an agent who represents a claim outcome is misrepresenting the product.

---

Section 3: Documentation and the Common Rejections

In practice: the fastest way to shorten a claim is to send a complete file the first time. Most "carrier is slow" is "carrier received a file with a gap and could not close it".

Medical claims — the required set

{
  "documentRequest": {
    "claimId": "CLM-2026-4417",
    "requestedAt": "2026-03-04",
    "dueDate": "2026-03-18",
    "items": [
      {
        "docType": "DISCHARGE_SUMMARY",
        "label": "出院摘要",
        "source": "Hospital Medical Records Office",
        "clientInstruction": "帶身份證 + 住院編號；部分醫院需先網上申請",
        "blocking": true,
        "typicalTurnaroundDays": 10
      },
      {
        "docType": "FIRST_CONSULTATION_RECORD",
        "label": "首次就診紀錄",
        "source": "Treating doctor (A&E)",
        "clientInstruction": "醫生紙通常要病人親自向診所申請",
        "blocking": true,
        "typicalTurnaroundDays": 7
      },
      {
        "docType": "ITEMISED_BILL",
        "label": "收費明細",
        "source": "Hospital billing office",
        "clientInstruction": "必須逐項，總額單不足以評估",
        "blocking": true,
        "typicalTurnaroundDays": 5
      }
    ]
  }
}

Motor claims — a different and harder documentation problem

The third-party case has a specific trap: the client's own policy covers their vehicle, while the at-fault party's policy covers their bodily injury and, through a knock-for-knock arrangement, the client's vehicle damage. The two claims are therefore separate claims with separate evidence trajectories, but the client experiences them as one event and one agent. Explaining that split early is a core skill.

The seven common rejection reasons, ranked

1. Late notification. Most medical policies require notification "as soon as reasonably practicable", commonly with a hard limit measured from the event date. This is the most avoidable rejection and the one an agent causes by failing to act on a client's "我最近有少少 唔舒服" comment during a policy review.
2. Non-disclosure material to the risk. A prior diagnosis that was not declared. Rejection can be made even where the condition is minor, because the duty is to disclose, not to disclose "significant" conditions.
3. Within an exclusion. The condition or event falls inside a listed exclusion — a specific pre-existing condition exclusion (see Lesson 06), a waiting period, or a named-condition rider exclusion.
4. Outside the benefit period. Confinement longer than the policy's limit, or a benefit with a per-policy cap already exhausted.
5. Sum assured exhausted. Benefit capped at, say, HK$500,000 and the claim is HK$620,000. Partial payment, not rejection — but the client experiences it as one.
6. Documentation gap that cannot be closed. The records requested twice, then the file is closed for non-provision. Recoverable on REOPENED in many cases, but slow.
7. Failure of the duty of disclosure after the event. Occasionally a claim is submitted knowing a fact that would have changed underwriting. Treated far more seriously than items 1-6.

Not all seven are equal, and the agent should know which are which before speaking to the client. The recovery route, the elapsed time, and whether the money can ever be obtained differ by an order of magnitude, and a client told "we'll appeal" when the ground is a closed exclusion will escalate two steps further down the line than a client told the truth on day one.

Say the ground before the client asks. The single most damaging sentence an agent can say at this point is "let us see what happens", because it implies the outcome is open. The honest script names the ground, the recoverability and the timeline:

"你嘅個案被拒絕嘅原因係申報遲咗。呢個情況通常可以上訴，我哋會幫你整理埋 當時嘅就診記錄同遲交嘅原因。如果順利，大約需要四至十二星期。 如果係因為除外條款，咁就冇上訴空間——嗰個條款係你簽約時同意咗嘅。"

The reason matters because the two halves are different conversations. The first is logistics and the client should be optimistic about effort, not outcome. The second is explanation and the client needs the exclusion quoted back from their own contract, not paraphrased by the agent — because the paraphrase is where the complaint is born.

Reason 5 deserves special handling because it is miscategorised. A partial payment arriving against an exhausted benefit reads to a client exactly like a reduction they did not agree to. It is not a rejection, nothing was refused, and no appeal is needed. Saying so — and showing the benefit limit from the policy schedule — converts a complaint into a closing call.

---

Section 4: The Adjuster Workflow

In practice: your role changes completely once a claim is accepted into assessment. Stop trying to influence the assessment and start supplying evidence and managing the client's expectation.

type ClaimStatus =
  | 'NOTIFIED'
  | 'SUBMITTED'
  | 'AWAITING_DOCS'
  | 'ASSESSING'
  | 'REFERRED'
  | 'APPROVED'
  | 'DECLINED'
  | 'REOPENED'
  | 'SETTLING'
  | 'SETTLED'
  | 'WITHDRAWN';

type ClaimRecord = {
  claimId: string;
  status: ClaimStatus;
  claimType: 'INDIVIDUAL_LIFE' | 'INDIVIDUAL_MEDICAL' | 'GROUP_MEDICAL'
           | 'CRITICAL_ILLNESS' | 'ACCIDENT' | 'MOTOR_OWN' | 'MOTOR_TP'
           | 'HOME' | 'TRAVEL' | 'LONG_TERM_CARE' | 'HOSPITAL_CASH';

  insured: { name: string; hkIdLast4: string; dateOfBirth: string };
  policy: { policyNumber: string; productCode: string; productVersion: string };

  // Assessment is always against the version in force on the EVENT date
  assessmentBasis: {
    termsVersionAtEvent: string;
    sumAssured: number;
    sumAssuredRemaining: number;
    benefitsRemaining: { benefitCode: string; limit: number; used: number }[];
    exclusionsApplied: string[];
    waitingPeriodEndDate: string;
    freeLookEnded: boolean;
  };

  statusHistory: {
    from: ClaimStatus | null;
    to: ClaimStatus;
    at: string;
    reason: string;
    actor: 'SYSTEM' | 'ADJUSTER' | 'AGENT' | 'CLIENT' | 'CARRIER_MEDICAL';
    slaDays?: number;
  }[];

  nextAction: { owner: 'CLIENT' | 'AGENT' | 'CARRIER'; action: string; dueDate: string };

  financials: {
    claimedAmount: number;
    assessedAmount: number | null;
    paidAmount: number | null;
    deductible: number | null;
    assessmentNotes?: string;
  };

  reopened: { count: number; lastOutcome: 'UPHELD' | 'OVERTURNED' | 'WITHDRAWN' | null };
};

Who owns the next action

This is the single most useful derived field on a claim, and almost no one computes it explicitly. Build it:

function nextActionOwner(c: ClaimRecord): ClaimRecord['nextAction'] {
  switch (c.status) {
    case 'NOTIFIED':
      // Agent's job: issue claim form and document request the same day
      return {
        owner: 'AGENT',
        action: 'Issue claim form and document request list to client',
        dueDate: addDays(c.statusHistory.at(-1)!.at, 1),
      };

    case 'AWAITING_DOCS': {
      const outstanding = c.assessmentNotes ? 1 : 0;
      return outstanding === 0
        ? { owner: 'AGENT', action: 'Confirm documents received, submit file', dueDate: addDays(c.statusHistory.at(-1)!.at, 2) }
        : { owner: 'CLIENT', action: 'Client to supply outstanding medical documents', dueDate: addDays(c.statusHistory.at(-1)!.at, 14) };
    }

    case 'ASSESSING':
    case 'REFERRED':
    case 'SETTLING':
      // Carrier's clock. Agent's job is expectation management only.
      return { owner: 'CARRIER', action: 'Await carrier assessment', dueDate: addDays(c.statusHistory.at(-1)!.at, c.status === 'REFERRED' ? 21 : 42) };

    case 'DECLINED':
      // Agent's job: explain, then advise on internal review
      return { owner: 'AGENT', action: 'Explain decision to client; advise internal review rights', dueDate: addDays(c.statusHistory.at(-1)!.at, 7) };

    case 'APPROVED':
      return { owner: 'AGENT', action: 'Confirm payment instruction and beneficiary account details', dueDate: addDays(c.statusHistory.at(-1)!.at, 3) };

    case 'SETTLED':
      return { owner: 'AGENT', action: 'Confirm receipt with client; close case; update CRM', dueDate: addDays(c.statusHistory.at(-1)!.at, 14) };

    default:
      return { owner: 'AGENT', action: 'Review claim status', dueDate: addDays(new Date().toISOString(), 3) };
  }
}

The ASSESSING branch encodes a rule agents get wrong constantly: when a claim is under assessment, the agent has no lever on speed. Chasing an adjuster produces nothing but an irritated adjuster and a client who now believes the claim is being actively processed rather than queued. The honest sentence is "而家喺審核階段, 一般六至十二個星期, 我哋個星期會主動 update 你一次".

---

Section 5: Third-Party vs Own-Account Claims

In practice: the distinction determines whose insurer pays what, who needs which documents, and who is the client. Get this wrong and you will collect documents from the wrong person, or advise the wrong party on the wrong policy.

The knock-for-knock reality in Hong Kong

Because repairing a modern vehicle can take weeks, the practical market convention is that a party's own insurer settles the repair quickly and then recovers the cost from the at-fault party's insurer (knock-for-knock, or KFK). This means:

• The client's claim against their own insurer proceeds on its own merits and its own timeline.
• The recovery from the third party is a separate, invisible-to-the-client process run by the two insurers.
• The client's satisfaction is entirely determined by the first limb, not the recovery. They never see the second.

The agent failure here is telling the client that the other party's insurer is "拖慢咗我哋". It is not, and the statement damages trust when settlement arrives on time. The repair is being paid by the client's own insurer the whole time.

Liability apportionment in multi-vehicle accidents

---

Section 6: Settlement

In practice: settlement is the moment you get one last chance to make the relationship, and the moment agents most often get the mechanics wrong.

type Settlement = {
  claimId: string;
  approvedAt: string;
  paymentInstructionRaisedAt: string;
  settledAt: string;
  approvedAmount: number;
  paidAmount: number;
  differenceReason: string | null;

  // The reconciliation an agent must be able to explain
  reconciliation: {
    claimed: number;
    lessDeductible: number;
    lessExcludedItems: { item: string; amount: number; exclusionRef: string }[];
    lessNonCovered: { item: string; amount: number; reason: string }[];
    lessSumAssuredCap: { amount: number; sumAssured: number };
    lessOutstandingBenefitLimit: { amount: number; limit: number; used: number };
    equalsPaid: number;
  };

  payee: {
    name: string;
    accountName: string;          // MUST match the account holder
    bank: string;
    accountNumberLast4: string;   // stored masked
    isThirdParty: boolean;        // third-party payments require written authority
  };
};

The reconciliation is the part to get right. A client who is paid HK$180,000 on a HK$205,000 claim will assume something was withheld, unless the agent can walk the ledger line by line. Build a client-facing view from the same data:

Doing this reconciliation on the phone before the money lands converts the most common "點解少咗" complaint into a non-event.

---

Section 7: The Agent's Claims Dashboard

In practice: you cannot manage claims you do not see. The POS must show you every open claim with its owner and its age, sorted by who is blocking it.

SELECT
  c.id                AS claim_id,
  c.claim_ref         AS claim_ref,
  c.status            AS status,
  c.claim_type        AS claim_type,
  c.policy_number     AS policy_number,
  cl.display_name     AS client_name,
  cl.hkid_last4       AS hkid_last4,
  c.event_date        AS event_date,
  c.assessed_amount   AS assessed_amount,
  na.owner            AS next_action_owner,
  na.action           AS next_action,
  na.due_date         AS next_action_due,
  c.updated_at        AS updated_at,
  CAST(julianday('now') - julianday(na.due_date) AS INTEGER) AS days_overdue
FROM claim c
JOIN policy p      ON p.policy_number = c.policy_number
JOIN client cl     ON cl.id = p.client_id
JOIN claim_next_action_view na ON na.claim_id = c.id
WHERE c.status NOT IN ('SETTLED', 'WITHDRAWN')
ORDER BY
  CASE na.owner WHEN 'CLIENT' THEN 0 WHEN 'AGENT' THEN 1 ELSE 2 END,
  na.due_date ASC;

Two sort rules that make the dashboard useful rather than decorative:

1. Client-blocked claims first. A claim waiting on a client document is 90% of your controllable delay. Burying it under carrier-assessment claims is how it goes stale for four months.
2. Overdue before upcoming. A claim due in 21 days is not work. A claim due yesterday is work.

type ClaimsDashboardRow = {
  claimId: string;
  status: ClaimStatus;
  clientName: string;
  eventDate: string;
  daysOpen: number;
  nextActionOwner: 'CLIENT' | 'AGENT' | 'CARRIER';
  nextAction: string;
  daysOverdue: number;
  clientContactCadence: number;  // days since last agent-client contact
};

// Anything client-blocked and quiet for 10+ days is a churn risk on a claim you will win
const needsAttention = rows.filter(
  r => r.nextActionOwner === 'CLIENT' && r.clientContactCadence >= 10
);

---

Section 8: Client Communication Cadence

In practice: most claim complaints are communication complaints. A fixed cadence costs nothing and eliminates the majority of escalations.

Never contact the client with no news on a long-running claim. Silence is read as bad news. "我哋 仲喺度等緊, 今個星期冇新進展, 下星期再 update 你" is a message you should send, and the fact that most agents do not send it is why claims handling has a reputation it does not deserve.

---

Key Takeaways

1. The claim state machine is mostly a waiting machine. AWAITING_DOCS is the longest and most controllable state because the documents come from the client — chase there first.
2. Capture the date of the event, not the date of the report. It starts the clock, selects the policy version, and is the most commonly recorded field incorrectly.
3. Assess against the terms in force on the event date. Product re-versioning between sale and claim is a frequent and entirely preventable source of dispute.
4. A complete first submission is the single biggest speed lever. Most "carrier is slow" is a gap in the file that prevents closure.
5. Know whose turn it is, explicitly. A derived nextActionOwner field turns claim management from chasing into triage.
6. When a claim is under assessment, you have no lever on speed — only on the client's understanding of it. Say so honestly rather than implying active progress.
7. A declined claim is often correct and usually recoverable. Explain the reason in the terms the client agreed to at application, and advise on internal review.
8. Own-account and third-party claims are separate claims with separate evidence and separate parties. In motor, knock-for-knock means the client's own insurer pays the repair throughout — do not blame the other insurer for delay.
9. Reconcile the settlement out loud before the money lands, and keep a fixed communication cadence. Most "why did I get less" disputes are an unexplained gap between claimed and paid. Most escalations are silence: a weekly "no news" update is a message you should send, because silence is read as bad news.