Benefits Enrollment Events: Every Request Decided on Its Own Record

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

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.

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
• OneDrive
• Outlook
• 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.