A reusable AI voice RFP template for UK buyers

Voice AI tenders often fail quietly. Not at the demo, which almost everything passes, but three weeks later, when a procurement lead spreads six vendor responses across a table and finds that no two answered the same question the same way. One priced per minute, another per resolution, a third per seat. One described its compliance posture in a paragraph, another attached a forty-page policy. The responses are not comparable, so the decision drifts back to the demo, which measured the wrong thing. The selection decision is where enterprise AI value is won or lost: roughly 88% of organisations now use AI, yet only about 6% capture material EBIT impact from it (McKinsey, The State of AI, November 2025). A structured request for proposal is how a UK buyer turns a demo into evidence.

This guide is a reusable AI voice RFP template for UK buyers: the numbered sections, the question stems under each, the response-format rules that force comparable answers, a weighted evaluation matrix you can adapt, and the clarification process that keeps a tender fair. It is scoped to enterprise, or private-sector, tenders. Public-sector buyers running a formal procurement under the Procurement Act have extra duties, and those belong in our public sector voice AI procurement strategy. It also stops short of a full vendor comparison, which our voice AI vendor selection method and procurement framework already cover. Here, the template is the deliverable.

This template is shipped by the team behind Dilr Voice, an enterprise voice AI platform that chains specialised agents into a single phone call for inbound and outbound workloads. Or see DATS, our senior-led AI consulting practice, whose placement diagnostic produces a ranked roadmap of where AI belongs before you commit.

What should a voice AI RFP template include?

A voice AI RFP template should include seven numbered sections: scope and use case, functional requirements, compliance and data protection, integration and telephony, commercial model, security and reliability, and support and roadmap. Each section carries a short set of questions, a flag marking whether an answer is mandatory or scored, and an instruction on the format a vendor must respond in. The structure matters more than the length, because it forces every vendor onto the same grid.

The reason to number the sections and fix the response format is simple: comparability. When a vendor can answer in free prose, it answers the question it wants to answer. When the template says "state your telephony providers as a list, and for each, name the UK number types supported," you get a list you can line up against four other lists. A good template reads less like a questionnaire and more like a specification with gaps for the vendor to fill. The sections that tend to decide a tender are worked through below with their question stems, while functional requirements fall out of the scope section and the support and roadmap area is weighed in the scoring matrix at the end. Treat them as a starting point, delete what does not apply to your workload, and keep the ones that will actually separate one vendor from another.

How should the scope and use-case section be written?

The scope and use-case section should be written first and in plain operational terms, because every later section is scored against it. Name the call workload, the direction, the volumes and the languages, and state what a good outcome looks like. A vendor cannot answer a compliance or integration question sensibly until it knows whether you are automating inbound triage or running outbound status campaigns. Write the business problem, not a feature wish list.

Use these stems, and require a direct answer to each:

• What is the primary call workload? Inbound front desk and triage, outbound campaigns from a contact list, or a mix, and in what proportion.
• What is the current and expected call volume by month, and what are the peak windows across a year?
• Which languages and accents must be supported, and to what standard?
• What does resolution mean for this workload, and what currently counts as an escalation to a human?
• What systems hold the answer a caller needs, and what is the source of truth the agent must read from?

Keep this section outcome-led. Our wider enterprise voice AI agents guide works through how a multi-agent call is actually assembled, and the voice AI by industry pillar shows how the same workload reads differently in insurance, healthcare or logistics. If you have not yet decided which calls to automate first, that is a diagnostic question, not a tender question, and our AI placement diagnostic exists to answer it before you issue anything.

What compliance and data-protection questions belong in a UK voice AI RFP?

A UK voice AI RFP should ask, in its compliance section, how the platform handles call recording consent, do-not-call screening, caller disclosure, data residency and automated decision-making. These obligations fall on your organisation, the one operating the line, not the vendor, so the template must confirm the platform lets you meet them. Ask for specifics and evidence, not a claim that the vendor is compliant, which means little on its own.

For UK outbound calling, the duties bind the organisation making the calls. Under the Privacy and Electronic Communications Regulations, the Information Commissioner's Office is explicit that for live marketing calls "you must check phone numbers against these registers before you make the calls", referring to the Telephone Preference Service and its corporate equivalent, and that "you must display your number (or a valid alternative contact number) to the person receiving the call" and "say who is calling" (ICO guidance on direct marketing using live calls). The template should therefore ask whether the platform performs that screening automatically, presents a valid caller line identity, and recognises an opt-out mid-call. It should also make the vendor state which PECR regime applies, because an outbound agent delivering scripted, pre-defined utterances can fall under the automated-calling rules, which require prior opt-in consent, rather than the live-calling rules above, a point we work through in our guide to AI outbound calling under GDPR and PECR.

Transparency is a question of its own. The EU AI Act, which can apply to UK firms whose voice agents interact with people in the EU, requires in Article 50(1) that "Providers shall ensure that AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system, unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect" (EU AI Act, Article 50). The duty names the provider, but it shapes what you can safely deploy, so ask how disclosure is delivered on the call.

Use these stems:

• How does the platform capture and log recording consent, and where is that log stored?
• Does it screen against the Telephone Preference Service and Corporate Telephone Preference Service before dialling, and how often is the list refreshed?
• How is the caller told they are speaking to an AI system, and at what point in the call?
• Where is call audio, transcript and personal data processed and stored, and can processing be kept in the UK? International transfers now run under the regime in Articles 45A and 46 of the UK GDPR as amended by the Data (Use and Access) Act 2025, so ask which mechanism applies.
• If the agent ever makes or materially influences a decision with legal or similarly significant effect, how are the automated decision-making safeguards now set out in Articles 22A to 22D of the UK GDPR met?
• What is the data retention default, and can it be configured per workload?

The depth here is deliberately capped at what a tender needs. Our UK and EU voice AI compliance pillar and our voice AI data retention guide go further than any RFP should.

What should the integration and telephony section cover?

The integration and telephony section should cover how the platform connects to your phone numbers, your systems of record and your downstream tools, and who owns each account. This is where a demo favourite often falls over, because a voice agent that cannot read your customer record or write back the outcome is an expensive answering machine. Ask for the live, named integrations rather than a roadmap.

Telephony is the first question. Ask which providers the platform runs on, for example Twilio or Telnyx, which UK number types are supported, and whether outbound campaigns require you to supply your own telephony account. Then move to the systems of record: ask which customer relationship and calendar platforms, such as HubSpot or Salesforce, are integrated natively today, what data the agent can read during a live call, and what it can write back after. Finally, ask about the knowledge source: whether the agent answers from your own documents through retrieval, and whether it cites the source of an answer.

Use these stems:

• Which telephony providers are supported, and must we bring our own account for outbound?
• Which CRM and calendar systems are integrated natively and in production, not on a roadmap?
• During a call, what can the agent read from our systems, and after a call, what can it write back without custom code?
• Is there a documented platform API for agents, campaigns, leads, knowledge bases and call data?
• How are knowledge bases kept current, and does the agent cite from our own content?

How do you evaluate cost without comparing headline prices?

You evaluate cost by comparing the shape of each pricing model against your own volume, not by lining up headline rates. Voice AI vendors price in different units, per minute, per resolution or per seat, and a rate that looks low in one unit can cost more at your volume than a higher rate in another. Make every vendor state its unit, what is included and what triggers an overage, so finance can model each against the same forecast.

A worked baseline helps frame the question. The mean cost of a live-agent inbound phone interaction in the UK is around 5.58 pounds (ContactBabel, UK Contact Centre Decision-Makers Guide 2024), which is the number any automation is measured against. Ask each vendor to express its cost in the same per-contact terms so the comparison is like for like. Do not ask for, or accept, a single blended figure that hides the drivers.

Use these stems:

• What is the pricing unit: per minute, per resolution, per seat, or a combination?
• What is included in the base figure, and what is billed separately, such as telephony, premium voices or integrations?
• What triggers an overage, and how is it charged?
• What notice applies to a price change, and is there a rate lock for the contract term?

This section deliberately asks about pricing shape, not a number we would quote you, and the deeper economics of the three models sit in our total cost of ownership breakdown and our voice AI ROI framework.

The same discipline that scores a tender runs a live deployment. Our AI operating model consulting sets who owns the model, the data and the escalation path once a platform is chosen, which is where cost either stays controlled or quietly grows.

Security and reliability: ask for evidence, not adjectives

The security and reliability section should ask for evidence, not adjectives: named certifications, hosting arrangements, encryption, sub-processors, uptime history and support cover. This is the part of the tender where a vendor's maturity shows, because a serious platform can answer every question with a document and a date, while a thin one answers with a promise. Mark most of these mandatory, because a gap here is usually a reason to stop rather than a point to score.

Ask what certifications the vendor holds, such as SOC 2, ISO 27001 or ISO 42001, and for the report or certificate, not a claim. Ask where the service is hosted and how data is encrypted in transit and at rest. Ask for the list of sub-processors that touch call data, which matters because processor and sub-processor obligations sit in Article 28 of the UK GDPR. Ask for a published uptime figure and recent history, and for the incident and escalation process. None of these is a question you can answer for the vendor, which is exactly why they belong in writing.

Use these stems:

• Which security certifications do you hold, and can you provide the current report or certificate?
• Where is the service hosted, and how is data encrypted in transit and at rest?
• Who are your sub-processors, and where are they located?
• What uptime do you commit to, and what was your actual uptime over the last twelve months?
• What is your incident response and escalation process, and what support hours apply?

Keep the contractual service-level detail for the contract stage. How to design the service levels themselves is covered in our voice AI SLA design guide, and the warm-transfer behaviour that a reliability question should probe is set out in our escalation and human handover guide.

How do you score voice AI vendors consistently?

You score voice AI vendors consistently by agreeing a weighted matrix before the responses arrive, then scoring each section against it blind to the vendor's name where you can. The weights encode what matters for your workload, and fixing them in advance stops a strong demo from re-weighting the decision afterwards. Give each scored question a simple scale, require evidence for the top marks, and total the weighted scores into a defensible ranking.

The weights below are an example starting point, not an industry figure. Set your own: a regulated outbound workload will push compliance higher, while a high-volume inbound deflection use case will push conversation quality and cost to the top.

Scoring against named gates, rather than overall impressions, is the core of our vendor selection method, and the department-by-department questions that IT, security and finance each raise are catalogued in our enterprise vendor checklist.

How long should a voice AI RFP and pilot take?

A voice AI RFP and pilot should run on a fixed, published timetable, so vendors can resource it and you can hold the award date. Issue the tender with a clear response window, run one clarification round, score the written responses against the matrix, then shortlist a few vendors for a live evaluation on your own scenarios. The decisive stage is a short paid pilot: a Dilr Voice pilot runs one to two weeks.

Three rules keep the timetable fair and useful. First, run clarifications once and share every answer with all bidders, because a private answer to one vendor taints the whole process. Second, evaluate on your scenarios and your data, not the vendor's polished script, since the gap between the two is the thing you are buying insurance against. Third, make the pilot paid and time-boxed, with the success criteria written down before it starts, so both sides know what proving it means. A free, open-ended trial with no agreed success criteria proves nothing except that everyone was busy.

Should a voice AI RFP be vendor-neutral?

A voice AI RFP should be vendor-neutral in its questions and explicit in its criteria. Write the requirements around your workload and your obligations, not around one platform's feature names, so that engineering-led tools and no-code platforms can both answer honestly. Neutral questions with clearly weighted criteria produce a defensible decision. A tender written around a single vendor's vocabulary tells the others, and your own audit trail, that the outcome was decided before the responses arrived.

How many vendors should you invite to a voice AI RFP?

You should invite enough vendors for a genuine comparison and few enough to score them properly, which usually means three to five. Fewer than three gives no real spread to weigh, and more than five turns scoring into a burden that collapses back into gut feel. Shortlist against a light pre-qualification first, such as UK telephony support and a named compliance posture, so every invited vendor can plausibly win.

What is the best AI voice platform for a UK enterprise in 2026?

The best AI voice platform for a UK enterprise in 2026 is the one that scores highest against your own weighted matrix, not a universal winner, because the right answer changes with the workload. An engineering team wanting maximum control may rate API-first platforms such as Vapi, Retell AI or Bland AI most highly, a legitimate tender result. A buyer needing no-code configuration and compliance rules shipped by default will score those lower, and PolyAI differently again.

This is why the template matters more than any ranking we could publish. Run the sections, score the responses, and the winner is the one your own criteria chose. Dilr Voice is built for the buyer in the second group: it chains specialised agents, a greeter, a qualifier, a knowledge agent, a customer-care agent and an action agent, into a single call, supports thirty or more languages, and ships per-country compliance rules by default, including recording consent, do-not-call checks, opt-out recognition, permitted calling hours and a full audit trail on every call. It responds in under 500 milliseconds on our own on-platform measurement, runs outbound campaigns with scheduling windows, retry logic and an auto-pause at the configured daily end time, and writes outcomes back to HubSpot or Salesforce after a call without custom code. For an API-first team that wants to build every layer itself, one of the developer platforms will score higher, and a good tender should say so.

If you would rather bring senior practitioners in before you commit, DATS, our senior-led AI consulting practice, runs a placement diagnostic that produces a ranked roadmap of where AI belongs, and you can read how we place AI inside an enterprise in our approach. The deeper guides referenced above all sit in our voice AI blog.

Ready to put a platform through your own tender? Try Dilr Voice on a free trial, read our 2026 voice AI buyer guide, map the rollout with our AI operating model consulting, or see the AI execution office that runs a programme after the award.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.