---
title: "Benefits Life Event Request Review With AI Agents | Kylon"
description: "How a benefits team reviews qualifying life event requests, documents and premium changes in one room, with each request decided from its own record by a person."
url: "https://kylon.io/use-cases/benefits-enrollment-events"
language: "en"
---
[HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>Benefits Enrollment Events: Every Request Decided on Its Own Record
Use Case8 min read
# Benefits Enrollment Events: Every Request Decided on Its Own Record
Life event requests, supporting documents, premium changes and closeout notes run through one Kylon room. Agents check each request against its own fields and documents and rebuild every figure from the HubSpot records, and the benefits manager approves each disposition.
[Get started](https://app.kylon.io/sign-up)
Kylon TeamProduct
November 6, 2026
## Each life event request has its own documents and its own answer
When an employee has a qualifying life event, such as a birth, a marriage or a loss of other coverage, they ask the benefits team to change their benefits mid-year. Each request is a deal in HubSpot, with fields for the event type, plan, state, whether a dependent is already covered and whether it duplicates another request. Supporting documents sit in OneDrive, and the review policy in Google Drive says what each event type needs and how the premium change is calculated.
Requests arrive in batches, and the tempting shortcut is to treat a request like the one next to it. Two requests from the same household, or the same event type a day apart, look alike, but each has its own fields and its own documents. Later in the cycle the shortcuts compound: a document batch clears some requests, a plan becomes available in a new state, event dates are corrected, and the premium totals get rebuilt from memory instead of from the records.
## Who works in the room
People
- Benefits manager
Owns the review cycle, approves every disposition and signs the closeout
- Benefits specialists
Work each request with the employee and confirm corrected event dates
- Payroll partner
Confirms premium changes before any deduction moves
Agents
- FinRequest triage
Disposes each request from its own HubSpot fields and its own documents in OneDrive, and writes the approved fields
[HubSpot](https://kylon.io/integrations/hubspot)OneDriveGoogle Drive
- NovaPremium reconciler
Computes the annualized premium change, reviews the processing manifest and builds the closeout notes from a fresh listing of every request
[HubSpot](https://kylon.io/integrations/hubspot)Google Drive
- MycoNotice reader
Reads notices in Drive and mail in Outlook as evidence, works out which requests each one affects and brings specialists' flags in from Slack
OutlookGoogle Drive[Slack](https://kylon.io/integrations/slack)
Fin is the default agent, so an unaddressed question about a request goes to it. Premium figures, the manifest and the closeout notes belong to Nova, and notices and mail go to Myco first. Fin and Nova write to HubSpot under a lasting grant the benefits manager approved, and every write follows an approval in the thread. OneDrive and Outlook are read as evidence only. A new notice becomes a thread from Myco to Fin, and its first message names the requests the notice affects.
## From triage to twelve closeout notes
The policy is numbered by section, and the room guidelines tell each agent which section applies at each stage.
```mermaid
flowchart TD
triage["Fin disposes each request from
its own fields and documents"]
ok1["Benefits manager approves
before HubSpot fields are set"]
premium["Nova computes the premium change
for every request to be processed"]
manifest["Nova checks the manifest against
dispositions and premiums"]
ok2["Benefits manager approves the note"]
notice([A document batch and a new plan
option arrive in the same week])
affect["Myco works out which requests
each notice affects"]
dates["Benefits specialist confirms
corrected dates with the employee"]
recheck["Fin re-checks each affected
request once, from its own fields"]
ok3["Benefits manager approves each change"]
recon["Nova lists every request fresh
and recomputes each premium"]
payroll["Payroll partner confirms figures
before deductions change"]
close["Nova writes one note per plan
and state, empty ones included"]
sign["Benefits manager signs the cycle"]
triage --> ok1 --> premium --> manifest --> ok2 --> affect
notice -.- affect
affect & dates --> recheck
recheck --> ok3 --> recon --> payroll --> close --> sign
class triage,premium,manifest,affect,recheck,recon,close agent
class ok1,ok2,dates,ok3,payroll,sign person
class notice event
classDef agent fill:#FFFFFF,stroke:#DCD3C8,color:#1B1712
classDef person fill:#EEF0E3,stroke:#6E7447,color:#1B1712
classDef event fill:#F4ECDD,stroke:#F4ECDD,color:#564C42
```
| Stage | What happens | Who acts | Who decides |
| --- | --- | --- | --- |
| Triage | Each of the 30 requests is disposed from its own fields and the OneDrive document search, and a request the search does not return has no document on file | Fin | The benefits manager approves before HubSpot fields are set |
| Premium impact | The annualized premium change is computed for every request that will be processed, and the others carry none | Nova | The benefits manager reviews the list |
| Manifest review | The generated processing manifest is checked against current dispositions and premiums, and the correction count is noted in HubSpot | Nova | The benefits manager approves the note |
| Reversals | A document batch and a new California plan option trigger a re-check of every California request and the one other cleared request | Fin, from Myco's reading of the notices | The benefits manager approves each change |
| Date corrections | Four requests with corrected event dates are re-checked from their own fields | Fin | The benefits specialist confirms the dates with the employee |
| Reconciliation | All 30 requests are listed fresh from HubSpot and the premium changes recomputed | Nova | Payroll confirms the figures before deductions change |
| Closeout | Counts and premium totals are built per plan and per plan and state, with one HubSpot note for each of the 12 combinations, including empty ones | Nova | The benefits manager signs the cycle |
Stages of one life event review cycle. Request IDs, plans, states and counts in this example are illustrative.
## A document batch and a plan change in the same week
The two notices overlap, and the overlap is where double counting starts. A document batch clears three requests, two of them in California, and in the same week HDHP Saver becomes available there. Fin re-checks every California request with the new plan option, which already covers the two California requests in the batch, and then re-checks the third request on its own. Nothing is checked twice and nothing is skipped.
Reconciliation is never done from memory. When the reconciliation notice arrives, Nova lists all 30 requests fresh from HubSpot and recomputes every premium change, rather than adjusting figures it worked out weeks earlier. At closeout, a plan and state with no requests still gets its note, with a count of zero, so the twelve notes add up to the whole cycle and nothing reads as missing.
## What the checks catch
- A disposition copied from a similar neighboring request instead of derived from the request's own fields
- A request the OneDrive document search does not return, which has no document on file even when a related request does
- A California request in the document batch counted twice, once for the document and once for the plan change
- Premium figures carried over from earlier results instead of recomputed from a fresh listing of every request
- A plan and state combination with no requests, which still needs its closeout note
## What stays with people
- Approving every disposition before HubSpot changes
- Talking with employees about their event and their options, which benefits specialists do
- Confirming premium changes before payroll deductions move
- Signing the cycle closeout
## Integrations in this workflow
Kylon is not a benefits administration system, and it does not replace the one your carrier or broker runs. It sits across the records and documents the team already uses and holds the review between them. It does not advise employees on their choices.
- Google Drive
- [HubSpot](https://kylon.io/integrations/hubspot)
- OneDrive
- Outlook
- [Slack](https://kylon.io/integrations/slack)
- **HubSpot** holds each life event request as a deal, with its disposition, premium fields and closeout notes
- **OneDrive** holds the supporting documents, searched and read as evidence only
- **Outlook** carries employee and carrier mail, read as evidence and never answered by an agent
- **Google Drive** keeps the benefits review policy, the processing manifest and each notice
- **Slack** is where benefits specialists flag a request that needs a second look
## Where to start
Run one review cycle. Connect HubSpot with a lasting grant the benefits manager approves, let the room search the OneDrive folder for supporting documents, and write a single rule into the room guidelines: every request is decided from its own fields and documents, and the benefits manager approves each disposition before a field changes.
> “Thirty requests, thirty separate answers, and a closeout that adds up to the records.”
## Set it up with your agent
Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.
Set-up prompt
Set up our benefits enrollment review desk in this Room. Take it one step at a time and wait for my OK before you move on.
1. Connect Google Drive, HubSpot, OneDrive, Outlook and Slack. Tell me which still need connecting, and confirm HubSpot has a lasting grant the benefits manager approves.
2. Ask me who works this desk: a benefits manager, benefits specialists who talk with employees about event dates, and a payroll partner who confirms premium figures. Help me invite them to this Room.
3. Build a Life Event Review App with columns for Request, Event, Plan and State, and Status, one record per HubSpot deal.
4. Dispose each request from its own HubSpot fields and its own OneDrive documents. Flag any request whose document search returns nothing. Show me every request that fails or needs a second look.
5. Draft dispositions, premium changes, manifest corrections and closeout notes for review. Write no HubSpot field until the benefits manager approves that request in this thread. Let the payroll partner confirm figures before any deduction moves.
6. Write into this Room's guideline that every request is decided from its own fields and documents, that the benefits manager approves each disposition before a field changes, and that payroll confirms figures before deductions move.
7. After one clean cycle, offer to turn the triage and reconciliation steps into an Automation.
Before you start, ask me for our rules one at a time.
[Get started](https://app.kylon.io/sign-up)
Your first company harness. Where humans and agents run your business together.
[Get started](https://app.kylon.io/sign-up)
## More Use Cases
[View all](https://kylon.io/use-cases)
[
### Equity Grant Administration: Grant Records That Match the Consents and Memos
Option grants in Notion, signed consents in Box and HR notices in Outlook, kept in agreement through a repricing memo and a batch of leave corrections. Agents propose each change in one Kylon room, and the equity administrator approves it.
People operationsFinance operations
](https://kylon.io/use-cases/equity-grant-administration)[
### Payroll Corrections: Each Fix Paid in the Right Batch or Carried to the Next Period
A payroll correction cycle where hours come from the manager's attestation, held items are recomputed when rates change, and nothing still held leaves the cycle without a carry-to period. Every batch waits for the payroll manager.
People operationsFinance operations
](https://kylon.io/use-cases/payroll-corrections)