An AI chatbot RFP template needs five things a generic software RFP does not: RAG-specific technical questions, a hallucination-handling clause, data residency and AI Act disclosure requirements, a pricing-model comparison (per-resolution versus flat rate), and a weighted scoring matrix that separates a rigorous evaluation from a decision made on brand recognition alone. Most procurement templates circulating online were written for generic SaaS and simply bolt "AI" onto a feature checklist — which is why they miss the questions that actually predict whether a chatbot will hallucinate in front of your customers.
Below, the first five sections explain what to require and why each requirement matters. Section six is the template itself: 11 copy-ready sections you can paste directly into a document and send to vendors today, including an explicit clause on customer data not being used for model training.
Table of Contents
What an AI Chatbot RFP Should Contain (and Why Generic Templates Fail)
A generic vendor RFP tests things every SaaS purchase needs: uptime, support responsiveness, contract terms, references. Those questions still matter for a chatbot purchase — but they tell you nothing about whether the AI will answer accurately, whether it can be audited when it gets something wrong, or whether your customer data trains a model your competitors also use.
An AI chatbot RFP needs to test three things a feature checklist cannot capture on its own:
- Retrieval accuracy: does the vendor ground answers in your documents (RAG), or does the bot answer from general model knowledge and risk inventing specifics about your business?
- Failure behavior: what happens when the chatbot does not know the answer? A well-built system says so. A poorly built one guesses — and a confident, wrong answer to a customer is worse than no chatbot at all.
- Data handling: where is the data stored, who can access it, and — critically — is any of it used to train the vendor's underlying models for other customers?
Teams that skip these three areas and rely on a repurposed software RFP typically discover the gaps after signing: a chatbot that hallucinates pricing, a data residency clause that does not hold up to a legal review, or a per-resolution pricing model that triples the invoice the month a marketing campaign spikes traffic. The template in this guide is built to surface those issues before contract signature, not after. If you are still deciding whether to build in-house or buy a platform, our build vs buy decision guide covers that upstream question first.
Core Requirements Section
Before any vendor sees your RFP, define these internally. A vendor cannot score well against requirements you have not written down — and an unscoped RFP produces vague, hard-to-compare proposals.
Objectives and success metrics
State the business outcome you are buying, not just the feature. "Reduce first-response time on support tickets" and "qualify inbound leads before a sales call" require different chatbot configurations, integrations, and even different pricing tiers. Define the metric you will use to judge success post-launch: containment rate (the share of conversations resolved without human handoff), resolution rate, average handle time, or lead-qualification accuracy. For a full list of the metrics worth tracking once a vendor is live, see our chatbot KPI guide.
Functional scope, prioritized
Use MoSCoW prioritization (Must have, Should have, Could have, Won't have) rather than a flat feature list. This forces internal alignment before the RFP goes out and lets vendors be evaluated against what actually matters, not against every checkbox they happen to support.
- Must have: the requirements that eliminate a vendor if missing — e.g., RAG-based document grounding, EU data hosting, a specific integration.
- Should have: strong differentiators that influence the score but are not disqualifying — e.g., multilingual support, WhatsApp channel, advanced analytics.
- Could have: nice-to-haves that break ties between otherwise-equal vendors.
- Won't have (this phase): explicitly out of scope, to stop vendors from padding proposals with irrelevant capabilities.
Deployment footprint and volume
Specify the channels (website widget, WhatsApp, internal tool), expected monthly conversation volume, knowledge base size (document count and rough character volume), and number of distinct agents or use cases you plan to run. Vendors price and architect very differently for one agent handling 500 conversations a month versus ten agents handling 50,000 — get these numbers on paper before requesting quotes.
AI/RAG-Specific Questions to Ask Every Vendor
This is the section that separates an AI-literate RFP from a repurposed software template. Every question below should produce a specific, verifiable answer — a vague response ("our AI is highly accurate") is itself a useful data point.
Retrieval and source grounding
- Does the system use Retrieval-Augmented Generation (RAG) to ground every answer in our uploaded documents, or does it rely on the base model's general training data?
- Can the platform cite or trace which source document informed a given answer?
- What document formats are supported natively (PDF, DOCX, PPTX, TXT, URL scraping), and how is content chunked and embedded?
Knowledge base freshness
- When a document is updated or deleted, how quickly does the change propagate to live answers?
- Is there a scheduled re-sync for content pulled from URLs or connected systems, and can we control its frequency?
- How do we audit what is currently in the knowledge base, and remove outdated content on demand?
Hallucination handling and data use
This is the single highest-leverage question in the entire RFP. A chatbot that cannot find an answer should say so — "graceful abstention" — rather than generate a plausible-sounding guess. Ask vendors to demonstrate this behavior live, not just describe it in a slide.
- What happens when the knowledge base has no relevant answer? Request a live demonstration, not a written description.
- Is customer knowledge-base content ever used to train or fine-tune models shared across other customers? Require this in writing. A "no training on customer data" clause belongs in the contract, not just the sales deck — see Section 4 of the template below.
- How is response accuracy measured or tested before and after deployment, and is that data available to us?
For a deeper technical breakdown of how retrieval pipelines are built and what "knowledge base quality" actually means for answer accuracy, see our guide on knowledge base engineering for AI chatbots and our piece on chatbot hallucinations and reliability guardrails.
Security & Compliance: GDPR, SOC 2, and the AI Act
Security and compliance questions in a chatbot RFP need to cover both standard SaaS due diligence and AI-specific disclosure obligations that did not exist in older procurement templates. Treat this section as non-negotiable, not optional.
Data residency and GDPR
- Where is customer and conversation data physically stored (EU data residency, or transferred outside the EU)? If outside the EU, what transfer mechanism applies under GDPR Chapter V?
- Is a Data Processing Agreement (DPA) available, and does it list all sub-processors, as required under GDPR Article 28?
- What is the data retention period for conversation logs, and can we request deletion on demand?
- How are conversations encrypted, both in transit and at rest?
SOC 2 and audit posture
Ask for the vendor's current SOC 2 Type II report, not just a claim of "compliance." A Type II report verifies that security controls operated effectively over an observation period (typically six to twelve months) — a meaningfully stronger signal than a Type I report, which only checks that controls exist on a single date. The AICPA's Trust Services Criteria define what a SOC 2 report actually audits (security, availability, confidentiality, and related categories) — useful context if your legal team is reviewing a report for the first time.
- Is a current SOC 2 Type II report available under NDA?
- Is there a documented incident response process and a breach-notification SLA?
- Is audit logging available for admin actions and knowledge base changes, and for how long are logs retained?
EU AI Act transparency obligations
From 2 August 2026, Article 50 of the EU AI Act requires that anyone deploying a chatbot reachable by people in the EU discloses that they are interacting with AI — with fines of up to €15 million or 3% of global annual turnover for non-compliance. Ask the vendor whether this disclosure is built into the widget by default or left for you to implement, and whether they can support the higher documentation bar if your use case (recruitment screening, credit-related decisions) falls under the Act's high-risk category. We cover the full compliance timeline in our EU AI Act chatbot compliance checklist. For GDPR specifically, our GDPR-compliant AI chatbot guide and our piece on EU data sovereignty for AI chatbots go further into data-hosting specifics.
A practical tip
The RFPs that catch real problems are the ones that ask a vendor to demonstrate the failure case live — what the bot says when it doesn't know the answer — rather than accepting a written claim of accuracy. That single demo tells you more about a chatbot's production readiness than any feature list.
Pricing Models to Scrutinize: Per-Resolution vs Flat Rate
Chatbot vendors price on two fundamentally different models, and an RFP that does not ask vendors to show both the sticker price and the total cost of ownership (TCO) at your actual volume will produce quotes that look comparable and are not.
| Question to ask | Per-resolution pricing | Flat-rate pricing |
|---|---|---|
| Bill scales with... | Conversations the AI resolves without escalation | A fixed monthly plan tier (message/character caps) |
| Budget predictability | Low — a traffic spike or seasonal campaign directly increases cost | High — invoice is known in advance regardless of volume within the plan |
| What to ask the vendor | "What is the exact definition of a billable resolution, and can we audit it?" | "What happens when we exceed the plan's message cap mid-cycle?" |
| Best documented example | See our full breakdown of per-resolution vs flat-rate chatbot pricing, with worked numbers at several volume tiers. | |
Heeya prices on a flat-rate model as a matter of design: Free (€0/month, 30 messages), Standard (€19/month, 500 messages, 1M knowledge-base characters), Premium (€99/month, 2,500 messages, 3M characters), and Enterprise (custom quote for unlimited volume). Whichever model a vendor uses, require the RFP response to include a TCO estimate at your projected 12-month volume, not just the entry-tier list price — see current plan detail on AI chatbot pricing.
The AI Chatbot RFP Template: 11 Sections to Copy
This is the template itself — copy the structure below into your own document. No download link, no email gate: it is written to be used directly on this page. Every vendor response should be scored against the weighted matrix in section 10.
1. Company context and background
- Company size, industry, and current customer support or lead-generation setup
- Why you are evaluating an AI chatbot now (cost pressure, ticket volume, response-time targets)
- Current tools in place (helpdesk, CRM, live chat) that the chatbot must coexist with or replace
2. Objectives and success metrics (KPIs)
- Primary objective in one sentence (e.g., "reduce first-response time on tier-1 tickets")
- Target containment rate or resolution rate at 90 days post-launch
- Secondary metrics: lead-qualification accuracy, CSAT, agent time saved
3. Functional scope (MoSCoW)
- Must have / Should have / Could have / Won't have, per the framework in Section 2 above
- Channels required: website widget, WhatsApp, internal tool, API
- Languages required and whether translation is native or configured per-agent
4. AI/LLM requirements
- RAG-based document grounding: required, with a live demonstration of source citation
- Documented hallucination-handling behavior (graceful abstention) — demoed live, not described only
- Explicit clause: customer knowledge-base content and conversation data are not used to train models shared with other customers, in writing, in the contract
- Underlying model(s) used and whether they can be changed or upgraded without a re-implementation
5. Knowledge base requirements
- Supported document formats and maximum knowledge base size (documents and characters)
- Update propagation time after a document is changed or removed
- Content-audit tooling: can we see and search what the AI currently knows?
6. Security, compliance, and data residency
- EU data residency confirmed, or transfer mechanism under GDPR Chapter V documented
- DPA available, listing all sub-processors (GDPR Article 28)
- Current SOC 2 Type II report available under NDA
- EU AI Act Article 50 disclosure ("you are talking to AI") built into the widget by default
- Audit logging retention period for admin and knowledge-base actions
7. Integrations and API
- CRM, helpdesk, and calendar integrations required, with confirmation of native vs custom-built
- API availability for headless or embedded deployments
- Webhook or event support for triggering downstream workflows (e.g., lead handoff to sales)
8. Pricing and total cost of ownership
- Pricing model: per-resolution or flat-rate, with the exact definition of a billable unit
- TCO estimate at your projected 12-month conversation volume, not just entry-tier pricing
- Overage behavior: what happens when volume exceeds the plan or quote
- Setup fees, minimum contract term, and cancellation terms
9. SLA and support
- Uptime guarantee and how it is measured/reported
- Support channels and response-time commitments by severity tier
- Onboarding timeline from contract signature to live deployment
10. Weighted scoring matrix
| Criterion | Suggested weight | Vendor score (1-5) |
|---|---|---|
| RAG accuracy & source citation (demoed live) | 25% | — |
| Security & compliance (SOC 2, GDPR, AI Act) | 20% | — |
| Total cost of ownership at your volume | 20% | — |
| Functional fit (must-have coverage) | 15% | — |
| Integrations & API | 10% | — |
| SLA, support & onboarding timeline | 10% | — |
Adjust the weights to your priorities before sending the RFP — a healthcare or legal use case should push security higher; a high-volume e-commerce deployment should push TCO higher. What matters is agreeing on weights before proposals arrive, not after, when a favorite vendor's weak spot suddenly looks less important.
11. Glossary
- RAG (Retrieval-Augmented Generation): the AI searches your documents before answering, rather than relying only on general model training data
- Hallucination: a confident but factually wrong or fabricated AI response
- Containment / resolution rate: the share of conversations the AI resolves without human escalation
- Per-resolution pricing: billed per conversation the AI resolves, as opposed to a flat subscription
- SOC 2 Type II: an independent audit report verifying security controls operated effectively over a defined observation period
- DPA (Data Processing Agreement): the GDPR-required contract governing how a vendor processes your data on your behalf
FAQ: AI Chatbot RFP Template
How do I write an AI chatbot RFP?
Start by defining your objectives and success metrics internally, then scope functional requirements using MoSCoW prioritization (must/should/could/won't have). Add AI-specific sections that a generic software RFP omits: RAG and source-citation requirements, hallucination-handling behavior, data residency and SOC 2 documentation, and a pricing-model comparison. Finish with a weighted scoring matrix so every proposal is compared on the same criteria. The 11-section template in this guide can be copied directly.
What questions should I ask an AI chatbot vendor?
Ask whether answers are grounded in your documents via RAG or generated from general model knowledge, what the chatbot does when it doesn't know an answer (it should say so, not guess), whether your data trains models shared with other customers, where data is hosted, whether a current SOC 2 Type II report is available, and whether pricing is per-resolution or flat-rate at your expected volume.
What's the difference between a chatbot RFP and a general software RFP?
A general software RFP covers uptime, support, and contract terms — all still relevant for a chatbot. A chatbot RFP adds AI-specific sections a generic template misses entirely: RAG and source-citation requirements, hallucination-handling and graceful-abstention behavior, explicit language on whether customer data trains shared models, and AI Act transparency disclosure obligations that do not apply to ordinary SaaS purchases.
Can I use this AI chatbot RFP template directly, or do I need to convert it to Word?
The template on this page is written to be copied directly — the 11 sections, bullet questions, and scoring matrix can be pasted into a Word or Google Docs file as-is. There is no separate download; the page itself is the usable, up-to-date version, which also means it stays current as pricing models and compliance deadlines change.
What GDPR questions should be in an AI chatbot RFP?
Ask where data is physically stored and what transfer mechanism applies if it leaves the EU (GDPR Chapter V), whether a Data Processing Agreement is available listing all sub-processors (GDPR Article 28), what the conversation-log retention period is, whether logs can be deleted on request, and how data is encrypted in transit and at rest.
How is an AI chatbot RFP scored?
Score each vendor against a weighted matrix agreed before proposals arrive — for example, RAG accuracy and source citation at 25%, security and compliance at 20%, total cost of ownership at your actual volume at 20%, functional fit at 15%, integrations at 10%, and SLA/support at 10%. Adjust weights to your use case: a healthcare or legal deployment should weight security and compliance more heavily.
What's the difference between per-resolution and flat-rate chatbot pricing?
Per-resolution pricing bills per conversation the AI resolves without human escalation, which scales unpredictably with traffic spikes and campaigns. Flat-rate pricing bills a fixed monthly amount for a plan tier (message and character caps), which is easier to budget but requires understanding what happens if you exceed the cap. Always request a total-cost-of-ownership estimate at your actual projected volume, not just the list price, regardless of model.
Should I require SOC 2 certification from every AI chatbot vendor?
For any vendor handling customer conversation data, request a current SOC 2 Type II report at minimum — it verifies security controls operated effectively over an observation period, not just that they existed on one date. Smaller or early-stage vendors may not yet have one; in that case, ask for their compliance roadmap and equivalent controls (encryption, access logging, incident response process) as a substitute during evaluation.
Evaluating vendors against this RFP?
Test Heeya's RAG grounding and hallucination handling yourself — flat-rate pricing, EU data hosting, and no training on your data. Anas Rabhi and the Heeya team are available if you have vendor-evaluation questions.
