How do you write an effective AI project RFP? Start with a clear business problem statement, not technical requirements. Include company context, desired outcomes, data availability, compliance requirements, a realistic budget range, and weighted evaluation criteria. Then ask the 15 targeted questions below that surface genuine expertise rather than polished salesmanship.
Most RFPs get generic responses because they ask generic questions. After responding to hundreds of RFPs over 19 years — and helping clients write them from the other side — I can tell you exactly what separates an RFP that gets useful, tailored proposals from one that gets copy-paste responses with your company name swapped in.
The difference is not length. Some of the worst RFPs I have seen were 40 pages. The difference is specificity, context, and structure. A well-written two-page RFP will get better proposals than a poorly structured 20-page one.
This guide gives you the exact structure, the questions to include, and the mistakes to avoid. Use it whether you are commissioning a £20K proof of concept or a £500K enterprise AI platform.
Why Most RFPs Fail
Before we talk about what works, let us be clear about why the standard approach fails. These are the five most common mistakes, and I see at least two of them in nearly every RFP that lands in our inbox.
Too vague
“We want to leverage AI to improve our operations.” This tells a vendor nothing. What operations? What does “improve” mean? What data do you have? Without specifics, vendors either ask 30 clarifying questions (which defeats the purpose of the RFP) or they make assumptions and propose something generic. The more vague your RFP, the more vague the proposals you receive.
Too prescriptive
The opposite problem. “We need a solution built in Python using TensorFlow with a React frontend deployed on AWS ECS.” Unless you have a strong technical reason for every one of those choices, you are constraining vendors from proposing the best solution. State the problem and the constraints. Let the vendors propose the approach. That is what you are paying them for.
Missing business context
An RFP that jumps straight to technical requirements without explaining the business problem forces vendors to guess your priorities. Why does this project matter? What happens if you do nothing? What does success look like in business terms? A vendor who understands your business context will propose a fundamentally better solution than one working from a requirements list alone.
Unrealistic timelines or budgets
If your budget is £30K and your requirements describe a £200K project, you will not get honest proposals. Vendors will either decline to respond or propose something that technically fits the budget but will not solve your problem. Be realistic. If you are not sure what realistic looks like, read our guide on what custom AI software actually costs.
Too many questions
I have received RFPs with 120 questions. The response took 40 hours to write. The quality of each answer was lower than if there had been 20 focused questions. Here is the paradox: the more questions you ask, the less thoughtful the answers become. Vendors have limited time to respond. Force them to spend that time on substance, not paperwork.
Many RFPs are written to justify a decision that has already been made. If your procurement process requires you to solicit three proposals when you already know who you want, at least be honest with the other vendors about the timeline and process. Good vendors can tell when they are making up numbers, and the best ones will stop responding to your future RFPs.
The Structure of an Effective AI RFP
This is a section-by-section template. Not every section will apply to every project, but this structure ensures vendors have the context they need to propose something genuinely useful.
A. Company overview and project context
What to include: Three to four paragraphs about your organisation, your industry, your size, and why this project exists now. What triggered the need? Is this a strategic initiative, a response to a competitor, a regulatory requirement, or an efficiency play?
Example: “[Company] is a mid-market insurance broker managing £120M in premiums annually. We process approximately 8,000 claims per year, currently handled by a team of 12 using a combination of spreadsheets and a legacy system from 2014. Processing time averages 4.2 days per claim. We are seeking an AI-assisted solution to reduce processing time to under 1 day while maintaining accuracy and compliance with FCA requirements.”
Common mistake: Skipping this entirely or providing a single sentence. Without context, vendors cannot assess fit or calibrate their approach.
B. Business problem statement
What to include: A clear description of the problem in business terms, not technical terms. What is the cost of the current situation? What is the impact on customers, revenue, or operations? Quantify wherever possible.
Example: “Our document review process requires senior analysts to manually read and categorise an average of 340 documents per week. This costs approximately £180K per year in analyst time and introduces a 48-hour delay in our client onboarding process. We estimate this delay costs us 15–20 potential clients per quarter.”
Common mistake: Describing the solution you want instead of the problem you have. “We need an AI document classifier” is a solution. The example above is a problem. Let vendors propose the solution.
C. Current state
What to include: How the process works today. What tools and systems are currently used. What has been tried before and why it did not work. This prevents vendors from proposing something you have already attempted.
Common mistake: Omitting previous failed attempts. If you tried a solution 18 months ago and it failed, vendors need to know why so they do not repeat the same approach.
D. Desired outcomes
What to include: Specific, measurable outcomes. Not “improve efficiency” but “reduce document processing time from 4.2 days to under 1 day” or “achieve 95% classification accuracy on incoming documents.” Define what success looks like at 3 months, 6 months, and 12 months post-launch.
Common mistake: Vague outcomes that cannot be measured. If you cannot define success, you will not know if the project delivered.
E. Technical environment
What to include: Existing systems, technology stack, cloud providers, integration points, and any hard constraints. If you are required to use Azure because of an enterprise agreement, say so. If your team only has Python expertise for ongoing maintenance, mention it.
Common mistake: Listing every system in your organisation instead of only those relevant to this project. Focus on what the new system needs to interact with.
F. Data availability
What to include: This is critical for AI projects and often missing. What data do you have? How much? What format? What quality? Is it labelled? Where is it stored? Are there access restrictions? An AI project without data is an AI project that will fail.
If you do not have clean, labelled training data, say so. A good vendor will include data preparation in their proposal. A bad vendor will assume the data is ready and give you a lower quote that explodes once they see reality. Honesty about data quality saves everyone time and money.
G. Compliance requirements
What to include: Industry regulations (FCA, HIPAA, GDPR), data sovereignty requirements (must data stay in the UK/EU?), security certifications required (ISO 27001, SOC 2), and any internal policies that constrain the technical approach.
Common mistake: Mentioning “GDPR compliance” without specifying what that means for this project. Are you processing personal data? What is the legal basis? Do you need a Data Protection Impact Assessment?
H. Budget range
What to include: A realistic range. “Our budget for this project is £50K–£80K.” Yes, include it. I address the objections to this in a dedicated section below.
Common mistake: Omitting the budget entirely or stating an unrealistic number. Both lead to proposals that do not match your reality.
I. Timeline expectations
What to include: When you need the solution live and why. Differentiate between hard deadlines (regulatory) and soft deadlines (preference). Include key dates: RFP response deadline, vendor selection date, project start date, go-live target.
J. Evaluation criteria
What to include: How you will score proposals, with weightings. This is one of the most valuable things you can include because it tells vendors exactly what to focus on. Example: Technical approach (30%), Team experience (25%), Cost (20%), Timeline (15%), Cultural fit (10%).
Common mistake: Not sharing evaluation criteria, which means vendors spend equal effort on everything instead of focusing on what matters most to you.
K. Submission requirements
What to include: Format, page limit, deadline, where to send it, and who to contact with questions. A Q&A period is essential — set a window for vendors to ask clarifying questions and share the answers (anonymised) with all participants.
The 15 Questions That Get Better Proposals
Include these questions in your RFP. Each one is designed to surface information that separates genuine expertise from polished salesmanship.
- Describe a project you have delivered that is most similar to ours. What were the key challenges and how did you overcome them?
Why it matters: Forces specifics instead of generalities. Reveals genuine experience versus marketing claims. - What approach would you recommend for this project, and why? What alternatives did you consider and reject?
Why it matters: Shows technical thinking. Vendors who only present one approach either lack breadth or are pushing their preferred stack regardless of fit. - Who specifically would work on this project? Provide CVs or profiles for the proposed team.
Why it matters: The team matters more than the company. A prestigious agency staffed with junior developers on your project will underperform a small team of senior engineers. - What data do you need from us, in what format, and when? What happens if the data quality is lower than expected?
Why it matters: AI projects live and die by data. Vendors who do not ask about data quality in their proposal have not thought seriously about your project. - Walk us through your development process from kickoff to launch, including milestones and review points.
Why it matters: Reveals operational maturity. Look for defined phases, client review points, and a realistic timeline with buffer. - How do you measure and validate AI model performance? What accuracy thresholds do you commit to?
Why it matters: Any vendor can build an AI model. The question is whether it works well enough for production use. Vendors should describe their validation methodology, not just promise “high accuracy.” - What are the biggest risks you see in this project, and how would you mitigate them?
Why it matters: Vendors who see no risks have not thought carefully about the project. Look for honest assessment and practical mitigation strategies. - How do you handle scope changes during the project?
Why it matters: Scope will change. A clear change management process prevents disputes and budget overruns. - What does post-launch support look like? Include warranty terms, response times, and ongoing maintenance options.
Why it matters: The project does not end at launch. Vendors who are vague about support are either planning to move on immediately or have not thought it through. - Provide a detailed cost breakdown by phase, role, and deliverable.
Why it matters: A single total number is useless for comparison. Detailed breakdowns reveal where the money goes and where there might be room to adjust scope. - What intellectual property do we retain? What components, if any, would we be licensing rather than owning?
Why it matters: You need to know exactly what you own at the end. If the vendor uses proprietary frameworks or tools, understand the licensing implications. - How do you ensure security throughout the development process? Describe your approach to code review, vulnerability testing, and data protection.
Why it matters: Security bolted on at the end is not security. Look for practices embedded throughout the development lifecycle. - What happens if this project needs to scale to 10x our current requirements? How does your proposed architecture accommodate growth?
Why it matters: Even if you do not need scale now, understanding the architecture’s ceiling prevents a costly rewrite later. - Can you provide two client references for projects of similar scope and complexity? We would like to speak with them.
Why it matters: References verify claims. Ask references specifically: “Was the project delivered on time and budget? Would you hire them again?” - What do you need from our team to ensure this project succeeds? Be specific about time commitment, roles, and responsibilities.
Why it matters: Vendors who say they need nothing from you are either planning to build in isolation (dangerous) or not being honest. Good projects require collaboration.
Writing an RFP now?
Book a free 30-minute consultation and we will review your draft — no obligation, even if KORIX is not on your vendor list.
Book a Free RFP Review →Should You Include Your Budget? (Yes.)
This is the most counter-intuitive advice in this guide, and I will stand behind it completely: always include your budget range in the RFP.
The objection I hear most often: “If I share our budget, every vendor will just quote that number.” This is not what happens in practice. Here is what actually happens:
Without a budget: Vendors have no way to calibrate their approach. A project can be solved for £30K with a simple, focused solution or for £300K with an enterprise-grade platform. Without knowing your range, vendors either guess conservatively (and you receive underwhelming proposals) or guess aggressively (and you receive proposals you cannot afford). Neither outcome serves you.
With a budget range: Vendors design a solution that fits your reality. They make informed trade-offs: “For £60K we would recommend approach A with these features. For £80K we could also include X and Y.” You receive proposals you can actually compare because they are solving the same problem within the same constraints.
The fear of overpaying is understandable but misplaced. You are not sharing a single number — you are sharing a range. A vendor who quotes the top of your range when the work only justifies the bottom will be exposed when you compare proposals. The budget range is a planning tool, not a negotiation ceiling.
“Our budget range for this phase of the project is £50K–£75K. We value proposals that maximise impact within this range and clearly articulate what would be achievable at both ends of the budget.”
That single sentence will improve the quality of every proposal you receive.
Evaluating Responses: A Scoring Framework
When proposals arrive, resist the temptation to flip to the pricing page first. Use a structured scoring matrix so that your evaluation is consistent and defensible. Here is a framework we recommend:
Running effective vendor demos
After scoring written proposals, invite your top two or three vendors for a demo or presentation. Structure these meetings identically so you can compare fairly:
- Same agenda for each vendor: 15 minutes for their presentation, 30 minutes for your questions, 15 minutes for their questions to you.
- Insist the proposed team attends, not just the sales team. You are evaluating the people who will do the work.
- Ask each vendor the same three to four challenging questions and compare the depth and honesty of their answers.
- Present a hypothetical scenario: “The data quality turns out to be worse than expected. What do you do?” The answer reveals how they handle adversity.
- Pay attention to the questions they ask you. The best vendors will ask probing questions about your business, data, and constraints. Vendors who do all the talking and none of the asking are performing, not problem-solving.
Common RFP Mistakes That Cost You Money
These are the patterns that consistently lead to poor outcomes. Avoid all of them.
Sending to too many vendors
Three to five is the right number. More than five and you cannot give each proposal the attention it deserves. You also create more work for yourself in the evaluation phase without meaningfully improving your options. Vendors also know when an RFP has been broadcast to 15 companies — the best ones will not respond because the odds are too low to justify the effort.
Not including a Q&A period
Set a one-week window after issuing the RFP for vendors to submit questions. Compile all questions and your answers into a single document and share it with all participating vendors. This ensures everyone works from the same information. Vendors who ask the best questions are often the best fit — pay attention to who asks what.
Rigid technology requirements
Unless you have a genuine constraint (regulatory, integration, team capability), do not dictate the technology stack. State the problem, the constraints, and the requirements. Let vendors propose the best technical approach. You are hiring them for their expertise — let them use it.
Evaluating on price alone
If your evaluation criteria weight cost at 50% or more, you will consistently select the cheapest option, which is rarely the best value. The cheapest proposal often becomes the most expensive project. A £40K quote that delivers a working solution is better value than a £25K quote that delivers something you have to rebuild.
Not checking references
References are listed in the proposal. Call them. Not via email — by phone. Ask specific questions: Was the project delivered on time? On budget? Would you hire them again? What was the biggest challenge? How did they handle it? A 15-minute phone call can save you from a six-month mistake.
Treating the RFP as the final decision
The RFP process identifies your best-fit vendor. But before signing a contract, invest in a paid discovery phase or pilot project. A two-week, £3K–£8K discovery engagement tells you more about a vendor than any proposal ever will. You see how they work, how they communicate, and whether the chemistry is right for a multi-month engagement.
At KORIX, we recommend every new client start with a paid discovery phase before committing to full development. The output — a detailed specification, architecture plan, and project roadmap — is yours to keep regardless of whether you proceed with us. It is the lowest-risk way to validate a vendor relationship.
We have condensed this guide into a fillable RFP template with all sections, example text, and the 15 questions pre-formatted. Email us at contact@korixinc.com with “RFP Template” in the subject line and we will send it over — no strings attached, no sales follow-up unless you ask for it.
A good RFP is specific, contextual, and structured. It asks 15 focused questions, not 120 generic ones.
Include your budget range. Share your evaluation criteria. Focus on the business problem, not the technical solution. The 15 questions in this guide will separate genuine expertise from polished salesmanship every time.
Recommended Reading
Should I include my budget in the RFP?
Yes. Always include a budget range (not a single number). Without it, vendors cannot calibrate their approach and you receive either underwhelming or unaffordable proposals. Read the full budget section for the reasoning.
How many vendors should I invite?
Three to five is the sweet spot. Fewer than three limits your options. More than five and you cannot evaluate each proposal properly. The best vendors will not respond to RFPs broadcast to 15 companies.
How long should an RFP be?
Two to five pages is usually sufficient. Quality matters more than length. A focused two-page RFP with the right sections will get better responses than a 40-page document full of generic requirements.
Should I prescribe the technology stack?
Only if you have genuine constraints (regulatory, integration, team capability). Otherwise, state the problem and let vendors propose the approach. You are paying for their expertise — let them use it.
How do I evaluate proposals fairly?
Use a weighted scoring matrix. We recommend: Understanding of problem (20%), Technical approach (25%), Team (20%), Cost (15%), Timeline (10%), Risk management (5%), Proposal quality (5%). See the full scoring framework above.