Designing Architect Decision Trees for Insurance Claim Triage Using JSON Lookups

How-To-Articles
1

Designing Architect Decision Trees for Insurance Claim Triage Using JSON Lookups

Executive Summary & Architectural Context

In the insurance industry, the First Notice of Loss (FNOL) is the most critical interaction in the customer lifecycle. A customer calling to report a house fire needs a vastly different experience than a customer reporting a cracked windshield. Standard IVR design-relying on a series of nested “Press 1 for Auto, Press 2 for Home” menus-is inherently brittle, difficult to update, and provides a poor customer experience for complex, multi-line policyholders.

A Principal Architect moves the logic out of the IVR and into an Externalized Decision Engine. By using JSON-driven decision trees, the Architect flow becomes a dynamic interpreter. When a caller enters their policy number, the system performs a real-time “Policy Dip” and receives a JSON payload describing exactly which triage questions to ask, what the valid responses are, and which specialized queue should handle the final transfer.

This masterclass details how to build a scalable triage engine in Genesys Cloud and NICE CXone, leveraging advanced JSONPath extraction and Data Action state-management.

Prerequisites, Roles & Licensing

Licensing & Permissions

  • Licensing Tier: Genesys Cloud CX 2 or 3 (Required for complex Architect logic and Data Action concurrency).
  • Granular Permissions:
    • Architect > Flow > Edit
    • Integrations > Action > Execute
    • Architect > Datatable > View
  • Dependencies: A Claims Management System (CMS) or Policy Administration System (PAS) with a REST API that returns claim-contextual JSON.

The Implementation Deep-Dive

1. The Architectural Shift: Logic vs. Flow

In a traditional flow, adding a new insurance product requires opening Architect, dragging new blocks, and republishing. In a JSON-driven flow, you simply update a database record.

The JSON Schema Pattern:
The external system should return a “Triage Descriptor” object:

{
  "policyType": "PERSONAL_AUTO",
  "eligibleClaims": ["COLLISION", "COMPREHENSIVE", "GLASS"],
  "urgencyFactors": ["INJURY", "DRIVABLE", "TOW_REQUIRED"],
  "priorityScore": 85,
  "targetQueueGuid": "a1b2c3d4-e5f6..."
}

2. Implementing the “Interpreter” Flow

The Architect flow must be designed as a generic “Engine” that can handle any policy type returned by the API.

Step 1: The Policy Dip

  • Use a Data Action to fetch the triage descriptor based on the PolicyNumber input.
  • Map the JSON arrays (eligibleClaims, urgencyFactors) to Collection Variables in Architect.

Step 2: Dynamic Menu Generation

How do you play a menu when you don’t know the options in advance?

  • The Solution: Use a Loop to iterate through the Flow.eligibleClaims collection.
  • The Technique: Concatenate a dynamic prompt.
    • Loop 1: Flow.TriagePrompt = Flow.TriagePrompt + "Press 1 for " + ToAudioPrompt(Flow.eligibleClaims[0])
    • Loop 2: Flow.TriagePrompt = Flow.TriagePrompt + "Press 2 for " + ToAudioPrompt(Flow.eligibleClaims[1])
  • The Play: Use a single Collect Input action that plays the Flow.TriagePrompt variable.

Step 3: Multi-Factor Urgency Triage

After the user selects their claim type (e.g., “Collision”), the flow must ask the Urgency Questions defined in the JSON.

  • Example Logic: If the JSON says TOW_REQUIRED is an urgency factor, the IVR asks: “Is your vehicle currently drivable, or do you require a tow?”
  • If the caller answers “Tow Required,” use an Update Data action to increase the Flow.PriorityScore by 20 points.

[!IMPORTANT]
Architectural Reasoning: By calculating a PriorityScore within the flow based on these dynamic factors, we ensure that a “Total Loss with Injury” call jumps to the front of the queue, while a “Parking Lot Ding” waits for the next available adjuster.

3. “The Trap”: The Orphaned Response

The Scenario: You build a dynamic menu that offers 4 options based on the JSON. The caller presses 5.

The Catastrophe: If you haven’t accounted for the “Invalid Input” path in a dynamic environment, the flow might crash or default to a generic “I’m sorry, I didn’t get that” loop that never ends because the “Invalid” path doesn’t know what the valid options were.

The Principal Architect’s Solution: The “Valid Range” Validator
Inside your Collect Input action, set the Maximum Digits based on the length of your JSON array (Flow.eligibleClaims.Count).

  • Validation Expression: If(ToInt(Task.Input) <= Flow.eligibleClaims.Count, "Valid", "Invalid")
  • This ensures that the flow only accepts inputs that correspond to the dynamic menu presented to the caller.

Advanced: Catastrophe (CAT) Mode Overrides

During major weather events (hurricanes, wildfires), insurance triage needs to change instantly across the entire country.

Implementation Pattern:

  1. Create a Global Data Table named CAT_Overrides.
  2. The Triage Flow performs a secondary lookup: Lookup(CAT_Overrides, State: "FL", ZipCode: "33101").
  3. If a “CAT Flag” is active for that region, the flow Short-Circuits the standard triage.
  4. Override Action: Play: “We are currently responding to the recent hurricane in your area. Your claim will be fast-tracked to our Emergency Response Team.”
  5. Force the Flow.PriorityScore to 100 and transfer to the CAT_Response_Queue.

This “Geographic Short-Circuiting” prevents your triage engine from getting bogged down in routine questions during a state of emergency.

Integration: Injecting Triage Meta-Data into the Agent Workspace

The agent should not have to ask the questions the IVR just asked.

The Data Handoff (Participant Data):

As the triage progresses, update the following Participant Attributes:

  • Claim_Type: e.g., “Auto Collision”
  • Urgency_Level: e.g., “CRITICAL”
  • Tow_Required: e.g., “YES”
  • Policy_Validated: e.g., “TRUE”

Agent Script Integration:

When the adjuster answers the call, the Genesys Cloud Script should automatically pop up with a high-visibility “Triage Summary” panel:

  • Red Alert Header: “URGENT: TOW REQUIRED & INJURY REPORTED”
  • Quick Links: Button to “Open New Claim Record” with all IVR data pre-populated.

Validation, Edge Cases & Troubleshooting

Edge Case 1: JSONPath Performance Latency

The failure condition: The Policy Dip returns a 50KB JSON payload with hundreds of nodes, and Architect takes 2 seconds to “Flatten” it.
The root cause: Inefficient JSONPath queries within a Data Action.
The solution: Use a Middleware Layer (AWS Lambda or Azure Function) to “Pre-Process” the claim data. The Lambda should return a “Lean” JSON object containing only the specific fields Architect needs for triage, rather than the entire policy database record.

Edge Case 2: Multi-Language Triage Discrepancies

The failure condition: The JSON returns claim types in English (“Collision”), but the caller is in the Spanish IVR.
The root cause: Lack of localization in the decision engine.
The solution: The JSON response should include Prompt Keys instead of literal strings.

  • JSON: "claim_type_prompt": "PROMPT_COLLISION"
  • Architect: Play Audio(FindPromptByID(Flow.claim_type_prompt))
  • Architect will then play the Spanish version of the “Collision” prompt automatically based on the flow’s current language.

Reporting & ROI Analysis

A dynamic triage engine provides unprecedented visibility into your claims pipeline.

Metrics to Monitor:

  • Triage Completion Rate: What percentage of callers successfully categorize their claim before reaching an agent?
  • Priority Accuracy: Comparison of the IVR-assigned PriorityScore vs. the Adjuster’s final assessment.
  • CAT Mode Efficiency: How quickly did the system pivot to emergency routing during a specific event?

Target ROI: Expect a 15% reduction in Average Handle Time (AHT) for FNOL calls and a 40% improvement in “First-Touch Resolution” for emergency claims.

Official References