How to choose a Genesys Cloud partner

Two decisions are often bundled together, and it helps to pull them apart. The first is how you buy the Genesys Cloud CX subscription: direct from Genesys, or through a partner that resells it as part of a wider contract. The second is who designs, builds, migrates and supports your solution. Genesys publishes several kinds of partner, including resellers, services partners that implement its products, referral partners, global systems integrators and technology partners whose applications appear on AppFoundry. A single organisation may play more than one of these roles, or none of them.

Neither route is wrong. A reseller can simplify procurement and bundle support; buying direct can give you a clear relationship with the vendor. What matters is that you know which commercial relationship you are entering, who is accountable for the delivery, and whether the delivery partner's advice could be shaped by what it sells. QVCCS is a Genesys referral partner, not a reseller, so we never sell the subscription; our work is the professional services around it, whichever way you buy.

Genesys runs its own certification programme through Genesys Beyond, its education site. For Genesys Cloud CX this includes a Professional certification covering the platform broadly, a Developer certification for APIs and integration, and specialist certifications in particular areas such as Architect flows. Certification is not a guarantee of judgement, but it is a fair, independent baseline. Ask how many of the people proposed for your project are certified, in what, and whether they will actually do the work or only appear in the bid.

Breadth has value: a partner that knows several contact centre platforms may understand your legacy estate well, which helps with migration. Depth on the target platform matters more once design starts. Genesys Cloud CX changes frequently, with new features and deprecations arriving through regular releases, so you want people who work in it every week and follow the release notes as a matter of routine. At QVCCS we work on Genesys Cloud CX and on migrations to it. Every delivery team member holds, or is completing, Genesys Cloud certification.

• Names and roles of the proposed team, not only the account lead
• Which Genesys Cloud CX certifications each person holds, and when they were achieved
• Experience in your specific areas: telephony, routing, workforce engagement, self-service, reporting or integration
• How the team is backed when a question goes beyond one person's experience
• How continuity is handled if a team member leaves part-way through

Most partners will say they have a method. The useful test is whether they can show you the artefacts it produces and the points at which work stops until someone accountable signs it off. A sound method makes each requirement traceable to the design that answers it, the configuration that builds it and the test that proves it. That traceability is what lets you go live with evidence rather than optimism, and it is what lets a future team understand why the platform is built the way it is.

Ask for anonymised examples or templates. A good requirements traceability matrix, a high-level design with clear decisions, and a low-level design detailed enough to rebuild from are hard to fake. So are a systems integration test pack that covers failure paths as well as the happy path, a user acceptance test plan written around real business scenarios, and a cut-over runbook with a rehearsed rollback. If a partner offers only a slide describing phases, ask what each phase leaves behind.

Our own approach runs through seven stages: discover, define, design, build, prove, transition, and run and evolve. Each is closed by a quality gate, from discovery sign-off and the requirements baseline through design authority review, go or no-go readiness and operational acceptance. We describe it here only as one example; the questions below apply to any partner's method.

• Business requirements document and a requirements traceability matrix (RTM)
• High-level design (HLD) and low-level design or build book (LLD)
• Interface control documents for each integration
• Test strategy, SIT pack, UAT scenario scripts and a defect log
• Cut-over plan and runbook, rollback plan and an operational handover pack
• Version-controlled configuration, for example with CX as Code, where it suits the client

Contact centre projects rarely fail on the parts the brochure shows. They fail on the edges: a CRM lookup that times out under load, a carrier that handles number porting differently from the plan, a single sign-on configuration that locks out a team on day one. When comparing partners, give each one a short scenario drawn from your own estate and ask how they would design, build and test it. The answers will tell you more than any capability statement.

For integration, look for working knowledge of data actions, the Platform API, events and AppFoundry applications, and a habit of agreeing interface contracts with the owners of the other system. For telephony, look for people who understand SIP, carrier connectivity, number porting, emergency calling and failover, and who plan dedicated telephony testing rather than assuming it will work. If your design includes Bring Your Own Carrier or connections to on-premises equipment, ask who on the team has done that specific work before.

Go-live is the start of the platform's life, not the end of the project. Before you sign, agree how the solution will be supported and changed afterwards, and check that the answer fits the way you buy your subscription. If Genesys, a reseller or a managed service provider already provides incident management and first-line support, you may need a specialist partner for complex change, release readiness and expert escalation rather than a second helpdesk. If you want one organisation to take responsibility for support, look for clear service levels, monitoring and a defined route for out-of-hours incidents.

Ask what hypercare includes and how long it lasts, what the handover pack contains, how small changes are requested and tracked, and how Genesys releases will be assessed for impact on your configuration. At QVCCS we align support and maintenance to your Genesys Cloud CX consumption and support model: we work inside your provider's service delivery model, or provide SLA-based support directly where you contract it with us.

References are most useful as conversations. Ask to speak to a client with a similar size, sector or legacy platform, and ask them what went wrong and how the partner responded, not only whether they were happy. Ask whether the people who delivered their project are the people being proposed to you. Where clients cannot be named, a partner should still be able to describe comparable work in specific, verifiable detail, and you can check individual certifications through the badges Genesys issues.

Some warning signs recur. Be cautious of a proposal that names no individuals, a plan that skips formal testing or squeezes it into the final week, a design phase with no written output, advice that consistently increases the licence you buy from the same organisation, or a support offer that does not say who handles incidents. None of these alone rules a partner out, but each deserves a clear answer before you commit.

1. Do you sell the Genesys Cloud CX subscription, and how does that affect your advice?
2. Who exactly will work on our project, and what Genesys certifications do they hold?
3. Can we see anonymised examples of your RTM, HLD, LLD, test packs and cut-over runbook?
4. What quality gates does the project pass through, and who signs each one off?
5. How would you design and test this integration scenario from our estate?
6. Who on the team has delivered carrier connectivity, number porting and telephony failover?
7. What does hypercare include, and how does support work with our existing provider?
8. How do you assess each Genesys release for impact on our configuration?
9. What will we own at the end: designs, configuration in version control and runbooks?
10. May we speak to a client whose project did not go entirely to plan?