Questions for your Genesys Cloud business case, by stakeholder

Most contact centre business cases that stall do so for the same reason: one stakeholder asks a question the sponsor cannot answer with evidence. The finance director wants to know which existing contracts actually end, the security lead wants to know where recordings will be stored, the operations director wants to know what happens to service levels during cut-over. None of these questions is unreasonable, and almost all of them can be anticipated.

The practical approach is to treat the business case as a set of answers to known questions rather than a sales document. Gather the evidence first, write the case second. Where you do not yet know something, say so, state how and when you will find out, and show the decision does not depend on it. A committee will accept an honest unknown far more readily than a confident figure that unravels under one follow-up question.

Public sector readers will recognise this discipline from HM Treasury's Green Book and its five case model, which separates the strategic, economic, commercial, financial and management questions. Private sector cases benefit from the same separation, even when the format is lighter.

The board wants to know why this change, why now, and what happens if the organisation does nothing. Answer with the strategic drivers in plain terms: a platform reaching the end of vendor support, a customer experience the organisation wants to change, a contract renewal that forces a decision, or a resilience concern raised by audit. Link each driver to the organisation's own stated objectives rather than to general market trends.

The do-nothing option deserves real work. Describe what continuing on the current platform involves: the support position, the hardware and licence renewals ahead, the skills needed to keep it running, and the change requests it cannot meet. If a vendor has announced an end-of-life date, quote it from the vendor's own published notice, such as the Genesys end-of-life tables for PureConnect and Engage, and attach the reference.

• What problem are we solving, and how does it connect to our strategy?
• What happens if we do nothing, and by when do we have to decide?
• What options did we consider, including staying where we are or a different platform?
• What are the main risks, who owns them, and what would make us stop?
• Who is accountable for delivery and for the benefits after go-live?
• How will we know, in a year's time, whether this was the right decision?

Finance will ask what the change costs, what it saves or avoids, and when. Start with a baseline of today's spend built from evidence: telephony and carrier contracts, licence and maintenance renewals, hardware support agreements, hosting, partner support, and internal effort to run the platform. Record each contract's end date and notice period, because a cloud subscription that starts while old contracts still run creates a period of double running that the case must show.

Avoid presenting a single headline saving. Build costs and benefits as ranges, with each assumption written down and its source named. Then test the case: which assumptions, if wrong, would change the decision? Those are the ones to firm up with quotations, contract reviews or pilot data before committee. Separate one-off costs (design, build, testing, training, number porting, data migration, decommissioning) from recurring ones, and show where spend moves from capital to operating budgets.

• Which current contracts end, when, and what are the notice periods and exit charges?
• How long will old and new platforms run side by side, and what does that period cost?
• Which costs are one-off and which are recurring, and how does the budget treatment change?
• Which benefits are cash savings, which are cost avoidance, and which are non-financial?
• What assumptions drive the numbers, and how sensitive is the case to each one?
• How does subscription spend change as volumes, agents or channels grow or shrink?

IT will ask how Genesys Cloud CX fits the existing estate: identity, networks, telephony, desktop, CRM and data platforms. Prepare an integration inventory listing every system the contact centre touches today, how it connects, and who owns it. Telephony needs its own answer: Genesys Cloud supports Genesys Cloud Voice, where Genesys provides the carrier service, and Bring Your Own Carrier (BYOC) options, where SIP trunks connect Genesys Cloud to a third-party carrier, which may be your existing one. The choice affects contracts, number porting and resilience design.

Security and data protection leads will ask where data is stored, who can reach it, and how the organisation meets its obligations. Genesys Cloud is deployed in published regions, including London, so the region choice should be a stated decision in the case. Plan a data protection impact assessment early, in line with ICO guidance, and review any international transfers, for example where support or a connected service sits outside the UK. Genesys publishes its compliance certifications and attestations on its Trust Centre; collect the current ones relevant to your sector rather than relying on memory.

• Which Genesys Cloud region will hold our data, and does that meet our residency policy?
• Have we completed, or scheduled, a data protection impact assessment?
• Are there international transfers, and what safeguards cover them?
• How will identity, single sign-on and user provisioning work?
• Which integrations are needed at go-live, and which can follow later?
• What is the telephony model, and how are carrier and network resilience designed?
• How will configuration be controlled, tested and changed after go-live?
• How do we monitor platform status and receive notice of planned changes?

Operations leaders care about service during and after the change. They will ask what customers will notice, whether service levels can be protected through cut-over, and whether the new platform will let them make changes faster than today. Answer with measures you already collect: service level, abandonment, first contact resolution, complaints, customer satisfaction and effort scores, and the backlog of change requests the current platform cannot deliver.

Be careful with promises about improvement. Show the current baseline for each measure, describe which capability is expected to move it and why, and agree how the effect will be isolated from other changes such as new staff, seasonal demand or a policy change. A phased plan by channel, site or business area, with rehearsed cut-over and rollback, is usually the most credible answer to the question of operational risk.

• What will customers notice on day one, and what will improve later?
• How will service levels be protected during cut-over, and what is the rollback plan?
• Which current customer and service measures form the baseline?
• Which changes will the operation be able to make itself, and which need specialist help?
• How will reporting compare before and after when definitions differ between platforms?
• Which journeys or channels move first, and why?

HR and workforce leaders ask about people: training, working patterns, home and hybrid working, monitoring, consultation and skills. Agents and team leaders will learn a new desktop and new processes, planners may move to a new workforce management tool, and the internal team that ran the old platform needs a route to new skills. If recording, analytics or quality tools change what is captured about staff, employee representatives and the data protection officer should be involved early.

Gather the evidence that already exists: training records, attrition and absence trends, employee survey results, and feedback from agents on the tools they use today. These give a baseline for employee experience and help size the training plan. Be clear about which roles change and how, and avoid presenting staff reductions as an assumed benefit unless the organisation has decided that separately and consulted on it.

• Which roles change, and how much training does each role need?
• Does the change affect home or hybrid working, equipment or working patterns?
• What new data about staff will be recorded or analysed, and how is it governed?
• Do we need to consult employees or their representatives?
• How will the team that runs today's platform be reskilled for Genesys Cloud?
• Which employee experience measures will we track before and after go-live?

Every stakeholder group eventually asks the same two questions: can we get out if this does not work, and how will we prove that it did? On exit, review the subscription term, renewal and notice provisions, how data, recordings and configuration can be exported, and what happens to numbers if you change carrier or platform. Keeping configuration in version control and documenting integrations as interface contracts reduces lock-in to any one supplier, including your implementation partner.

On benefits, write a benefits register before signing. For each benefit, record the baseline, the measure, the owner, the data source and the review date. Benefits that cannot be measured should be described as qualitative and not given a value. QVCCS works with clients to set this register up during discovery, but whoever you work with, the principle is the same: agree the yardstick before the change, not after.