Commercial Lines Service · Agent blueprint · validated with 8 team members

First Notice of Loss Prep Agent

Reads the client's loss report in Outlook, matches the account and policy in Applied Epic, and prepares the claim record and the carrier portal entry. A CSR approves the prepared claim once, then a browser agent enters it in the carrier portal. The claim number is recorded in Epic and a reply to the client is drafted for approval.

Trigger

A client loss report arrives by email in the CSR's Outlook (calls are keyed in as a short note or forwarded summary).

Done when: The carrier's claim number is recorded in Applied Epic and sent to the client.

Needs: Client email or call note (who, what, when, where, injuries, police report number if any); Applied Epic account, policy number, contact details and deductible; Carrier for the policy (from the Epic policy record); Estimated loss amount, if the client gave one

What the agent does

1. 1
   Read the new loss report and extract the key facts · Microsoft Outlookconnector

   Outlook trigger passes the email to the model, which pulls date of loss, description, injuries, police report number and contact.
2. 2
   Draft the loss description in the client's own words · Microsoft Outlookai

   Who, what, when, where, plus the police report number if there is one. No coverage advice.
3. 3
   Find the client account and candidate policies · Applied Epicapi

   Match on sender, name or policy number. If there is no single clear match, hand to the CSR.
4. 4
   Suggest claim type and flag injuries or near-deductible losses · Applied Epicai

   Vehicles = Auto, building damage = Property, customer injuries = General liability. Anything else goes to the CSR.
5. 5
   Show the prepared claim to the CSR for review and approval · Applied Epicperson

   The CSR checks policy, claim type, description and carrier, edits if needed, and approves. Nothing is saved or submitted before this.
6. 6
   Create the claim and the activity in Epic with status · Applied Epicapi

   Writes claim type, loss description and claim status. Logs the client request as an activity.
7. 7
   Enter date of loss, description, policy number and contact in carrier portal · Carrier agent portalsui automation

   These portals have no API, so a browser agent works the screens with the approved data. It stops for a person if a screen doesn't match.
8. 8
   Phone the carrier the same day for injury claims · Carrier agent portalsperson

   The CSR makes the call in addition to the online report. The agent supplies the claim summary and a reminder.
9. 9
   Read the carrier claim number from the portal confirmation · Carrier agent portalsui automation

   Browser agent captures the number and the confirmation screen. If none appears, hand to the CSR.
10. 10
    Record the claim number and update claim status in Epic · Applied Epicapi

    Runs after the CSR has confirmed the portal submission succeeded.
11. 11
    Draft the reply to the client with the claim number · Microsoft Outlookai

    Short confirmation with the claim number and next steps. No coverage statements.
12. 12
    Review the reply and send it to the client · Microsoft Outlookperson

    The CSR approves, then the reply is sent from Outlook. This closes the case.

Decisions the agent makes

Where a person signs off

• CSR approves the prepared claim (policy match, claim type, description, carrier) before anything is written to Epic or submitted to a carrier portal
• CSR confirms the portal submission and claim number before the Epic update
• CSR approves the reply to the client before it is sent
• CSR makes the same-day phone report on injury claims

Exceptions

Build with

• Power Automate: Outlook trigger, Epic API calls, approval flow, orchestration and run logging
• Microsoft 365 Copilot / Copilot Studio: Extracts facts, drafts the loss description, suggests claim type, drafts the client reply
• Power Automate desktop / browser agent in Microsoft Edge: Works the Travelers, The Hartford and Liberty Mutual portal screens
• Applied Epic API: Reads accounts and policies; writes claims, activities and claim numbers

Skills: Power Automate, Copilot Studio prompts, Applied Epic API, browser/UI automation, testing with CSRs

Before building

• Applied Epic API access with a service account that can read accounts and policies and write claims and activities; confirm the API supports creating claims
• Power Automate and Microsoft 365 Copilot licences, including attended or desktop automation capacity
• Outlook connector on the shared or CSR mailboxes in scope
• A dedicated agent sign-in for each carrier portal (Travelers, The Hartford, Liberty Mutual), with multi-factor handled in a way the carriers permit
• Check each portal owner's terms on automated access before building
• Written same-day reporting and injury-phone-report rules, with the carrier phone numbers

Risks

• Portal screens change without notice: monitor runs, alert on failures, and hand to a person whenever a screen doesn't match
• Carrier terms or MFA policies may restrict automated access to the portals
• A wrong policy match or claim type could reach a carrier, so the single approval screen must show these clearly
• The team disagrees on near-deductible and unusual cases, so the agent could mishandle a case if these rules are not settled
• Savings are modest (about 30-50% of 5.5 team hours a week, roughly 2 hours): exception review and portal maintenance could eat into this

How we'll know it worked

• Median work time per claim (baseline 10.1 min) and team hours per week (baseline 5.5)
• Share of claims reported to the carrier the same day (baseline not measured; start tracking before launch)
• Share of claims handed to the CSR to finish by hand, by reason
• Claims where the Epic record and the carrier portal disagree (baseline 0% observed mismatch)

Still to answer before building

• Where are the same-day reporting rule and other claim policies written down, and who owns them?
• What is the deadline and process for the injury phone report, and which carrier numbers are used?
• How is the carrier chosen for a claim, and does the carrier determine which portal is used?
• How are claim types beyond Auto, Property and GL chosen (e.g. workers' compensation)?
• How is the claim status in Epic chosen, and which values are used?
• For losses near the deductible: does the same-day rule apply, or does the CSR ask the client first, and what counts as near?
• Why do about a third of people give 'other' as the reason for retyping?
• How often do unusual cases really occur? About 7 in 10 said almost never and about 3 in 10 said often.

Where the team disagrees

Settle these first: an agent needs one rule, and new hires get mixed answers today.

• Most say to report every loss the same day even if the client is unsure, yet some say to ask clients with losses near the deductible whether they want to report. How these fit together is not stated.
• About 7 in 10 say unusual cases almost never occur and about 3 in 10 say often, so the frequency of exceptions is unclear.

Evidence

• 90% of cases follow the same steps (some skip a step)
• 6 team hours a week
• data is moved by hand from Applied Epic to Liberty Mutual Agent Portal (64% retyped)

Observed main path (73% of cases): Microsoft Outlook → Applied Epic → Edit Claim type → Microsoft Edge → Edit Loss description → Applied Epic → Edit Claim status

Handover spec for the builder (text) →

Designed by AI from how the team did this work (2026-10-19 to 2026-10-23), the company's tools and its rules. A starting point for the builder: confirm system access and approvals before building.