A benefits brokerage automated its January: carrier data and SSO across forty employer clients

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

Every January, open enrollment compresses a year of benefits administration into a few weeks. This brokerage serves forty employer clients: it designs benefit packages, fields employee questions, and — the January problem — translates each employer's HRIS export into elections inside each carrier's portal, then wires up SSO so employees can reach those portals. The work is skilled, repetitive, and unforgiving: one mistyped dependent row becomes a claim dispute in March. The team had absorbed the workload with overtime and temp staff, and the brokerage's growth was capped by how much January it could survive.

What it was costing

Every open enrollment, the brokerage manually keyed elections from employer HRIS exports into carrier portals and built SSO links by hand; January consumed the whole team, and one mistyped dependent row became a claim problem in March.

What they could see

• January consumed the entire team; other renewals and client questions waited until February.
• Keying errors surfaced months later as carrier corrections and employee claim problems nobody could trace.
• Each employer's HRIS export arrived in a different shape; normalization happened in the keyer's head.
• SSO links were assembled by hand per employer, so employees at smaller clients just phoned the carrier instead.
• There was no answer to how every election reached every carrier — reconciliation meant re-reading portals.

The constraints we worked inside

• Each employer's HRIS export differs in format and quality; the pipeline must normalize without assuming the source is clean.
• Carrier portals are third-party with file-based or API-based intake of varying quality — per-carrier adapters are unavoidable.
• Benefits data is sensitive; the sync layer must be auditable row by row, with no spreadsheet staging.

What had been tried before

Hired temporary data-entry staff every January to key elections into carrier portals.

Accuracy held while supervised and slipped when it didn't; the January after a hiring miss produced dependent errors that surfaced as March claim problems.

Standardized a spreadsheet template and asked employer HR teams to fill it.

Forty employers returned forty interpretations of the template; validation happened at keying time anyway, and the brokerage still carried the reconciliation burden.

Bought an enrollment-platform licence from a carrier-affiliated vendor for the largest clients.

The platform served that carrier's intake well and everyone else poorly, and exporting audit-ready records back out defeated the point of having them.

What we proposed

We proposed a sync pipeline with two explicit boundaries: an adapter per HRIS source at the edge, and an adapter per carrier at delivery. Each HRIS adapter validates its export and surfaces problems as reviewable rows the broker approves or rejects — bad data gets caught at ingestion, not at the carrier in March. Carrier adapters isolate each portal's file or API intake behind tests, so a format change is a contained fix rather than a January emergency. The same identity layer that authenticates employer users brokers SSO into carrier portals where supported, giving one user model and one audit trail. Every row is auditable; no spreadsheet staging anywhere.

Just as important is what we ruled out, and why:

• A commercial benefits-enrollment platform covering HRIS-to-carrier sync — Coverage was strongest exactly where the brokerage's margins were thinnest, the per-employee pricing scales against forty employers, and row-level audit was not exportable.
• One universal HRIS normalization format all employers must adopt — The brokerage controls employers' systems, not the employers; a mandated format would take years of negotiation and still miss the messy reality each January.
• Robotic process automation driving the carrier portals' screens — Portal UIs change without notice and RPA breaks invisibly — a silent failure in this domain is a claim dispute, which is the exact cost we were eliminating.

How the work ran

Delivered by the systems pod — 2 engineers over 14 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

Node.js

The pipeline is glue with judgment — parsing, validating, transforming — and one runtime let two engineers cover adapters, workers, and review tooling without seams.

TypeScript

Each adapter's output is a contract with a carrier's intake process; discriminated unions state that contract explicitly, which is what keeps it keepable across forty employers' exports and a dozen carriers.

Postgres

Row-level audit is a promise to employers and carriers; a relational store with append-only history tables makes every election's journey reconstructable.

SAML/OIDC brokering

Employers authenticate against one brokerage identity layer that brokers into carrier portals where supported — one credential model instead of forty hand-built links.

Queue-based sync workers

January is bursty by nature; queued workers with retries absorbed carrier slowdowns and late exports without anyone watching a batch job at midnight.

What went wrong

How we worked together

Cadence

Twice-weekly checkpoint calls through the build, then daily fifteen-minute syncs through the January enrollment itself, with a live reconciliation dashboard open between us.

Client side

The brokerage's operations director owned carrier relationships and January triage; one senior broker reviewed exception rows daily; two employer HR contacts tested exports.

Decisions

Exceptions followed a standing rule — when in doubt, review rather than transmit; anything ambiguous went to the operations director before it reached a carrier.

They provided

Sample exports from every employer's HRIS, carrier portal documentation and contacts, security review time, and the team's January availability for the live run.

What changed

The headline: forty employer clients' elections flowing through adapters with row-level audit, reviewed by exception — Manual January → pipeline-run enrollment, read from Enrollment reconciliation report. A second check: keyed-data errors requiring carrier correction at −81%.

The exceptions dashboard is January's morning meeting now. The team reviews flagged rows instead of keying forty files, and the question of whether everything landed has an answer you can export. Errors that once surfaced as March claim disputes surface in December, where they cost minutes instead of relationships. The brokerage also sells differently — auditable, self-running enrollment is now part of how they win employer clients, and the pipeline's capacity grows with the client list instead of with the hiring calendar.

The result was read from Enrollment reconciliation report against the pre-engagement baseline over the stated window, with a guardrail check on keyed-data errors requiring carrier correction. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The pipeline repository with per-employer HRIS adapters and per-carrier intake adapters
• Carrier credentials and portal contact list under the brokerage's own vault
• The exception-review workflow and reconciliation report the operations director runs daily
• Runbook for adding an employer or a carrier, including the audit checklist