Most group medical support volume traces back to three predictable moments: adding a family member, discovering a hospital is out of network, and hitting an exclusion at the counter. Each one is a product problem before it is a support problem.
Ask anyone who has run support for an employer medical product where the tickets come from and you will hear the same three answers: dependents, networks and exclusions. Not billing, not documents, not passwords. Family members who are not covered when the employee thought they were, hospitals that turn out to be off-panel at the worst possible moment, and treatments the policy never included but nobody read the table to find out.
The useful insight is not that these tickets exist — it is that all three are generated at predictable moments by predictable information gaps. That makes them product problems. A platform embedding group medical can design most of this volume out of the queue before a support team ever sees it, and the platforms that do will run health cover at a fraction of the operating cost of those that treat support as the fix.
Ticket one: the dependent who was never added
The single most painful group medical ticket is a spouse or newborn arriving at a hospital and being told they have no cover. The root cause is almost never the insurer. It is the enrolment flow: the employee assumed dependents were automatic, or HR collected the names but never submitted them, or the addition was submitted after the event that needed it.
Dependents fail because they are a second transaction disguised as part of the first. Covering an employee happens once, at onboarding, driven by the employer's obligation. Covering a family changes shape over time — marriages, births, a parent joining the household — and each change is a mini-enrolment with its own documents, its own effective date and often its own premium adjustment.
The design response is to treat dependent management as a first-class journey, not a support workflow. That means an explicit dependents step at enrolment that forces a yes-or-no decision rather than defaulting silently to employee-only; a self-serve add-dependent flow with the required documents listed upfront; and clear effective-date rules shown at the moment of addition, because a dependent added today is rarely covered yesterday. Every one of those screens replaces a future ticket that would have arrived as an emergency.
Ticket two: the network discovered at the reception desk
Network tickets share a signature: they arrive from a hospital lobby. The member chose a provider, travelled there, and learned at reception that the facility is out of network for their plan class — or in network for consultations but not for the procedure they came for.
The information existed the whole time. Insurers publish network lists. The failure is presentational: the list lives in a PDF several clicks from the member, organised by the insurer's internal categories rather than by the question the member actually has, which is always some version of — can I go here, now, for this?
Platforms that embed medical cover hold an advantage here, because they control the surface the member already uses. A searchable network directory inside the product, filtered to the member's actual plan class, answers the question before the journey to the wrong hospital begins. The harder discipline is keeping it current: networks change mid-year as insurers and providers renegotiate, and a stale directory is worse than none because it converts a confusion ticket into a trust problem. Whatever feed or file the insurer provides, treat its refresh cadence as part of the integration contract, not an afterthought.
Ticket three: the exclusion nobody read
Exclusions generate fewer tickets than the first two categories but the angriest ones, because the member has usually already received treatment and is now holding a bill. Common flashpoints are predictable: pre-existing condition windows, dental and optical assumed to be included when they are riders, cosmetic-adjacent procedures, and annual sub-limits on specific benefit lines that exhaust mid-year.
No design can make an exclusion pleasant. What design can do is move the discovery earlier. A benefits table written in plain language, surfaced at enrolment rather than buried in policy wording, converts the worst version of this ticket — anger after treatment — into the mild version, a question before it. Sub-limit visibility helps too: a member who can see how much of an annual benefit remains behaves differently from one who finds out at zero.
Every exclusion ticket is a disclosure that happened too late. The policy did not change at the hospital counter — the member's knowledge of it did.
What the pattern tells you
Three different tickets, one shared anatomy: a fact about the cover that was true from day one, discovered at the moment of need instead of the moment of purchase. Dependents, networks and exclusions are simply the three facts members most often need under stress.
That framing turns support metrics into a product roadmap. Classify group medical tickets against these three categories for a month and you will find the ranking tells you exactly which journey to build next. In our experience of designing these flows, the deflection order that usually makes sense is dependents first — highest emotional stakes, most self-serviceable — then network search, then benefits-table clarity. Not because exclusions matter least, but because the first two have crisp product answers while the third is a writing problem as much as a software one.
None of this eliminates support. Claims disputes, escalations and genuine edge cases will always need humans, and a member mid-emergency deserves one. The goal is narrower and more achievable: stop paying people to answer, ticket after ticket, the three questions the product could have answered on its own.