Slàinte Mhath — pronounced "SLAN-cha vah" — is a traditional Gaelic toast meaning "good health to you." It also turned out to be exactly the design challenge: deliver good health, conversationally, to medical-billing administrators across multiple states whose Medicaid programs varied wildly in eligibility rules, provider requirements, languages, and enrollment processes. Our client was a Medicaid administrative services aggregator serving multiple states, and they needed a scalable way to deliver customized, fully functional provider-facing voice systems without rebuilding from scratch for every state.

What they asked for

The brief was deceptively simple: build a voice-forward, AI-assisted Medicaid provider services system for a multi-state aggregator. The complications were structural.

This wasn't one project — it was effectively a collection of projects. Each state's Medicaid program was its own client of our client, and while there were core functions and requirements common to all state Medicaid programs (provider enrollment, authentication, claims, member lookup), the particular ways each program implemented those functions varied considerably. A shared category of project could have very different eligibility requirements, different forms of accepted identification, different multilingual demands. Some states needed English-only; others required combinations of Spanish, Vietnamese, Tagalog, or whatever the local Medicaid demographic most needed.

The asking-for layer was straightforward: deliver this system, customized per state, on schedule, within budget. The actually-needed layer was different: find a way to design once and deploy many times, without the per-state customization eating the entire engineering budget. The client didn't articulate the second framing in the brief — they articulated the first. Recognizing that the second was the real problem was the work that had to happen before any visible design could begin.

What we envisioned

If the real problem was design once, deploy many times, the architecture had to be modular at the level where states diverged and shared at the level where federal Medicaid imposed common ground. That insight produced the design's core decision.

A scaffold framework, not a template. A template assumes minor customization on top of fixed structure. A scaffold assumes major customization on top of fixed patterns. The framework would define the conversational architecture for every common Medicaid function — provider enrollment, provider authentication, claims lookup, member lookup — and leave the state-specific variations as configurable layers within each function. Each state's deployment would inherit the framework's design discipline while expressing the state's particular eligibility rules, identification methods, and language combinations.

Voice-forward by design and necessity. The users were medical-billing administrators processing dozens of patient records a day, calling from desk phones with paperwork in front of them. Hands full, eyes on records. A chatbot would have been the wrong answer regardless of trend pressure — what they needed was a voice-forward system that could keep pace with their workflow without demanding a single tap, click, or glance at a screen. Good conversation design means choosing the right modality for the user's actual context, not the modality that's easiest to demo.

There were edge cases — questions about enrollment status, particular claims, or forms requiring completion — where reference to a state's Medicaid web site became unavoidable. Those got handled as deliberate handoffs rather than as system limitations.

Multilingual capability built into the framework, not bolted on. Some states required English-only; others needed Spanish, Vietnamese, Tagalog, or some combination. The framework treated language as a first-class configuration parameter rather than as a translation layer applied after design. That decision had downstream implications for prompt authoring, persona consistency, and call-flow logic that would have been expensive to retrofit if language hadn't been architectural from the start.

Together, these three decisions defined the design space within which each state's deployment could be built efficiently — and within which the framework's overall design discipline could remain coherent regardless of how many states eventually came online.

​What we built

The framework organized around the four common Medicaid functions, each designed once at the architectural level and configurable at the state-specific level.

Provider enrollment. The eligibility requirements, accepted forms, and identification standards for joining a state's Medicaid program. This information remained largely static across states, but couldn't be acted on within the IVR itself — signature requirements and completed forms meant the system's role was guidance and referral rather than completion. The design handled this honestly: the framework escorted providers to the appropriate state web resources rather than pretending to handle what couldn't be handled by voice.

Provider authentication. The accepted forms of identification varied from state to state — each state has its own Provider ID method in addition to the National Provider ID — but the variation followed detectable patterns. The framework's authentication logic identified those patterns and accommodated them through configuration rather than through per-state rebuilding. A new state's authentication scheme could typically be added to the framework rather than designed from scratch.

Claims. Lookup criteria varied by state, but every state would accept lookup by claim number. That commonality became the framework's anchor: claim-number lookup as the universal entry point, with state-specific alternative criteria layered as configurable secondary options. Providers calling from any state could always start with the claim number; states with additional lookup options got those exposed contextually.

Member lookup. This was the actual Medicaid patient receiving services — the lookup used either to retrieve claims and their statuses, or to determine eligibility for particular services under that state's Medicaid guidelines. The framework's member-lookup logic handled both use cases through a unified conversational pattern, with state-specific eligibility rules expressed as configuration rather than as parallel design tracks.

The architectural goal across all four was shared discipline, expressed differently per state. The framework imposed consistency on the conversational patterns; the configurations expressed each state's particularity. The skeleton can be detected from this representative Intent Mapping page — a typical configuration showing the framework as it would begin in any given state's deployment.

The result was that adding a new state to the platform became a matter of configuration and customization, not of rebuilding. Designers could focus their attention on the genuinely state-specific elements without re-solving the same conversational design problems for every new deployment.

What it achieved

The scaffold framework delivered exactly what the underlying problem required: design discipline once, customized deployment many times. Each state Medicaid program received a fully functional, voice-forward provider services IVR tailored to its particular eligibility rules, identification methods, language requirements, and program structures — without the design and development teams rebuilding the conversational architecture from scratch for every state.

The framework also reshaped how the project's pre-design work happened. With the architectural questions answered once at the framework level, designers and project management could focus the per-state pre-design process on gathering, documenting, and clarifying state-specific requirements rather than on re-deriving the conversational logic that should already have been settled. By the time designers were ready to begin the active interaction-flow work, fingers-to-the-keyboard time was minimal and development could begin sooner. The efficiency wasn't a happy accident — it was the architectural decision paying off in operational practice.

The modernization-of-stack dimension paid off in parallel. States that had been operating on late-1980s DTMF systems gained speech-enabled, AI-assisted capabilities — provider experiences that finally matched the rest of healthcare's voice infrastructure rather than lagging two decades behind. The aging underlying APIs didn't disappear, but they were now wrapped in a conversational layer that made them usable for the modern medical-billing workflows the providers were actually doing.

The deeper achievement was demonstrating that conversational AI for regulated, multi-jurisdictional services doesn't require choosing between scalability and customization. Done right, the architecture provides both — a unified design discipline expressed through state-specific configurations, with each deployment honoring federal common ground while accommodating each state's particular implementation. That principle generalizes well beyond Medicaid: any voice-driven public-services platform serving multiple jurisdictions faces the same scalability-versus-customization tension, and the same kind of scaffold-framework thinking can dissolve it.