Chat Routing Improvements

Background

Three tiers of support, one chat window

Included Health provides virtual healthcare access, answers, and advocacy through a modern experience designed to treat people better. Members get their healthcare questions answered through our messaging platform, where three groups share the same thread:

• AI Assistant — our LLM-driven first line of support, answering questions and directing members to the right humans.
• Member Care Advocates (MCA) — a synchronous chat team handling billing and claims, coverage, and technical issues.
• Virtual Care Support (VCS) — an asynchronous team of nurses handling clinical requests like prescription refills, excuse notes, and referrals.

Problem

Stepping away meant starting over

When members stepped away from a live chat, MCAs would close the thread after several minutes. When members navigated back, they were often connected to a different MCA — one with no context on what had already been discussed.

That single behavior pushed both of our key metrics the wrong way:

• Average handle time increased — as new MCAs oriented themselves to the context of the chat, handle time went up.
• Chat MSAT decreased — members felt bounced around and frustrated by a fragmented experience as they moved among different MCAs, decreasing their trust.

Metrics Goals

What we set out to move

Designing Solutions

Mapping the member flow

Before touching a screen, I mapped every path a member could take out of a timed-out thread — dismissing the modal, waiting for their original advocate, or routing to whoever was free. The branching is where the real design problem lived.

Designing Solutions

The design was mostly writing

Two rounds of mocks, and the substantive change between them was language, not layout. V.1 explained what had happened to the member. V.2 asked them what they wanted — and moved the wait time from a warning into a commitment.

Both versions carried the same escape hatch — “If you need help sooner, you can chat with a different Care Team member. They’ll see all your chat history.” — because testing showed the assurance of carried-over context mattered as much as the wait itself.

Usability Testing

Validating the routing choice

The goal was to increase transparency around the path of a request and reduce the feeling of being “bounced around” among multiple MCAs. The open question: what type of context do members need to feel secure that their issue will be handled?

• Approach — 30-minute moderated interviews
• Platform — Google Meet with the Hey Marvin AI assistant
• Participants — 4 internal team members

Research Findings

Three things members needed

• Wait time transparency — for complex issues, members wanted to stick with the same advocate, since that person had context on their problem. Including a definitive max wait time, even a long one, made them more confident their issue would be addressed. Its absence pushed them to route to a new advocate.
• Personalization — members felt reassured by the advocate’s name, especially on higher-complexity issues.
• Importance of context — members responded positively to the assurance that a new advocate would have all their prior chat history.

We need to work with routing logic to find a way to provide more time transparency to members.

Designing Solutions

Rebuilding the queue behind it

A max wait time is a promise, and the backend had to be able to keep it. Working closely with engineering, we restructured the queue so a member could hold a place with a specific advocate rather than being dropped into general routing.

Designing Solutions

The advocate’s side

Routing a member back to the same advocate only works if that advocate can pick the thread up cleanly. The Care Team view surfaces a chat history summary and flags when a chat has been routed back at the member’s request.

Final Member Designs

What shipped

Final member experience

Outcomes

Where it landed