A US health benefits provider: Avaya to Genesys Cloud CX, with an immense self-service IVR

The provider's contact centre ran on an on-premises Avaya system that had reached the end of its life, with a separate third-party IVR, a separate voice firewall, Verint for workforce and quality management, and a fax service for the documents providers ask for every day. It was the first phase of a multi-year modernisation that the client summed up as becoming best at the basics: replace the platform, keep everything callers relied on, and build the foundation for AI and new channels in later phases.

Keeping everything callers relied on was the hard part. The IVR was immense. Members called to check eligibility, benefits, claims, deductibles and treatment payment schedules; healthcare providers called to validate themselves and receive eligibility or claims summaries by fax or email; and major accounts had dedicated numbers with their own treatment. Behind all of it sat a claims system reached through APIs that the client's own team was building in MuleSoft while the contact centre was being designed.

The client's non-functional requirements set a high bar of their own: HIPAA and HITRUST alignment, data stored in the United States, single sign-on with roles mapped to Entra ID groups, a screen pop within a second of connection, and a voice firewall that blocks unwanted callers before they reach the IVR.

QVCCS was the Genesys Cloud CX delivery team for a global systems integrator and Genesys reseller, inside a multi-party programme with daily touchpoints, weekly status meetings and a steering committee. Discovery ran from May to July 2025. The build, validation, system testing, user acceptance testing and go-live ran from July to November 2025, and discovery for Phase 2 began in April 2026.

1. Discovery workshops across operations, IT, networking and security
2. A high-level design, requirements specification and firewall and network requirements
3. Six versions of the IVR design, from the legacy map to an agreed baseline
4. A review of every claims system API schema against the IVR design
5. Build of the organisation, IVR, voice bots, data actions and integrations
6. System integration testing, user acceptance testing support, training and go-live

The legacy IVR was documented in a 109-page design. We first remapped it, page by page, into Genesys Cloud Architect terms, then refined it with the client through six versions in May and June 2025 until a baseline was agreed. Like-for-like was deliberate: it kept change for callers and agents to a minimum, and it kept the first phase focused on a safe migration rather than a redesign.

The agreed design runs to 37 diagram pages and more than 2,200 shapes. It holds 62 menus, 112 prompts that let callers either speak or press a key, 276 recorded prompts in all, and 167 transfer points that decide where each journey ends. The application logic is what makes it immense: whether a member is found, whether several members match, whether a group is terminated or must always reach an agent, whether a member is on continuation cover or a plan with its own service team, and whether there are claims to read, each changes what the caller hears next.

Voice bot flows do the collecting. Eight bots gather the details self-service depends on, from member ID or Social Security number and dates of birth for the member and family to provider licence number, licence state, tax ID and ZIP code. They are called 53 times across the design, so each is built once and reused wherever the journey needs it, with keypad entry always available.

The client's MuleSoft team exposed the claims system through 19 IVR endpoints. Before any were built into flows, we reviewed every schema against the IVR design. All were structurally compatible with Genesys Cloud data actions, but several returned large arrays, such as a member's claims, so we recommended limits on how many records the IVR reads aloud, and set out how nested objects, arrays and empty values should be returned so that flows could handle every case without guesswork.

The baseline design calls 17 of those endpoints, 63 times in all. Member validation alone is called 17 times and enrolment validation ten, because almost every journey begins by establishing who is calling and what cover applies. Data actions authenticate to MuleSoft with OAuth client credentials over HTTPS.

• Validate members, patients and enrolment, including family members
• Read eligibility, benefits, claims summaries, remaining maximums and deductibles
• Read treatment payment schedules
• Validate providers by tax ID, licence and state, and look up practitioners by tax ID
• Send eligibility, benefits and claims summaries to providers and members by fax or email

The provider brought 88 numbers across, about 73 of them toll-free. Every number sits in a data table that tells the flow which queue and treatment apply, and any number not listed falls back to the subscriber route, so adding or moving a number is an operational change, not a flow change. Fifty-five numbers belong to major accounts, which hear their own welcome and route to a dedicated queue; lines for one premium plan go straight to their own team without the IVR.

A second data table controls each queue's operating state. Supervisors switch emergency messages on and off, control callback and voicemail offers, and edit up to four in-queue messages per queue, which play in turn between short spells of hold music. Seven queues, schedules for open hours and every public holiday, and emergency groups complete the routing.

The voice firewall moved with the platform. Every inbound call first passes through a common module that sends the caller's number to a third-party voice traffic filter through a Genesys Cloud data action. The service responds with an instruction for that call, from continuing into the IVR to blocking it or sending it to a verification step, before any self-service or queue time is spent on it. Its credentials and identifiers are held in a Genesys Cloud data table rather than in the flows, so they can be changed without republishing anything.

Around the IVR and its integrations, the provider runs Genesys Cloud CX 1 for 172 users, with seven queues and the screening, workforce, quality and identity services it already depended on. It kept Verint for workforce management and quality, moving it from its own servers to Verint's cloud so it could run alongside Genesys Cloud CX. Verint receives data through the Genesys Cloud APIs and audio through AudioHook, with the network rules documented for both. Microsoft Entra ID provides single sign-on and SCIM, so users, roles and group memberships follow the provider's own directory.

The organisation uses four divisions, for production, QA, staging and training, so new configuration and new agents can be prepared and tested without touching live service. Microsoft Teams is integrated for the wider business, and agents use WebRTC phones in the browser.

Genesys Cloud's FedRAMP region was considered and designed for at first. It was dropped in favour of a commercial US region that did not carry the same limitations, with additional focus on meeting the client's compliance requirements there, and the firewall, single sign-on and SCIM designs were reissued for the new region.

The network needed care of its own. The provider's VPN sent all traffic to its internal network by default, and its new VPN client could not route by domain name, so we produced firewall and network requirements by IP range for Genesys Cloud media, APIs and the Verint integration, and set out the readiness tests to run from office and home connections.

System integration testing was planned as 66 end-to-end scenarios covering every IVR path, from emergency, closed and holiday announcements to each self-service journey and its failure paths. The provider's own testers then ran user acceptance testing, supported by our team, and its trainers were trained to train their colleagues, with administrators given direct training and job aids for changing schedules and in-queue messages themselves.

The move took Avaya out of service in stages that callers never saw. On go-live, the provider forwarded its numbers to Genesys Cloud CX; the numbers were then ported to a new global voice carrier on Bring Your Own Carrier (BYOC) Cloud, after which the Avaya system could be fully decommissioned.

The provider went live on Genesys Cloud CX in November 2025, about seven months after discovery began, with 172 users, every number and every integration as designed: the self-service IVR with its voice bots and claims system APIs, fax and email from the IVR, call screening, Verint and Entra ID. Avaya has been decommissioned. The number of integrations the IVR needed is the clearest measure of how much application logic it carries, and all of it now runs in the cloud.

The foundation is doing what Phase 1 set out to do, and it is ready for what the programme planned next. Discovery for Phase 2 began in April 2026 and is ongoing, building on the platform towards the AI and channel capabilities the programme planned from the start.

• 172 users and 88 numbers moved off Avaya, which is now decommissioned
• An immense IVR rebuilt like-for-like: 62 menus, eight voice bots, 63 API calls
• 17 claims system APIs through MuleSoft, including fax and email from the IVR
• Every call screened before it reaches the IVR
• Phase 2 discovery under way since April 2026