# Endorsement Prep & Entry Agent

Agent blueprint, validated with 8 team members · Task: Process policy changes (endorsements) · Commercial Lines Service · readiness 64/100 · Standardize first

Reads client change requests in Outlook, prepares each change from the Applied Epic policy, and enters it on the carrier portal after a person approves. After the carrier responds, it records status and premium in Epic and drafts the client confirmation. Staff approve before every write, portal submission and email.

**Trigger:** A client change request arrives in the shared Outlook mailbox (new truck, new driver, removed vehicle, new location, address change). One email can hold several changes.

**Inputs:** Client email text and attachments (VIN, driver name, date of birth, license number, location details, requested effectiv; Applied Epic account and policy record, including the policy's carrier; Carrier portal response (accepted online or referred to underwriter), premium, and MVR result for new drivers; Carrier driver eligibility guidelines (for young or high-violation drivers)

**Done when:** The carrier has accepted the change, Applied Epic holds the activity with type, change type, effective date, status and premium, and the client has received the confirmation with new ID cards. For changes pending underwriting, the case stays open until the carrier decides.

## Steps

1. Detect new change-request email and pull its text and attachments (Outlook, connector)
2. Identify client, list each requested change, and extract vehicle or driver details (Microsoft 365 Copilot, ai): One change type per requested change. Flag unclear requests, missing details, and anything that needs coverage advice.
3. Find the account and policy, and read the carrier and policy type (Applied Epic, api)
4. Check for young driver, violations, or audit-rated policy; collect guideline notes (Microsoft 365 Copilot, ai): Flagged cases go to staff with the findings instead of continuing automatically.
5. Show the prepared change set (change types, effective date, carrier) for approval (Outlook, person): The account manager approves or corrects the whole prepared change in one step, including the Epic activity to be logged.
6. Log the request as an activity with activity type, change type and effective date (Applied Epic, api)
7. Sign in to the policy's carrier portal and open Policy Change (Carrier agent portals, ui automation): Portals have no API, so a browser agent works the screens with a dedicated sign-in.
8. Enter change type, effective date, and vehicle or driver details; submit (Carrier agent portals, ui automation): Runs only after approval. Stops and hands to a person if a screen does not match.
9. Read the carrier outcome: accepted online or referred to underwriter, plus premium (Carrier agent portals, ui automation)
10. Propose activity status and premium from the outcome; person confirms (Applied Epic, person): Completed if accepted online; Pending underwriting if referred (usual for new drivers until the MVR).
11. Update activity status and premium on the Epic activity (Applied Epic, api)
12. Draft client confirmation, only if the carrier accepted, with ID cards (Microsoft 365 Copilot, ai): No confirmation is drafted while the change is pending or rejected.
13. Review the draft and ID cards, then approve sending (Outlook, person)
14. Send the confirmation reply to the client (Outlook, connector)

## Approvals

- Account manager approves the prepared change set before the Epic activity is logged and before anything is submitted on a carrier portal
- Account manager confirms activity status and premium before they are written to Epic
- Account manager approves the client confirmation (and ID cards) before it is sent, and only after carrier acceptance

## Prerequisites

- Write down the standard procedure first (readiness is 'standardize'): carrier choice, driver-exception handling, and status rules
- Dedicated agent sign-in for each carrier portal (Travelers, Liberty Mutual, The Hartford), with multi-factor handled
- Check each carrier portal owner's terms on automated access before building
- Applied Epic API access and a service account that can read policies and write activities
- Outlook connector access to the shared mailbox, and Power Automate and Microsoft 365 Copilot licenses for the builder and approvers
- Source for ID cards identified (portal download or other), and standard confirmation wording agreed

## Risks

- Carrier portal screens change without notice, so scripts break. Monitor every run and hand to a person when a screen doesn't match.
- Portal terms or multi-factor rules may limit automated access
- Three portals with different screens multiply build and upkeep. Pilot Travelers first (largest share, about 40% of cases), then add the others.
- Misread email details (VIN, license number, date of birth) could submit a wrong change. The approval step shows the extracted values next to the source email.
- Pending underwriting cases could be forgotten without a follow-up process

## Measure after launch

- Median work time per endorsement (baseline 12.5 min; 28 team hours a week across 127 cases)
- Share of details retyped between Outlook, carrier portal and Epic (baseline 56% to Travelers portal, 81-90% portal to Epic)
- Portal-to-Epic mismatch rate (baseline up to 7.5% for Travelers)
- Share of cases with steps redone (baseline 8%)

## Decisions

| Decide | Rule | Source |
| --- | --- | --- |
| Change type(s) to record | Choose whatever the client asks for in the email. If the email asks for several changes, record each as its own change type. | team |
| Activity status after carrier response | Completed when the carrier accepts online (usual for vehicle and address changes). Pending underwriting when it goes to an underwriter (usual for new drivers until the MVR). Team described it two ways (by change type and by carrier outcome), probably consistent; confirm. Data: Add driver is Pending in 83% of 23 cases, Change mailing address is Completed in 100% of 12, Remove vehicle is Completed i | team + data |
| Which carrier portal to use | Use the portal of the carrier that holds the policy (Travelers, Liberty Mutual, The Hartford). The team did not say how this is chosen beyond that, and the reason for Liberty Mutual visits is unclear. | team |
| Whether to check carrier driver eligibility guidelines | For young drivers or drivers with violations, look up the carrier's driver eligibility guidelines before or while submitting, and send the change to the underwriter. | team |
| When the client may be told the change is done | Only after the carrier accepts the change. Never confirm coverage before that. | team |
| Whether staff approval is required | Policy forbids unattended actions, so approval is required before Epic writes, portal submissions and client emails. The team did not say which approvals they use today. | data |
| Whether a request needs coverage advice | Coverage advice is given only by licensed staff, so hand these requests to a person. | data |

## Still to answer before building

- How is the carrier chosen, and why do only some cases use the Liberty Mutual or Hartford portals? Data shows these as carrier variants, while the team links Liberty visits to eligibility lookups.
- How are cases pending underwriting followed up and tracked, and how soon?
- What does the client receive besides ID cards, where do the ID cards come from, and is there standard wording?
- Where are the rules written down, and which approvals are required today?
- Why is Microsoft Edge opened in some cases (adds about 3 min)?
- What payroll information is needed for audit-rated policies, who provides it, and how often does this happen?
- How often do young or high-violation driver exceptions occur? Team answers are split.
- Where are the carrier eligibility guidelines found, and can they be read without the portal?

## Exceptions

- When Driver is under 21 or has violations (frequency unclear: team answers split between almost never and sometimes or often): Hand to a person with the driver details and the carrier's eligibility guideline notes. The change goes to the underwriter and the status stays Pending underwriting.
- When New-driver changes, where about 83% end as Pending underwriting (about 25% of cases wait on underwriter or MVR): Set status Pending underwriting after approval and send no confirmation. Add the case to a pending list for staff follow-up. Follow-up timing is still an open question.
- When Mid-term change on an audit-rated policy (share not known): Stop and hand to a person to get payroll information first. Do not submit.
- When Information missing or unclear in the request (about 8% of cases redo steps): Hold the case, draft a request for the missing details to the client for approval, and resume when the reply arrives.
- When Request needs coverage advice, or the email holds several changes that conflict: Hand to licensed staff. The agent gives no coverage advice.
- When Policy's carrier is not Travelers, Liberty Mutual or The Hartford, or the portal screen does not match what the agent expects: Stop, keep the prepared data, and hand to a person to enter manually.

## Build with

- Power Automate: Orchestrates the flow, the Outlook connector, approval requests, and the Epic API calls (custom connector or HTTP)
- Microsoft 365 Copilot: Reads emails, splits multiple changes, flags driver exceptions, and drafts the client confirmation
- Power Automate desktop / browser automation (UI flows): Works the carrier portal screens, one script per carrier, starting with Travelers
- Applied Epic API: Reads policies and writes activities, status and premium

## Effort and return

- Size L, about 6-10 weeks (Power Automate, Copilot Studio / prompt design, Browser or UI automation, Applied Epic API, Insurance servicing process knowledge)
- Team time on this task now: 28 h/week; expected back: 4-10 h/week

## Evidence

- too many different paths for an agent to follow reliably; the training guide comes first
- 31% of cases follow the same steps (some skip a step)
- 28 team hours a week
- data is moved by hand from Microsoft Outlook to Travelers Agent Portal (56% retyped)
- 8% of cases redo steps
- 33% of cases need an extra lookup (an exception the agent must handle)