"Only one person broke down in tears during a client meeting today," my friend said, sipping his late December beer. "It was a good week."
My friend runs client implementations for a national benefits provider. I've been in his shoes and I didn't need him to elaborate. Some things you just nod at.
If you work in employer health and benefits, you know the Q4 Crunch: the push that starts in late summer, when your team begins preparing for every new client whose benefits program goes live on January 1. The project plans, the configuration checklists, the kickoff calls, the data conversations that were supposed to take two weeks and are now threatening to consume November. The engineer who hasn't taken a full weekend since October. The Slack message that arrives in the middle of the night, when only bad news is awake.
Every year, the team survives. Every February, someone says, "We need to fix this before next year." Every September, it happens again.
I've spent more than 25 years in the benefits industry, building systems, running teams, and talking to the CTOs who are still figuring out why this problem won't stay solved. And the honest answer is that most teams are only solving part of it.
Here's the part they've solved: eligibility. Most benefit providers have cobbled together something that handles the standard eligibility file well enough. It's not elegant. It's probably a custom script written by someone who may or may not still work there. But it runs. Eligibility, for most teams, has graduated from crisis to chronic condition.
Here's the part that's still wrecking them: everything else.
Leave history and takeover. Claims data. Service engagement records. Payroll files. Benefit payment data. Each of these arrives in its own format, on its own timeline, from a data source with its own priorities, which rarely include your January 1 deadline. They have their own Q4 Crunch to deal with, so they want you out of their task list as quickly as possible.
I’ll bet that the H&T file caused the tears. After all, it's caused more late nights in the absence management industry than any other single data source, and the reason is structural: the prior leave manager is contractually obligated to provide the history, but they're being replaced. They have every reason to get you what you technically asked for and no reason to make it easy. The format is whatever their system can export. The data is incomplete. Leave records that don't map to anyone on your current eligibility file are normal, not exceptional. In my experience, a 10% failure rate on a leave H&T load was considered a good day. The rest required manual review and cleanup before anyone could do anything useful with it.
This isn't a story about one company. It's the pattern at every absence management company onboarding a new client. The incentives produce the outcome. And H&T is just the absence management version. Claims data is voluminous, delayed, and has to be reconciled against members whose eligibility may have changed since the claim was filed. Service engagement data comes from partners whose systems weren't designed with your member identity model in mind. Payroll files touch finance systems that have their own cadence and their own definitions of "employee.” Each new data source doesn't add to your problem: it multiplies it, because now you're not just ingesting a file, you're reconciling it against everything you've already built.
In my experience, data integration represents roughly 70% of the technical and configuration work to onboard a new employer client.
But that's not the whole project: contracting, process design, and training all add time outside the technical scope. But if you want to know where the Q4 Crunch lives, it lives here.
The process for handling any of these data sources looks roughly the same every time. Someone schedules a kickoff meeting with six people on the invite, often more. Both sides bring their preferred data format, because each has already built something around it. There's a negotiation, polite at first, but leading to the same outcome: one side's format wins, usually the data provider's, because they own the data. An analyst maps the fields. Someone writes up the requirements. An engineer builds the integration.
Then the employer switches payroll vendors and you do it again.
When a CTO tells me "it's just a sprint for our data team," I understand what they mean. They're thinking about the engineer's time, which is real, and AI tools keep reducing that cost. What they're not counting is the analyst who spent three days reviewing a spec and asking questions, the project manager coordinating between four parties, the customer success manager making sure the employer relationship doesn't sour while the technical work drags on. They're not counting the second meeting when the format changed, or the third when the file arrived with fields missing.
They're not thinking about the same sprint, repeated, for every data source, for every employer, every year.
The sprint is real. It's just not the whole invoice.
The Q4 Crunch isn't a capacity issue or a planning failure. It's the predictable output of a system where everyone’s incentives are misaligned. Every party in your data supply chain is optimizing for something other than your data model, your operational needs, your go-live date. The prior leave manager wants to close out a client they're losing. The employer's HR data vendor has a backlog. The insurer's data team is responding to whoever is loudest that week. None of them are thinking about your January 1.
Your engineers are. And next year they will be again, because this isn't a technical problem. It's a structural one. And you can't vibe-code your way out of a structural problem.
Your team isn't bad at this. The system is designed to produce exactly this result.
Today we have time to take a breath. But September is coming.
