Insurance FNOL Entity Resolution and Composite Bag Prompts
A health insurer's digital assistant handles first notice of loss (FNOL) for auto claims. The skill uses a composite bag entity named ClaimDetails with five entity items: policyNumber (custom entity), lossDate (system.Date), claimType (custom list: collision, theft, weather, other), vehicle (custom entity), and description (string). About 3,000 conversations run per day. Agents see 15% abandonment at the lossDate prompt. Users say things like 'last Tuesday', 'the storm on the 14th', or 'the day my car was hit in the lot'. When a user replies 'the third one' at the claimType prompt, the bot repeats the prompt twice and then ends the flow. Policy numbers are often spoken as 'P zero zero four four seven one' and fail validation. The team wants to add a fifth prompt but keep the flow to two minutes.
1. Why do relative dates, spoken policy numbers, and ordinal replies fail here? Explain how composite bag entity resolution and prompt loops behave.
Read the worked answer
A composite bag entity tries to fill each entity item in turn. When an item cannot be resolved or validated, the flow re-prompts. After the configured maximum prompt attempts, the flow transitions to unresolved or ends. That explains the repeated prompt and termination.
The policy number fails because the custom entity expects a particular textual shape, while the user speaks digits as words: 'P zero zero four four seven one'. Without normalization, validation fails even though the user gave a valid number. The date prompt fails for two different reasons. system.Date handles many relative expressions, but it needs a reference date and timezone, and ambiguous narratives like 'the day my car was hit in the lot' have no date to extract. Without an event handler or a narrower follow-up prompt, the bot cannot convert that story into a date. 'The third one' is an ordinal reference to the options shown, not a value in the claimType custom list. The resolver has no mapping from ordinal to list item, so it re-prompts. These are prompt-design and event-handler gaps, not simply training-data shortages.
2. Design changes to resolve these issues without increasing total conversation time. Include entity event handlers, prompt design, and validation behavior.
Read the worked answer
Use an entity event handler custom component on the composite bag rather than adding more prompts:
- policyNumber: on the resolved event, normalize spoken digits ('zero' and 'oh' to 0), strip spaces and hyphens, uppercase the leading letter, then validate. If validation fails, return a specific message and allow one retry before offering agent transfer.
- lossDate: configure the system date entity with the correct timezone and a reasonable date range. Add handler logic for relative phrases and a fallback prompt such as 'Was that before or after the 14th?' instead of repeating the same question. Confirm the resolved date back to the user.
- claimType: map ordinals to the options actually presented. Use a resolved event handler or prompt configuration that accepts 'the third one' and returns the third rendered choice. Do not hard-code list order if the custom list can be reordered; use the rendered option list.
- Keep description optional and make vehicle resolvable from policy data where possible. Set maximum prompts per entity to two, then offer a transfer or a callback rather than ending silently.
This keeps the flow near two minutes because it removes repeated prompts and resolves values on the first or second attempt.
3. What test cases and correctness checks would you require before releasing the revised FNOL flow?
Read the worked answer
Test each entity independently and as a composite bag, using at least 40 real utterances per entity, including noisy SMS-style input and code-switching. For policy numbers, include spoken digits, mixed digits and words, missing leading letter, and invalid checksums; confirm normalization does not accept an invalid policy. For dates, test 'last Tuesday', 'the 14th', 'yesterday', midnight boundaries, and daylight-saving transitions. For claimType, test 'the third one', 'number three', 'the weather one', and an option that is not in the list. Measure first-attempt resolution rate, prompts per entity, abandonment, and total flow duration. Verify that the ordinal mapping uses the same option order the user saw, not a static list. Finally, test the maximum-prompt path to confirm it transfers cleanly and does not drop partial claim data.