Overview
From 2018 to 2021, I was the sole UX designer on a series of conversational AI initiatives for DTE Energy — including four large-scale voice-only IVR systems.
This case study focuses on the High Bill experience: a high-volume, emotionally charged call type that was one of the biggest cost drivers in DTE's customer service operation.
The mandate was to reduce call volume. The constraint was that you couldn't do it by making the experience worse. People calling about a bill they didn't understand were already frustrated — and any system that felt dismissive or unhelpful would make things worse, not better.
The Context
DTE receives millions of calls a year about billing. A significant chunk of those are internally categorized as "High Bill" — customers who believe their bill is unusually high and want explanation, reassurance, or correction.
The existing assumption was intuitive enough: if someone selects a billing option, route them into the High Bill flow. Simple, predictable, efficient.
The problem was that it wasn't working. The High Bill flow was long — three to four minutes of scripted voice — and most of the people going through it didn't actually have a High Bill issue. They were calling about payment plans, unclear terminology, service changes, or something else entirely. Routing them all through the same experience created friction for customers and unnecessary load for the call center.
My Role
I owned the UX work end-to-end: research, interaction design, conversational flow design, testing, and the documentation that engineering and QA would build from.
I partnered closely with a product manager, backend engineers, IVR platform specialists, and DTE's internal UX, innovation, and regulatory teams. The regulatory piece mattered — certain phrasings had compliance implications, and I had to design within those constraints.
- Led end-to-end conversational UX design
- Conducted user research and CSR interviews
- Defined system structure, dialogue flows, and error recovery paths
- Designed and ran Wizard-of-Oz testing sessions
- Produced the source-of-truth documentation used by engineering and QA
Research & Sensemaking
The first thing I wanted to know was whether the "High Bill" bucket was actually a coherent category. It wasn't.
Only about one-third of callers in the High Bill path actually had a high bill issue. The rest were calling about something else — payment arrangements, confusing terminology, recent service changes, billing discrepancies — but had landed in this flow because the IVR menu was the closest match they could find.
That finding reframed the entire design problem. The question wasn't how to make the High Bill flow faster or clearer. It was how to stop routing the wrong two-thirds of callers into it in the first place.
The Key Design Decision
I rejected the premise that "High Bill" should function as an entry point. Instead, I proposed leading with an open-ended NLP intake question:
"In a short phrase, please tell me what you're calling about."
This let the system listen before committing the caller to anything. Callers with genuine High Bill issues would still reach that flow — but callers with different needs could be routed appropriately, much faster.
The tradeoff was real: NLP introduces routing risk that a deterministic menu doesn't. But the cost of an NLP misroute — a brief redirect — was dramatically lower than the cost of forcing hundreds of thousands of callers through a four-minute flow that had nothing to do with their actual problem.
Validating the Approach
To pressure-test the decision, I designed two competing prototypes and ran them against each other:
- A deterministic, menu-driven High Bill flow (the existing approach, refined)
- An NLP intake model with selective routing based on what callers said
Using Wizard-of-Oz testing with mock bills and real-scenario role-play, we evaluated routing accuracy, patience for longer flows, hang-up behavior, and overall caller experience.
The NLP intake consistently routed non-High-Bill callers minutes faster. And — importantly — callers who genuinely had a High Bill issue were more patient through the longer flow when they felt they'd been heard first.
Designing for Real-World Constraints
Implementation introduced a different set of problems. Backend latency was real. The IVR shared services with a web chatbot, which introduced interdependencies. And certain phrasings had regulatory requirements that constrained the dialogue.
I re-sequenced the flow to collect account information early — which the system needed anyway — and placed the NLP intake question at the point where that data was available. This masked backend processing time behind natural conversation rather than silence.
The final system was documented in full: a journey map, an interaction map, and a line-by-line dialogue spreadsheet that served as the QA source of truth. Every response, every branch, every recovery path — specified before a single line of backend code was written.
Results & Impact
- 30% reduction in High Bill–related call center volume
- ~2 million calls per year affected by the redesigned flow
- $1.5M+ first-year savings (client estimate)
- Measurable reduction in CSR time spent manually researching historical weather data
An unexpected benefit: the NLP intake created a new window into why customers were actually calling. What one stakeholder called a "window into the sewer pipe" — real, unfiltered customer language that could directly inform future automation and content improvements.
Reflection
The most important insight from this project wasn't about NLP or IVR design. It was about what happens when you question the premise.
"High Bill" wasn't a design problem — it was a categorization problem. The existing system had optimized around the wrong assumption, and all the flow improvements in the world wouldn't have fixed it. The only way to make real progress was to look at who was actually calling and what they actually needed.
Voice remains a primary interface for a lot of people — especially elderly, visually impaired, or time-constrained customers. It deserves the same level of care as any visual system. And a well-designed voice experience doesn't just route people efficiently. It respects why they showed up.