Member expectations shifted toward digital self-service while the platform stayed fixed
Healthcare members now expect the same digital, self-service and omnichannel experiences they receive from banking, retail and technology companies. Contact centers are no longer viewed as cost centers but as strategic platforms for member engagement, care coordination and customer experience.
Our client’s traditional Avaya environment was not built for that. Infrastructure and maintenance costs were high, spanning hardware, software upgrades, licensing and disaster recovery. Scalability was limited, which mattered acutely during seasonal enrollment spikes and Medicaid redeterminations. Introducing new IVR capabilities, communication channels or member services meant lengthy implementation cycles.
Supporting remote and distributed agents had become harder following the shift to hybrid work models. Native AI and automation capabilities were limited, restricting opportunities to improve self-service containment and agent productivity. And integrating with modern cloud ecosystems, analytics platforms and digital engagement channels remained difficult.
Multiple plans, states and rule sets turned every change into its own program
The complexity was structural rather than technical. The client’s contact center environment supported multiple plans, states and member populations, each with its own business rules, call flows, prompts, routing needs and operational nuances. A single change rarely stayed single. Migrating an estate of that shape in one move would have concentrated risk across millions of members and numerous business units, IVRs, telephony environments and applications at the same time.
An automation-led migration designed for reuse across plans
At the center of our approach was a Chassis-based delivery model: a reusable architectural foundation made up of configurable modules, microservices and integration patterns, rather than a migration built from scratch for every health plan.
The Chassis included reusable components across Amazon Connect call flows, Amazon Lex conversational bots, AWS Lambda functions, routing logic, API integrations, error handling patterns, member authentication flows, common IVR utilities, logging and monitoring frameworks, and configuration-driven plan-specific behavior. That gave the client a common baseline architecture while still supporting the unique requirements of each plan. Each plan could be assembled from proven modules and then customized through configuration, reducing duplication and improving consistency.
Underneath it, a modern AWS-native architecture carried the workload. Amazon Connect served as the cloud-native platform for call routing, IVR orchestration, queue management and agent experience. Amazon Lex enabled conversational IVR, moving the member experience beyond traditional keypad-driven interactions. AWS Lambda functions supported backend business logic, integrations, validations and routing decisions, designed as reusable microservices so that capabilities such as member lookup, plan identification, authentication support, business rule execution and API orchestration could be shared across plans.
