Intermittent Connectivity
Foundational journey-mapping research across customer and agent experiences that secured $3M in executive funding for a unified data architecture.
Nobody could act on a problem nobody had agreed how to define
Intermittent connectivity issues, the kind that don’t fully knock out service but make it unreliable, were consuming a large share of Charter’s support budget and directly damaging the customer experience. The organization couldn’t act on it effectively for a more basic reason: there was no shared definition of what “intermittent connectivity” even meant, and no standardized way to diagnose it. Customer-facing teams, support, and engineering each approached the same problem differently. My job was to build the first end-to-end, evidence-based picture of that problem before anyone tried to solve it.
Three phases, from raw signal to a shared map everyone could act on
I ran a three-phase mixed-methods investigation. The first phase covered research and discovery: 21 subject-matter-expert interviews across 33 sessions, plus a content and analytics audit at the exact moments customers hit friction. The second phase tested the experience directly: a secret-shopper study across five support channels using four dedicated test accounts, paired with an analysis of 17 recorded support calls covering time-on-task, resolution steps, and agent helpfulness. The third phase turned all of it into a current-state journey and data blueprint, built jointly with content design so it would be legible to executives as well as researchers.
The same outage looked like a different problem from every seat
- 01Symptom definition disconnect.
No internal alignment on how intermittent connectivity was defined or recognized across teams. That produced inconsistent customer messaging and escalation paths that didn't reliably reach the right fix.
- 02Telemetry data was going unused.
The signals needed to proactively catch intermittent issues already existed, but weren't being tagged or classified in a way that triggered any proactive customer communication.
- 03No standardized architecture across tools.
Customer-facing and agent-facing systems held fragmented, inconsistent data about the same issue. That made repeatable, proactive resolution a structural problem that no amount of agent training could fix on its own.
The customer's experience and the agent's experience were mirror images of the same failure. A customer describes a problem that comes and goes, while the agent's tools show no issue at all in that instant. Neither side was wrong; the systems simply weren't built to see the same thing at the same time.
A three-part plan, and funding to build the architecture behind it
The recommendation was deliberately three-pronged. First, establish one working definition of intermittent connectivity and equip frontline teams to act on it directly. Second, use telemetry to classify severity automatically and trigger proactive outreach instead of waiting for a customer to call. Third, consolidate the underlying data into a single source of truth so every team was finally looking at the same picture. This research secured $3M in executive funding for that architecture, directly contributed to a Rule-Based Engine (paired with a custom LLM) being commissioned to replace the legacy system, and projected a 45%+ reduction in related churn along with a one-third reduction in associated support costs within two years. It also became the catalyst for a standing “Experience Tiger Team,” which has since taken on the billing and complete-outage journeys using the same model.