A global manufacturer: one Genesys Cloud platform for IT, HR and its worldwide resellers

The manufacturer sells through resellers in dozens of countries and supports them, and its own employees, by phone. Three quite different operations had grown up on separate platforms. Its global IT service desk ran on an Asterisk PBX. Its HR support teams ran on Cisco Unified Contact Center Enterprise. Its reseller and consumer support, the largest of the three, was split between in-house teams and two business process outsourcing partners, each on its own contact centre technology. Features differed from service to service, integration with business systems was limited, and the company's teams and its outsourcers worked in silos.

The company issued a request for proposals in October 2024 and chose Genesys Cloud CX 2 for around 335 agents, internal and outsourced, with 348 named users. Its goals were clear: one modern platform, a better experience for callers, more efficient agents, stronger security, minimal disruption to service, and high adoption. Only the first phase was approved at the outset, so it had to deliver those goals for voice on its own, while laying foundations for the phases that would follow.

QVCCS was engaged by a global systems integrator and Genesys reseller as the specialist delivery organisation for Genesys Cloud CX. From kickoff in May 2025 we led discovery and design for each line of business, produced the network, telecoms, firewall and identity designs, built the platform and every flow, tested it, wrote the runbooks and took each wave live, then supported the changes that followed. The programme ran on a PRINCE2 waterfall model with formal stages, a RAID log and a baselined plan.

1. Discovery workshops per line of business, with call flow designs revised through up to eleven versions
2. A configuration checklist per line of business: users, sites, numbers, schedules, queues, skills, roles, divisions and prompts
3. Network, firewall, telecoms, SSO and SCIM designs, and trunk requirements for every carrier and session border controller
4. Salesforce data actions and embeddable framework, and a ServiceNow softphone connector
5. Prompt sets for fourteen locales, generated from SSML with neural voices chosen per language
6. System integration testing, client acceptance testing in each language, and runbooks for each go-live
7. Change requests after go-live, and design of the next phase

Everything runs in one Genesys Cloud CX organisation, with its core in a North American region and a second media region in Europe, joined through Genesys Global Media Fabric so that European calls keep their media close to their callers. Divisions separate the three lines of business, and the outsourcing partners within them, so each team sees only its own queues, users and data, while administrators manage one platform.

Voice reaches the platform on the Bring Your Own Carrier (BYOC) Cloud model. The company buys its telephony from several carriers across its regions, and QVCCS documented trunk requirements for each, in both UDP and TLS variants, alongside the company's own session border controllers. To protect the first go-lives, the project took a deliberate decision to route public and internal calls through the company's existing on-net infrastructure and its Cisco session border controllers, and to move to direct carrier connections in later phases.

Users sign in with single sign-on through Microsoft Entra ID, which also provisions them through SCIM, with groups mapped to Genesys Cloud roles per line of business and environment. Agents work on WebRTC phones in the browser, behind the company's cloud security service, for which QVCCS specified every domain and address range that had to be opened. Development and production divisions keep testing apart from live service.

The IT service desk went first, because it would support the employees affected by every wave that followed. It serves employees in six countries across four continents, in English, French, Spanish and German. Agents work inside ServiceNow, through a softphone connector embedded in their service management screens, and the IVR passes what it learns in the form ServiceNow expects, so incident and request references arrive already formatted and the agent's screen finds the right record.

The design treats a major incident as a different kind of call. Major incidents have their own route: callers can reach it from a dedicated number or by pressing 6 at any point, even during the welcome message, and the call is flagged, given a higher priority and routed for an immediate response, with the on-call engineer path maintained in a data table rather than in the flow. Callers waiting in queue are told when agents are available and offered a callback to a number of their choice, and when no one is available they can leave a voicemail. At the client's request, no call or screen recording is active anywhere in the service desk flows. A separate runbook took the European service desk live in its own window.

HR support went live next, for employees in North America, Mexico, Europe and the rest of the world, in five languages. Callers enter their employee ID, which the IVR checks against the company's Salesforce HR records through Genesys Cloud data actions, so the agent knows who is calling before answering. They then choose benefits, payroll or another HR matter, and agents work in Salesforce through the Genesys embeddable framework, with the call, the employee and the request in one place.

Every country, language and topic has its own message of the day, switched on or off in a data table by the HR team, so an announcement about a payroll date in one country never reaches callers in another. Opening hours vary by country and are applied by schedule, and outside those hours callers hear when the team is open and can leave a voicemail. The HR go-live followed a formal method statement: prerequisites such as single sign-on, user divisions and a live simulation with a reference group of agents were confirmed first, and each stage had a pre-check, validation, post-check and a defined rollback.

Reseller and consumer support was the largest wave by far, with around 200 agents, in-house and at two outsourcing partners, serving resellers in North America, Latin America, Brazil, Europe, the Middle East, Africa and Asia-Pacific. Each region has its own design, built from shared building blocks: a main ingress, a main menu, case and claim collection, unit sales, two in-queue experiences, and the data tables and data actions behind them. In all, the reseller service runs on more than 160 queues and more than 170 schedules, so that every team in every region opens, closes and announces its hours correctly.

When a reseller calls, the IVR looks the number up in Salesforce, matches it to a registered reseller contact or account, and asks the caller to confirm their reseller number, or to enter it if the number is not recognised. Resellers then choose parts and accessories, technical support, warranty, technology or unit sales. For most enquiries they enter the case or claim number they have already raised in the company's reseller portal, and the IVR looks it up in Salesforce, finds the team that owns it and routes the call there, whether that is an in-house team, a first or second line team, or one of the outsourcing partners.

The design anticipates what goes wrong. If the reseller portal is down, a flag in a data table lets resellers through without a case number. If a case cannot be found, callers are told so and given another chance before the call ends cleanly. Closure messages for holidays, training and meetings are switched on per market and language. Resellers who want their own unit sales representative choose them by name, and the call is routed to that person if they are available, or to the wider team if not.

While they wait, callers hear their estimated waiting time in clear steps and, when waits grow long, can keep their place and be called back on the number they are calling from or another they enter. Before a call queues at all, the flow checks that agents are staffed and available, so nobody waits in a queue that no one is serving. Consumer lines for enquiries and sales leads were designed alongside the reseller service.

Callers across the reseller network are greeted in their own language: fourteen locales across ten languages, from North American English and French to the languages of Europe, Latin America and Brazil. The project decided early to use recorded prompts for stable messages and dynamic text to speech only where content changes, such as waiting times and announcements. The client chose a neural voice for each language, and every prompt was written as SSML and rendered into audio, so pronunciation, pauses and emphasis are controlled rather than left to chance.

The final reseller prompt set alone holds more than 1,200 recordings, around 88 per locale, and more than ten thousand audio files were produced across the revisions that led to it. Every prompt carries an identifier that ties it to the call flow design, the translation sheet and the flow itself, so a change to a message in one language can be traced and repeated in all the others.

QVCCS ran system integration testing before handing each wave to the client for acceptance testing. For the reseller service alone, the internal test plan held more than 500 test cases across the five regions, driven by test data that mapped real reseller numbers, case numbers and claim numbers to the queue each call should reach. Client acceptance testing then ran in each language pair. Go-lives were planned around the company's change freezes, including a holiday freeze and a carrier freeze on number porting, with runbooks covering every number, short code and redirect.

The platform kept evolving after go-live. A permissions audit led to a least-privilege change for the HR and service desk teams and a dedicated administrator role. European session border controllers were brought into service with primary and backup outbound routes for each region. The company asked for objects named after outsourcing partners to be renamed to a neutral, reusable convention, and for new routing logic when a case owner has no matching team in Genesys Cloud. The next phase, already in design, adds dedicated in-queue experiences for the outsourcing partners in the reseller service.

The final wave went live in February 2026, completing the first phase. The legacy platforms have been replaced by one Genesys Cloud CX organisation that serves the company's employees, its resellers and their customers, with in-house and outsourced agents on the same platform for the first time. Callers are recognised from Salesforce and ServiceNow records, routed to the team that owns their case, and greeted in their own language, and the business manages messages, closures and outages itself through data tables.

Every flow, queue, schedule, number and prompt is documented in configuration checklists and call flow designs that the company keeps, so the next phase starts from a complete, current record rather than a rediscovery. Changes since go-live have been raised, assessed and made through the company's own change process, and the next phase builds on the same organisation, divisions and integrations.

• IT service desk, HR and reseller support moved onto one platform
• Three go-live waves across North America, Latin America, EMEA and APAC
• More than 160 queues and 170 schedules for the reseller service alone
• More than 1,200 final prompts in fourteen locales
• Salesforce and ServiceNow integration for agents and the IVR
• Over 500 system integration test cases for the reseller service

Sequencing did a great deal of the work. The service desk went first so that it could support everyone else, HR followed, and the largest and most complex service went last, on a platform and a team that had already been proven twice. Decisions that could have stalled the programme, such as how calls would reach the platform and how prompts would be produced, were taken early, written down and revisited only when there was a reason. And the same disciplines ran through every wave: a design signed off before build, a configuration checklist as the single record of what was built, testing driven by real data, and a runbook with a rollback for every go-live.