Claims Intake With Three Channels and a 24-Hour Triage Clock
Northwind Mutual, a regional insurer, receives 4,200 property claims each week: 55% through a self-service portal, 30% by email, and 15% from a broker XML API. All channels currently create one 'Claim' case type with 18 properties. When claimants resend an email, the system creates a second case; about 6% of email claims are duplicates. A 12-person triage team manually assigns cases to three adjuster queues by region and claim amount. The first-contact SLA is 24 hours, but the average is 38 hours, and the audit team requires every status change and assignment to be traceable. The business now wants a parallel fraud review for claims over $25,000 and an optional subrogation process after payment. The broker API sends nullable fields, and some brokers omit the policy number. The platform is Pega Platform 8.8 with Theme Cosmos. Design the case lifecycle and routing so the SLA is met without increasing triage headcount.
1. Would you model the three channels as separate case types, or as one case type with channel-specific intake? Justify the decision in terms of lifecycle, data, and maintenance.
Read the worked answer
I would keep one Claim case type and model channel-specific intake as separate processes, not separate case types.
Reasoning:
- After intake, all three channels follow the same investigation, fraud review, payment, and subrogation lifecycle. Separate case types would duplicate the 18 properties, SLA logic, audit configuration, reporting, and future changes to fraud or subrogation.
- Channel differences are mostly data capture and validation. Use a Channel property and a decision table or when rule to route to Portal Intake, Email Intake, or Broker API Intake. A data transform can map broker XML fields and handle nullable values without creating a new case type.
- Keep the case-wide data model common: policy number, claimant, loss date, amount, region, and channel. If broker claims later need a genuinely different adjudication path, introduce case type inheritance with a BrokerClaim child rather than three independent case types.
- Separate case types would also make duplicate detection harder because email and portal claims would live in different work pools. One case type lets a single duplicate check search all claims by policy number and claimant email.
The judgement call is to separate intake variation from lifecycle variation. Here the lifecycle is shared, so one case type with channel-specific intake processes and validation is simpler and safer to maintain.
2. How would you design routing and SLA to hit 24-hour first contact with the same 12 triage staff?
Read the worked answer
The current 38-hour average is not primarily a staffing problem; it is a manual triage queue problem. I would remove the human triage assignment from the critical path.
Design:
- On case creation, run a decision table using region and claim amount to set the adjuster work queue, urgency, and required skills. This happens automatically in the intake process.
- Put an assignment-level SLA on the first adjuster contact: goal at 8 hours, deadline at 24 hours, with escalation to the queue supervisor at 18 hours. Do not rely only on a case-level deadline, because the requirement is first contact, not case closure.
- Use Get Next Work and queue-level reporting so adjusters pull from their own queue rather than waiting for a triage person to assign. Reserve a small Triage Review queue for exceptions such as missing policy number or ambiguous region.
- For broker claims with missing policy numbers, route to a data completion step before adjuster assignment, but keep that step inside the 24-hour clock and measure it separately.
- Audit assignment and status changes through case history and SLA events so the audit team can trace who received the case and when.
If volumes spike, the same decision table can temporarily raise urgency for aged cases. The design does not require more triage staff; it changes triage from manual assignment to automated routing plus exception handling.
3. The fraud review must run in parallel and must not block the adjuster; subrogation is optional. How do you model both without creating locking conflicts or duplicate work?
Read the worked answer
I would model fraud review as a child case, not as a second assignment on the same Claim case.
Reasoning:
- Fraud review has its own queue, its own SLA, and potentially a different team. If it runs as an assignment on the parent Claim, opening it can lock the Claim and block the adjuster from updating the investigation. A FraudReview child case has its own lock and lifecycle.
- The Claim can continue the adjuster investigation while the child case runs. Add a dependency or wait point only where payment must not be released before the fraud decision. The adjuster is not blocked from investigating, but payment is blocked by the dependency.
- Subrogation is an optional process after payment. Model it as an optional process with a condition such as payment complete and subrogation eligible. It should not start for every claim and should not be part of the fraud branch.
- Duplicate email claims need a duplicate check before case creation: search existing cases by policy number and claimant email using a report definition or data page. If a likely match exists, link the new email as a related case and route to a Duplicate Review assignment instead of creating a second Claim.
- Keep fraud and subrogation outcomes on the parent as read-only case-wide properties updated by the child case or by a data transform after the child resolves.
This separates long-running parallel work from the parent lock and avoids both lock contention and duplicate claim creation.