How to write an AI chatbot RFP

TL;DR

• An AI chatbot RFP forces vendors to answer the questions that actually predict success: what the bot is trained on, how it escalates, and how it's priced.

• Most teams write RFPs around features. Better RFPs are written around outcomes, specifically your resolution rate and your cost per resolution.

• The single most revealing question you can ask: "How do you define a resolved conversation, and will you put that definition in the contract?"

• You may not need an AI chatbot development company at all. If your knowledge already lives in docs and tickets, a self-serve platform can deploy in minutes without a build cycle.

• A copy-and-paste RFP template is included at the bottom of this post.

Buying AI chatbot services without an RFP is how teams end up six months into a contract with a bot that doesn't provide value to customers. The demo looked great. The proposal had every feature checked. Then it went live, and the gap between "responds to questions" and "solves problems" turned out to be enormous.

A request for proposal fixes this. Not because the document itself is magic, but because writing one forces you to define what you actually need before a salesperson defines it for you. It also forces vendors to answer in writing, which is a very different exercise from answering in a demo.

This guide walks through what belongs in an AI chatbot RFP, the questions that separate real platforms from rebadged FAQ bots, and a template you can lift directly.

First: do you even need a development company?

Before you send an RFP to a single AI chatbot development company, it's worth asking whether you need one.

The phrase "AI chatbot development services" implies a build. A vendor takes your requirements, develops a custom bot, and delivers it over a timeline measured in weeks or months. That model made sense when chatbots were custom-engineered systems. For a lot of support use cases in 2026, it no longer does.

If your support answers already exist somewhere (a help center, product docs, a history of resolved tickets) then the work isn't development. It's training. Modern platforms ingest that existing content and deploy a working agent without a custom build cycle. No statement of work, no development sprint, no integration project.

So the real first question is which of these two situations you're in:

• You need genuine custom development. Your use case is unusual, deeply integrated into proprietary systems, or requires capabilities off-the-shelf platforms don't offer. An RFP to development companies makes sense.

• You need a trained agent, fast. Your answers exist, your volume is growing, and you want something live soon. A platform RFP (or just a free trial) makes more sense than a development contract.

Most support teams are in the second situation and don't realize it. If you're not sure which applies to you, the signs your support team needs an AI agent are a useful gut check before you spend weeks on procurement.

The rest of this guide works for either path. The questions just get pointed at different types of vendors.

What to include in an AI chatbot RFP

A good RFP has six sections. Skip any of them and you'll be comparing vendors on incomplete information.

1. Context and goals. A short description of your company, your support operation, and what you're trying to achieve. Vendors give better answers when they understand the problem. Include your current ticket volume, your team size, and the specific outcome you want (for example, "resolve 50% of incoming tier-1 tickets without human involvement").

2. Scope of work. What you expect the chatbot to do. Be concrete. "Handle customer questions" is too vague to evaluate. "Resolve billing, account, and how-to questions across chat and email, escalating anything involving account security to a human" is something a vendor can actually scope.

3. Technical requirements. Your channels (chat, email, in-app), the systems it needs to connect to (your help center, CRM, billing tools), and any data or security constraints. If you have compliance requirements, state them here.

4. Vendor questions. The list of questions every vendor must answer in writing. This is the most important section and the one most teams under build.

5. Pricing request. Ask for a complete pricing breakdown, not a starting price. Specify that you want all fees disclosed: setup, per-seat, per-resolution, overage, and any annual commitment. Cost surprises live in the gap between the pricing page and the contract.

6. Timeline and evaluation criteria. When you need responses, how you'll evaluate them, and when you intend to decide. Tell vendors how you're scoring so the serious ones invest accordingly.

The questions that actually predict success

Most RFP question lists are full of items that sound rigorous but don't discriminate between good and bad vendors. "Do you support multiple languages?" gets a yes from everyone. Here are the questions that produce revealing answers.

The single most useful question on that list is how the vendor defines a resolved conversation. Some count a closed chat window. Some count a customer clicking "this helped." Some count any conversation that didn't escalate, including the ones where the customer gave up. That definition directly affects both your reported success metrics and, on per-resolution pricing, your bill. Get it in writing before you sign.

If pricing models are new to you, the breakdown of what AI support automation actually costs covers per-seat versus per-resolution in depth. Don't reproduce that analysis in your RFP. Just make sure your pricing request asks for the full picture.

Red flags in vendor responses

The responses tell you as much as the answers. Watch for these.

• Feature lists instead of outcomes. A vendor who answers "what's your resolution rate?" with a paragraph about their feature set is dodging. The number exists or it doesn't.

• "It depends" on the resolution definition. It can depend on your setup. It cannot be undefined. A vendor who won't commit to a definition in writing is protecting their flexibility at your expense.

• Setup described as a "project." If deploying the bot requires a multi-week professional services engagement, factor that cost and time into your comparison. It rarely appears on the pricing page.

• Escalation treated as an afterthought. If the answer to "what happens when the bot can't answer?" is thin, your customers will feel it. The handoff is where most chatbot experiences fall apart.

• Pricing that requires a call to understand. Opacity is a choice. Vendors confident in their pricing publish it.

The AI chatbot RFP template

Copy this, fill in the bracketed sections, and send it to your shortlist. It works for both development companies and platform vendors.

AI Chatbot RFP: [Your Company Name]

1. Overview [Company name] is seeking a proposal for an AI chatbot to support our customer service operation. We handle approximately [X] tickets per month with a team of [Y]. Our goal is to [resolve Z% of tier-1 tickets without human involvement / provide 24/7 coverage / reduce response times]. Responses are due by [date]. We intend to make a decision by [date].

2. Scope of Work The solution should: [resolve billing, account, and how-to questions / operate across chat and email / escalate account-security issues to a human]. It should not: [handle X / make changes to Y without verification].

3. Technical Requirements Channels: [chat, email, in-app]. Required integrations: [help center, CRM, billing system]. Data and security requirements: [list any compliance constraints].

4. Vendor Questions (please answer all in writing) a. What is your chatbot trained on, and can it learn from our documentation and resolved tickets? b. How do you define a resolved conversation? Will you include that definition in the contract? c. What is your average resolution rate, and how is it measured? d. What happens when the bot cannot resolve a query? Describe the escalation and what context transfers to the human agent. e. How does the system improve over time? Does it require manual retraining? f. Provide a complete pricing breakdown including setup, recurring, per-resolution or per-seat, overage, and any minimum commitment. g. What is the realistic timeline from contract to go-live? h. Who owns the data and the trained model?

5. Pricing Please provide full pricing for [expected volume], including all fees. Model the cost at our current volume and at 3x our current volume.

6. Evaluation Criteria We will evaluate proposals on resolution capability, escalation quality, pricing transparency, time to deploy, and fit with our existing stack.

The faster path, if you have one

An RFP is the right tool when you're committing to a significant contract or a custom build. But it's worth saying plainly: if your support answers already exist in your documentation and resolved tickets, you may not need the RFP cycle at all.

Platforms built for this connect to your existing content and deploy a trained agent in minutes, not months. You can evaluate them by trying them, which is a faster and more honest test than any proposal. A bot that resolves your real tickets in a free trial tells you more than a vendor's best answer.

Weav is built for exactly that path. Connect your docs, deploy an agent across chat and email, and see your real resolution rate before you commit to anything. If you're weighing specific vendors against each other, the comparison of the best AI agents for customer support lays out where each one fits.

The RFP exists to protect you from buying the wrong thing. Sometimes the best way to use it is to discover you didn't need to send it.

Evaluating your options? See how Weav handles resolution, escalation, and builds AI agents at weav.com/product, or compare the field in our roundup of the 8 best AI agents for customer support.