First question
Do you actually need an RFP?
An RFP is a procurement instrument, not a research method. It is very good at producing a defensible, comparable, auditable record of a decision. It is mediocre at telling you which platform will actually work, because the format rewards vendors who write well and punishes nobody for answering optimistically.
Run one when
An RFP is the right tool
Procurement policy or public-sector rules require a formal competitive process; the contract is large enough that vendors will invest genuine effort in responding; several stakeholders need to see the same evidence; or you need a documented trail for a board, a regulator, or an auditor.
Skip it when
A structured bake-off beats it
Under roughly fifty seats, the internal hours an RFP consumes usually exceed what it saves. Three vendors, the same three scenarios from your own call flows, demoed in the same week against a scorecard you wrote first, will tell you more in ten days than a hundred-question spreadsheet tells you in ten weeks.
Either way
Do the narrowing before, not inside
The worst version of this process invites nine vendors and uses the RFP to shortlist. That guarantees that the most careful reading goes to the first three responses and the last three get skimmed. Narrow to three to five candidates first — a market scan takes an afternoon — then run a real evaluation on a list you already believe in.
One more honest note before the template: if you are replacing a system because it hit end of life rather than because you chose to, your timeline is probably shorter than an RFP wants to be. Our PBX end-of-life hub covers how to compress the process without skipping the parts that matter.
The skeleton
What a CCaaS RFP should contain
Seven parts, in this order. The first two do more work than most buyers expect: a vendor who understands your operation writes a better proposal, and a vendor who knows how they will be scored answers the questions you actually care about.
| Section | What goes in it | Why it earns its place |
|---|---|---|
| 1. Context | Who you are, what the contact center does, why you are buying now | Vendors propose the wrong tier when they cannot see the operation |
| 2. Current state | Platform, seat count by role, channels, call volume, peak patterns, integrations, what breaks today | Turns generic proposals into specific ones and surfaces migration risk early |
| 3. Requirements | Must-have and nice-to-have, separated and labelled | Unlabelled requirements get scored as if they were all equal, which they are not |
| 4. Scenarios | Three to five real call flows and use cases, written out | The single highest-signal section — it cannot be answered from a boilerplate library |
| 5. Commercial | The exact configuration to quote, the term, and the format for the response | The only way five quotes come back comparable |
| 6. Evaluation | Your criteria and their weights, published up front | Focuses effort on what you care about and pre-empts the losing vendor's appeal |
| 7. Process | Dates, contacts, question window, demo format, decision date | Slippage here is what turns a ten-week process into a six-month one |
Publishing your weights in section 6 makes some buyers uncomfortable. Do it anyway. A vendor who knows that workforce management is 20% of the score and price is 25% will write to those things, which is exactly what you want — you are trying to learn how well each platform fits your priorities, not to catch them out.
The meat
The questions that separate vendors
Group questions by domain and write them so that a vendor without real experience cannot bluff. The pattern that works: ask them to describe how, name the module, and say what it costs — not whether they support it.
Routing and channels
Make them design, not confirm
Give them one of your real call flows and ask them to walk through the routing logic, naming the specific capability at each step. Ask what happens when the queue is empty, when every agent is on a call, and when the customer starts on chat and asks for a callback. Ask whether digital channels route through the same engine as voice or a parallel one — the answer changes reporting and staffing more than any feature list does.
Outbound and compliance
Where platforms genuinely diverge
If you dial out at all: which dialer modes, how pacing is controlled, how lists and dispositions are managed, and what compliance tooling ships versus what you configure. Ask specifically how the platform supports TCPA obligations and consent management, and who is responsible for what under the contract. Platforms that are strong here will say so in detail; platforms that are not will answer in adjectives.
AI, and how it is metered
The section most RFPs get wrong
Do not ask whether they have AI. Ask which of the four categories each proposed feature belongs to — customer-facing self-service, agent assist, analytics and auto-QA, or agentic — and for each one, the meter: per seat, per minute, per message, per token, or per resolution. Then ask for the cost at your current volume, at double it, and at your worst month last year. Our contact center AI guide covers why the per-resolution definition in particular needs to be in the contract.
Workforce management and quality
Native, partner, or aspiration
Ask whether forecasting, scheduling, adherence, and quality management are native, delivered through a partner, or on the roadmap — and get the answer per module, not per suite. Ask what share of interactions can be auto-scored and what that costs. This is the area where a cheaper seat price most often turns into a second vendor.
Integrations and CTI
Depth, not the logo wall
Every vendor lists the same CRMs. Ask what the integration actually does — screen pop, click-to-dial, activity logging, embedded agent desktop, bidirectional data — and which of those are configuration versus custom development. Ask for a reference running the same CRM at a similar scale. If you run Epic or Salesforce, our Epic and Salesforce guides list the specific things to make them name.
Reporting and data
The one people regret skipping
Ask what historical data you can export, in what format, and whether you can get raw interaction records rather than only the vendor's dashboards. Ask how long data is retained by default, what retention costs to extend, and what happens to your data at the end of the contract. The exit terms belong in the RFP, not in the renewal negotiation three years later.
Security and compliance
Scope, not badges
Ask for the certifications that apply to the specific product you are buying, not the corporate parent. If you handle regulated data, ask what the contract covers feature by feature — our HIPAA guide covers why AI features are the common gap. Public sector buyers should check authorization status directly rather than accepting a claim; the FedRAMP guide has the current picture.
Implementation and support
Who does the work, and when
Ask for a named implementation approach with a phase breakdown, who does what between vendor, partner, and your team, and what is included versus billable. Ask for the support model by severity level with response and resolution targets, and what the escalation path is at 2am. Ask how many customers of your size and profile they onboarded in the last year.
A practical constraint: keep the whole question set under about forty items. Every question past that point degrades the answers to the ones that mattered, because responses get delegated further down the vendor's bid team as the document grows.
Cut these
The questions to delete
These appear in most CCaaS RFPs and produce identical answers from every vendor. They cost you evaluation time and cost the vendors goodwill they would otherwise spend on your scenarios.
| The question | Why it fails | Ask instead |
|---|---|---|
| "Do you support omnichannel routing?" | Every vendor in the category says yes | "Do digital channels route through the same engine as voice? Name it." |
| "Is your platform reliable?" | Nobody answers no | "Give us your published uptime for the last 12 months and the SLA credit terms." |
| "Do you have AI capabilities?" | Universally yes, and it hides the meter | "For each AI feature quoted: which meter, and what does it cost at our volume?" |
| A 200-row feature checkbox matrix | Rewards the vendor with the largest bid team | Three real scenarios they must design against |
| "Are you HIPAA compliant?" | No product is compliant on its own | "What does your BAA cover, feature by feature, and what does it exclude?" |
| "How many customers do you have?" | Vanity metric with no bearing on your fit | "How many customers of our size, sector, and channel mix went live last year?" |
| "Describe your product roadmap." | Non-binding and rarely delivered as described | "What is generally available today that meets this requirement?" |
The roadmap one deserves emphasis. Buying on a roadmap is the most reliable way to end up unhappy: features slip, get repackaged into a higher tier, or arrive in a form that does not fit the use case you bought them for. Score what is generally available today, and treat anything future as a tie-breaker at most.
Where money leaks
The commercial section people under-specify
Most of the cost surprises in a CCaaS contract are not hidden — they are simply not asked about. Specify each of these in the RFP and require the response in the same structure, or you will be comparing quotes that are not the same shape.
| Line | What to require in the response |
|---|---|
| Seat definition | Named or concurrent, and what a concurrent seat counts — logged in, or handling |
| Non-agent seats | Supervisors, administrators, quality reviewers, and wallboard users, priced explicitly |
| Telephony | Whether minutes are bundled or metered, inbound and outbound, domestic and international |
| AI | The meter for every AI line, plus cost at current, double, and peak volume |
| Overage | Rates, whether unused capacity rolls over, and whether there is a cap |
| Implementation | Fixed or time-and-materials, what is included, and who is billable |
| Term and renewal | Length, auto-renewal terms, notice period, and any uplift cap at renewal |
| Price protection | What the rate is in years two and three, in writing |
| Termination | Early-termination charges and what triggers them |
| Data exit | Export format, assistance included, and retention after termination |
Two of those are worth insisting on even when a vendor resists. An uplift cap at renewal is the cheapest thing to negotiate before you sign and the most expensive to negotiate afterward, when switching costs are known to both sides. And data exit terms cost nothing to agree at signature; leaving them out is how a renewal becomes a negotiation you cannot walk away from.
Decide before you read
Scoring: weight it before the first response arrives
Write the scorecard before the responses land. Weights chosen after you have read the proposals are weights chosen to justify a preference you already formed — and everyone on the evaluation panel can feel it happening.
Weight the categories
A defensible starting split
Functional fit against your scenarios 30%, commercial 25%, implementation and support 15%, workforce and reporting 15%, security and compliance 10%, vendor viability and references 5%. Move these to suit your operation — an outbound-heavy team weights functional fit higher, a regulated one weights compliance higher — but agree them as a panel and publish them.
Score the scenarios separately
Where the real signal is
Have each panel member score the scenario walkthroughs independently before any group discussion, then compare. Divergence between scorers on the same scenario is usually a sign that the vendor was vague rather than that the panel disagrees — and that is worth a follow-up question rather than an averaged score.
Separate must-have from nice-to-have
And mean it
A must-have that a platform genuinely cannot meet is a disqualification, not a low score. If you find yourself scoring around a missing must-have because you like the vendor, it was never a must-have — go back and fix the requirements list, honestly, in front of the panel.
Check references properly
Three questions that work
Ask every reference: what took longer than expected, what would you do differently, and what does support look like when something is genuinely broken. Vendors supply happy references; those three questions still produce useful answers from happy customers.
Calendar reality
A realistic RFP timeline
For a mid-market contact center replacement with a shortlist of four, plan on twelve to sixteen weeks from kickoff to signature. Compressing it is possible; skipping the scenario design is what makes compression expensive.
| Phase | Duration | What actually happens |
|---|---|---|
| Prepare | 2–3 weeks | Requirements, scenarios, scorecard, and shortlist |
| Issue and Q&A | 2–3 weeks | Vendors read, ask questions, you publish answers to everyone |
| Responses | 3–4 weeks | Give them enough time or you get boilerplate |
| Score and demo | 2–3 weeks | Independent scoring, then demos against your scenarios |
| Negotiate | 2–4 weeks | Commercial terms, security review, legal — the phase that slips |
Two things reliably run long and neither is the vendors' fault: your own security review of a new cloud platform, and legal redlines on the data-processing terms. Start both in parallel with the demos rather than after the decision, and the last phase stops being the one that blows the date.
The other route
Or skip the RFP and run a structured bake-off
For most mid-market buyers, this produces a better decision in a third of the time. It is the same rigour applied without the document.
Shortlist three platforms from a market scan. Write three real scenarios from your own call flows. Book all three vendors in the same week and make each one demo those scenarios — not their standard deck. Score independently, then compare. Request quotes for one identical, explicitly specified configuration. Check references with the three questions above. Decide.
The thing an RFP gives you that this does not is the paper trail, which is exactly why regulated and public-sector buyers should still run the document. Everyone else is usually buying process for its own sake.
And the honest disclosure, since this page is on an advisory site: running this process — the shortlist, the scenarios, the scoring, the quotes, and the negotiation — is what we do for a living. It is free to you, because the supplier you select pays the commission rather than you. That is also why the section above tells you how to run it yourself: if you would rather not outsource it, the method is the same either way.
Common questions
Contact center RFP questions, answered
Do we need an RFP to buy a contact center platform?
Often not. Below roughly fifty seats, a formal RFP usually costs more in internal time than it saves, and a structured bake-off — same three scenarios, same three vendors, same week — produces a better decision faster. An RFP earns its keep when procurement policy requires one, when the deal is large enough that vendors will invest real effort in responding, or when you need a defensible paper trail for a board or a public body.
How many vendors should we invite?
Three to five. Fewer than three and you have no price tension; more than five and the evaluation collapses under its own weight, because nobody reads the ninth response as carefully as the first. Do the narrowing before the RFP, not inside it — a shortlist built from a market scan takes an afternoon and saves weeks.
What is the single most common mistake in a CCaaS RFP?
Asking capability questions instead of implementation questions. "Do you support skills-based routing?" gets a yes from every vendor in the market and tells you nothing. "Walk us through how you would route this specific call flow, and name the module that does it" gets you an answer only a vendor who has done it can give.
How should we handle pricing in an RFP?
Specify the configuration yourself and make everyone quote against it: the exact seat count by role, including supervisors and quality reviewers, the channels, the AI features, the telephony volume, and the term. Otherwise you receive five quotes for five different products and no way to compare them. Ask for the fully loaded three-year cost, not the year-one seat rate.
Should we tell vendors our budget?
Usually yes, as a range. Withholding it produces proposals aimed at the wrong tier, which wastes a round for everyone and can eliminate a platform that would have fitted at a different configuration. What you should withhold is what the other vendors have quoted — that is your leverage, and it is worth more later in the process than early.
Can an advisor run the RFP for us?
Yes, and it is one of the more useful things an independent advisor does, because they already know which questions each platform struggles to answer and what other buyers actually paid. Our advisory is free to you — the supplier you select pays the commission — so the practical choice is whether you want to write and score it yourself or have someone do it who has read a few hundred of these.
Keep reading