The RFP Illusion
Contact centre RFPs are broken.
Not because procurement teams are careless. Not because vendors are dishonest. But because the document is almost universally built around the wrong questions. Feature lists that every major vendor can satisfy. Capability checkboxes that confirm the platforms can do what platforms do. Requirements written in the shadow of demos that have already shaped what the buyer thinks they need.
And now AI has made it worse. A vendor can feed your RFP into a model and receive a comprehensive, confident, beautifully structured response in an afternoon. Every gap addressed. Every caveat buried in language that sounds like a commitment. The tells that used to help experienced procurement professionals identify a weak response — the generic sections, the thin answers, the places where the vendor clearly didn't know — are gone.
You are evaluating a document optimised by a model to pass your evaluation. The RFP arms race just became very one-sided.
But the problem isn't just what the RFP produces. It's what it fails to ask. The questions that determine whether a platform will actually fit your organisation, your customers, and your data are almost never in the document. They don't fit in a checkbox. They require your organisation to have done the foundational work first — to know your customers honestly enough, and your data clearly enough, to ask something specific.
Here are the eight questions that should be in every contact centre RFP. They won't be answered with a yes. They'll tell you which vendors have actually thought about your problem — and which ones are promising everything.
1. Data Foundations — Before Go-Live, Not After
Most RFPs ask whether the platform integrates with your CRM, your billing system, your order management platform. The answer is always yes.
The question that matters is different: what does the vendor require of your data before their platform can work as demonstrated? What is their process for identifying data quality issues before go-live? Who is responsible for data cleansing — and what happens when the AI encounters records that are duplicated, incomplete, or conflicting?
AI is only as good as the data it operates on. A vendor who can't give you a specific, honest answer to this question is a vendor whose AI will underperform in your environment from day one.
Ask: Describe your data readiness assessment process. What baseline data quality do you require before deployment, and what happens when that baseline isn't met?
2. Emotional Intelligence — Beyond the Sentiment Score
Sentiment analysis is now a standard feature. Every platform flags angry customers. Most can identify frustrated language and trigger an escalation.
But a sentiment score is a point-in-time measurement of what a customer said. It is not a measurement of how a customer feels across their entire journey with your organisation. Those are different things — and the gap between them is where your most at-risk customers live.
The customer who is politely persistent across four contacts about the same unresolved issue has a neutral sentiment score and a catastrophic experience. The customer who called frustrated but left satisfied is an intervention success that your sentiment data will never surface.
Ask: How does your platform measure customer emotion across the full journey, not just within a single interaction? How is that measurement made actionable for frontline staff and operations managers without requiring data analysis expertise?
3. Journey Visibility for Non-Technical People
Customer journey analytics is another standard feature claim. Every platform produces journey data.
The question is who can actually use it. In most contact centre deployments, journey visualisation requires a data analyst, a BI tool, and a report request with a two-week turnaround. The team leader who needs to understand why customers are dropping out of the self-service flow at step three can't access that information in real time. The operations manager who needs to know whether yesterday's IVR change improved or worsened the customer experience is looking at a dashboard that doesn't answer that question.
The people who most need journey visibility are the least likely to have access to it in a form they can use.
Ask: Show us how a non-technical operations manager or team leader would access and interpret customer journey data in your platform. What does that experience look like without a data analyst in the room?
4. Meaningful Measurement — Beyond AHT, ASA, and Abandonment
Average Handle Time. Average Speed of Answer. Abandonment Rate. These metrics have governed contact centre operations for thirty years. They are also, in an AI-enabled environment, increasingly misleading.
AHT tells you how long an interaction took. It doesn't tell you whether the customer's problem was actually solved, whether they called back three days later, or whether the speed of resolution came at the cost of the customer feeling processed rather than helped. ASA tells you how quickly a customer reached someone. It doesn't tell you whether the someone they reached had the context, the tools, or the capability to help them.
In an AI-enabled contact centre, optimising for AHT actively works against the kind of interaction quality that retains customers. The metric measures efficiency. The customer is measuring whether their problem went away.
Ask: What metrics does your platform recommend for measuring genuine customer outcomes — resolution quality, customer effort, journey completion — rather than operational efficiency alone? How are those metrics surfaced alongside traditional KPIs?
5. The AI-Ready Environment — RAG, LLMs, and Vector Databases
The AI capabilities vendors demonstrate in demos — intelligent routing, contextual agent guidance, autonomous resolution, knowledge retrieval — increasingly depend on a specific technical architecture to work properly. Retrieval Augmented Generation. Large Language Models. Vector databases that make your knowledge base searchable in ways traditional systems can't match.
These are not plug-and-play capabilities. They require your environment to be ready for them. Your knowledge base needs to be structured in a way the LLM can retrieve from. Your data needs to be in a format the vector database can index. Your integration architecture needs to support the retrieval pipeline.
Most organisations don't know whether their environment meets these requirements. Most RFPs don't ask.
Ask: What specific technical prerequisites does your AI architecture require from our environment? What does your implementation team do to assess and close those gaps — and what remains our responsibility? What happens to AI performance when those prerequisites aren't fully met?
6. Human-AI Collaboration — Partnership, Not Handoff
Most contact centre AI is designed around a handoff model. The AI handles the interaction until it can't, then passes to a human. The human picks up where the AI left off — with varying degrees of context transfer depending on how well the integration was built.
That's not collaboration. That's a relay race.
Genuine human-AI collaboration means the AI is actively supporting the human mid-interaction — surfacing relevant knowledge, flagging risk signals, suggesting next steps, updating records in real time — while the human maintains control of the conversation and applies the judgment, empathy, and contextual awareness the AI can't replicate.
It also means the human is training the AI — flagging when the AI's suggestion was wrong, when the knowledge retrieval missed the point, when the sentiment model misread the customer. That feedback loop is what makes the AI better over time. Without it, the AI optimises for its training data, not your operation.
Ask: How does your platform support active AI assistance during a human interaction — not just before or after? What is the mechanism for human agents to provide feedback that improves AI performance over time?
7. Open API and Webhook Granularity — At What Points Can Automation Act?
Every platform has an API. Every vendor will tell you their platform is open and integrable.
The question that matters is granularity. At what specific points in the interaction lifecycle can an external system hook in? Can a webhook fire when a customer's sentiment drops below a threshold mid-call? Can automation inject context into a live voice interaction from an external system? Can a third-party AI model be invoked at a specific point in the conversation flow regardless of whether the interaction started on voice, chat, messaging, or email?
The difference between a platform with an API and a platform with a genuinely open interaction architecture is the difference between integrating systems and orchestrating capabilities. One connects tools. The other enables you to build an operation that uses the best capability for each moment, regardless of which vendor provides it.
Ask: Map the specific webhook events and API endpoints available at each stage of the interaction lifecycle across all channels. At which points can external systems read interaction state, inject data, or trigger automation in real time?
8. Demographic Equity — Who Is Your Solution Actually Working For?
This question is almost never in an RFP. It should be.
Your customer base is not homogeneous. Your 55-year-old customer who prefers voice, has low tolerance for chatbot friction, and interprets a deflection as being dismissed has a completely different relationship with your contact centre than your 28-year-old customer who prefers asynchronous messaging and is comfortable resolving issues without speaking to anyone.
Both are your customers. Both deserve a good experience. But most platform evaluations are implicitly optimised for the digitally fluent younger demographic — because that's who the demos are designed around, that's who self-service data is richest for, and that's who produces the most legible analytics.
Your 50+ customers are frequently your highest-value, longest-tenure, most loyal customers. If your AI implementation systematically serves them worse — through channel designs that don't accommodate their preferences, voice AI that struggles with accent and speech patterns, or self-service flows that assume digital fluency — you are optimising your operation for the wrong segment.
Ask: How does your platform measure and report experience quality by customer demographic segment? Can we access resolution rates, satisfaction scores, and channel preference data broken down by age group or other demographic markers? How does your solution accommodate customers who don't fit the default digital profile?
The Point of These Questions
None of these questions can be answered with a yes.
They require the vendor to describe their approach, demonstrate their capability in your context, and be specific about what they can and can't do. They make the gap between a promise and a capability visible before the contract is signed.
They also require your organisation to have done the work first. You can't ask meaningful questions about data foundations if you haven't honestly assessed your data. You can't ask about demographic equity if you don't know the demographic profile of your customer base.
That foundational work is not the vendor's job. It's yours. And it has to happen before the RFP goes out — not after the contract is signed.
Canzuki Limited
info@canzuki.com
Auckland, New Zealand
Sydney, Australia
© 2026 Canzuki Limited. All rights reserved.
+64 9 871 4471
Links
Locations