The Human Side of IVR
Context: Solo design exploration - behavioral health IVR design
Tools: Miro (Logic & Architecture Mapping), Pages / PDF Expert, Amazon Connect & Lex Developer Documentation (Reference)
References: Conversation Design Institute (CDI) Foundations coursework and methodology materials; IVR flow conventions research
The Starting Point
I've navigated the medical system during high-stakes moments. I know what it feels like to need support and find it, and what it feels like to need support and not find it. That experience is why behavioral health felt like the right context to learn IVR design in, not just a technically interesting problem, but a human one.
This sample was built as a portfolio piece to demonstrate competence in hybrid deterministic/NLU IVR design using Amazon Connect. The design decisions reflect what I actually believe good behavioral health call design requires. While this exploration represents my first architectural blueprint for an IVR, it is fully grounded in my existing experience with systems thinking, error-state analysis, and multi-turn conversational logic derived from my hands-on work in LLM evaluation, and a clear sense that behavioral health is a context that demands more care than most.
Core Design Decisions
Why Hybrid: Intent Classification & Cascading Fallbacks
A fully deterministic (menu-driven) approach would have been the safer choice technically, and the more predictable one to document, but I chose hybrid because the user context made it the better design.A caller accessing behavioral health support is often already experiencing distress. Presenting a rigid menu as the first interaction adds friction at exactly the wrong moment. NLU-first allows the system to meet the caller where they are, capturing natural language like "I need to find a therapist" or "I'm not doing well", rather than asking them to navigate options before they've said anything.
The deterministic fallback exists because NLU fails. When it does (particularly in a health context) the consequence of misrouting is significant. A caller who says "I need help" and ends up in the wrong queue has not been served. The hybrid model preserves the warmth of natural language entry while ensuring that low-confidence inputs fall back to structured, reliable routing rather than guessing.
To mitigate the risk of misrouting critical user intents, I established a strict Confidence Scoring Logic Gateway (>0.80 direct route / 0.50–0.79 explicit confirmation loop / <0.50 deterministic fallback). This architecture ensures the system executes choices with high deterministic confidence, dropping down to structured routing only when natural language processing signals ambiguity.
Why Crisis Is a Global Priority Interrupt
This was a deliberate, non-negotiable design decision that I made at the start of the project, not something added later.In a behavioral health IVR, a caller may be in crisis at any point in the call, not just at the beginning. A system that can only detect a crisis at the initial intent capture and cannot respond to it mid-flow is not safe. The crisis interrupt bypasses all confirmation logic and routes directly to a live agent because no routing efficiency is worth the risk of adding friction between a person in crisis and support.
This decision reflects a principle I hold about conversational design in health contexts: the system's job is never to optimize for call containment at the expense of safety.
The Retry Cap: Two Attempts
This was the decision I was least certain about.Two retries is a more aggressive cap than some enterprise implementations use. I chose it for two reasons. First, cognitive load: a caller who has failed twice to communicate their intent to a system is already frustrated. A third attempt rarely improves outcomes and often increases distress, particularly in a behavioral health context. Secondly, it establishes a definitive boundary for conversational error loops. If the system fails to resolve intent classification after two turns, the logic triggers a graceful handoff to a human agent rather than trapping the user in an adversarial loop.
I acknowledge this is a design opinion and that the right number may vary by context, call volume, and agent capacity. In a production environment, I would expect this to be tested and iterated against real data.
Keeping the Flow Simple
I made a deliberate choice to prioritize clarity over comprehensiveness. This flow covers the core use case, a member calling to find a behavioral health provider, with careful handling for the moments most likely to fail: low-confidence inputs, invalid structured data, and crisis. It does not attempt to cover every possible caller scenario.That's partly a portfolio decision, but it's also how I think about design: a clean flow that handles its scope reliably is more useful than an ambitious one with gaps.
What I Would Do Differently / Explore Next:
- Add system utterances. The current flow documents routing logic but not the actual prompt copy, what the system says at each node. A production-ready version would include this, and it's the next layer of work I'd want to build.
- Test the retry cap. Two retries is a reasoned choice, not a validated one. I'd want to see real data on where callers drop off and adjust accordingly.
- Explore authentication. This flow assumes a known member. A fuller version would address what happens with unrecognized callers, and how authentication integrates without adding burden at the start of a distress call.
- Live refinement with platform tooling. Building this in Miro gave me a clear view of the logic, but working directly in Amazon Connect would surface implementation constraints I couldn't fully anticipate from documentation alone.