Writing contact centre RFP requirements: capture, structure and scoring

Most modern contact centre platforms can route a call, record it and report on it, so a requirements list made of generic features produces answers in which every bidder complies with almost everything. The differences that decide whether a project succeeds, such as how a platform handles your particular integrations, languages, regulations and peaks, or how a partner approaches discovery and testing, never get asked about, and the choice falls back on price and presentation.

The other common failure is the opposite: a requirements list so long and so specific that it describes the current system rather than the outcome the business needs. Bidders then propose a replica of today's contact centre on new technology, and the opportunity to simplify, automate and improve is lost before the project starts. Good requirements sit between the two: specific about outcomes, facts and constraints, and open about how they are met.

Requirement capture is research, not drafting. It begins with what customers contact you about and what a good outcome looks like for each contact reason, drawn from wrap-up codes, call recordings, transcripts and the people who handle the contacts. It continues with the operational view from team leaders, workforce planners and quality teams, the technical view from IT, security and the owners of the systems agents use, and the commercial view from finance and procurement.

Workshops work best when each one has a clear scope and produces a written record that participants confirm. We find it useful to capture the current state and the future state side by side, so that every requirement can be traced to a problem it solves or an opportunity it creates. Requirements that cannot be traced to either are candidates for removal.

1. Analyse contact reasons, volumes, handle times and outcomes for every channel
2. Map the main customer journeys, including hand-offs and failure points
3. Interview operations, workforce planning, quality, IT, security and finance
4. List every system agents use and every integration the platform must support
5. Record constraints: regulation, data location, telephony, contracts and dates
6. Confirm the findings with stakeholders before writing a single requirement

A complete set describes the service, not just the software. Bidders need to know what the platform must do, how well it must do it, what it must connect to, how it will be delivered and supported, and what it will cost to run. The table shows the areas we expect to see, with examples of the questions each should answer.

Each requirement should state one need, in the language of the outcome, with a priority and a way to verify it. "The platform shall support callbacks" invites a yes. "Customers waiting longer than the target time shall be offered a callback to the number they are calling from or another they enter, keeping their place in the queue" invites a description that can be compared and later tested. Prioritise with a simple scheme such as must, should and could, and keep the musts truly essential, because every must becomes a pass or fail.

Avoid naming a vendor's features or products in requirements, which signals the answer and narrows competition, and avoid requirements that only describe how today's system works. Ask bidders to explain how they meet each requirement, what is standard, what needs configuration or development, and what depends on a third party or an add-on licence. Ask for the evidence behind claims, such as product documentation or a reference, rather than accepting a compliance mark on its own.

• One need per requirement, written as an outcome
• A priority: must, should or could
• A measure or test that shows it has been met
• No vendor product names and no description of today's system
• A request for how it is met: standard, configured, developed or third party

The requirements that most often cause problems after contract signature are the non-functional ones. Data protection obligations under UK GDPR need a data protection impact assessment and clear answers about where customer data, recordings and transcripts are stored and processed. Card payments need a design that keeps the contact centre out of scope for card data wherever possible. Security teams will want to understand identity, access control and audit, and the NCSC cloud security guidance is a useful reference for the questions to ask any cloud service.

Resilience and telephony deserve equal care. Ask how the service is made available, what the provider's published service level agreement commits to, how calls reach the platform, which carriers and connection models are supported in each country, and what happens when a site, a carrier or an integration fails. Public bodies should also align the process with the Procurement Act 2023 and the Cabinet Office guidance that supports it.

Agree the scoring model before the RFP is issued, with weightings for each area and a clear rule for how musts are treated. Shortlisted bidders should then demonstrate your journeys, not their standard demonstration: give them two or three real scenarios, with the data and integrations involved, and score what you see against the same criteria. Where a decision depends on a capability that is new or unusual, ask for a short proof using real calls, placed from outside the platform the way customers call.

Score the partner as well as the platform. Ask how they run discovery, how they test, how they migrate without disrupting service, who will do the work, and what they do when something goes wrong. References from organisations of similar size and complexity are worth more than any written answer.

QVCCS captures and writes contact centre requirements as part of its requirements analysis and functional requirements services, drawing on leadership in contact centre technology since 1984. We are a Genesys referral partner, not a reseller, and we say so at the outset: where we help an organisation prepare an RFP, we agree with them beforehand how that work relates to any later bid, so the process stays fair to every bidder. Whoever wins, a clear, traceable set of requirements becomes the foundation for design, testing and acceptance.