AI Consultant RFP Template &
Vendor Evaluation Scorecard (Free)

Give vendors enough context to propose intelligently. Vague context produces vague proposals — and vague proposals are impossible to compare.

• 1.1 Company overview: [Legal name, industry, headcount, locations, annual revenue band]
• 1.2 What we do: [2-3 sentences describing your core products/services and customers]
• 1.3 Why we are issuing this RFP: [The business problem or opportunity driving this initiative — in business terms, not technology terms]
• 1.4 What success looks like in 12 months: [e.g. "Quoting turnaround reduced from 3 days to 4 hours" — measurable outcomes, not activities]
• 1.5 Executive sponsor and decision process: [Who owns this decision, who evaluates proposals, target decision date]
• 1.6 Budget guidance: [State a range or band if you can — it filters out mismatched vendors and produces realistic proposals]

Describe your starting point honestly. Consultants price uncertainty — the more accurately you describe your systems and data, the sharper the proposals.

• 2.1 Core business systems: [ERP, CRM, industry-specific platforms — names and versions]
• 2.2 Where our data lives: [Databases, document stores, spreadsheets, paper — be honest about the messy parts]
• 2.3 Data quality self-assessment: [Structured and clean / partially structured / largely unstructured or inconsistent]
• 2.4 Current AI usage: [Any tools already in use, officially or unofficially, including employee use of consumer AI tools]
• 2.5 In-house technical capability: [IT team size and skills; any prior automation or integration projects]
• 2.6 Known constraints: [Legacy systems that cannot change, regulatory requirements, union or workforce considerations, data residency requirements]

Define what is in and out of scope. If you do not know the right scope yet, say so and ask vendors to propose a scoping phase — that is a legitimate first engagement.

• 3.1 Processes/workflows in scope: [List the specific workflows you want addressed, with rough volumes — e.g. "800 invoices/month processed manually"]
• 3.2 Explicitly out of scope: [Anything vendors should not propose against]
• 3.3 Deliverables expected: [e.g. readiness assessment report, working pilot in production, staff training, documentation, post-deployment support]
• 3.4 Systems the solution must integrate with: [Name each one]
• 3.5 Users of the solution: [Roles, headcount, technical comfort level]
• 3.6 Preferred engagement structure: [Fixed-scope project / phased with go-no-go gates / retainer — or ask vendors to recommend]

The heart of the RFP. Require specific written answers to every question — “we take security seriously” is not an answer, it is an evasion.

• Experience
• 4.1 Describe three AI implementations you have delivered to production. For each: industry, problem, solution, measurable outcome, and current status.
• 4.2 How long have you been delivering AI consulting specifically (not general IT consulting)? What did your firm do before?
• 4.3 Who, by name and role, would work on our engagement? What is each person’s direct AI delivery experience?
• References
• 4.4 Provide three client references we may contact, at least one in an industry comparable to ours.
• 4.5 Describe an AI engagement that did not go as planned. What went wrong and what did you change?
• Data governance
• 4.6 What data of ours would you need access to, and how would you handle, store, and dispose of it?
• 4.7 Where would our data be processed and stored geographically? Which third-party AI services would receive it?
• 4.8 How do you ensure our data is not used to train models accessible to others?
• Model strategy
• 4.9 How do you decide between cloud AI APIs, private/self-hosted models, and fine-tuned models? Walk us through the decision for a client like us.
• 4.10 How do you protect us from vendor and model lock-in as the AI market changes?
• 4.11 How do you handle AI errors and hallucinations in production systems? What validation and human-review controls do you deploy?
• Security & PIPEDA
• 4.12 How does your proposed approach comply with PIPEDA? Have you completed privacy impact assessments for AI systems before?
• 4.13 How are you preparing clients for AIDA and forthcoming Canadian AI regulation?
• 4.14 Describe your security practices: access controls, encryption, incident response, and any certifications or audits.
• Post-deployment support
• 4.15 What support do you provide after go-live, for how long, and at what cost?
• 4.16 How do you transfer knowledge so our team can operate — and eventually extend — the system without you?
• 4.17 What ongoing costs (API usage, hosting, licenses, maintenance) should we expect in years one and two? Provide estimates.

Force pricing into a comparable structure. Proposals priced on different bases cannot be compared, and that ambiguity always favours the vendor.

• 5.1 Provide pricing broken down by phase: assessment, pilot, production deployment, training, and post-deployment support.
• 5.2 State your pricing model for each phase (fixed price, time and materials, retainer) and why.
• 5.3 List everything NOT included in your price that we will need to pay for (cloud/API costs, licenses, hardware, travel).
• 5.4 What are your payment terms, and are any payments contingent on acceptance criteria being met?
• 5.5 If the pilot fails to meet its success criteria, what do we owe and what are our exit options?
• 5.6 Provide an estimate of ongoing operational costs after deployment (monthly or annual).

Score every vendor on the same weighted criteria, independently by each evaluator, before discussing. Weights below are our recommended starting point — adjust to your risk profile, but fix them before proposals arrive.

A realistic selection process for a mid-market AI engagement runs six to eight weeks. Compressing it below four weeks reliably produces worse decisions than the delay would have cost.

• Week 1: Issue RFP to a shortlist of 3-5 qualified firms. (Mass-blasting 15 firms produces volume, not quality.)
• Week 2: Vendor Q&A window — collect questions, answer all vendors identically in writing.
• Weeks 3-4: Proposals due. Independent scoring by each evaluator using the Section 6 scorecard.
• Week 5: Finalist presentations (top 2-3). Require the actual delivery team to present, not just sales.
• Week 6: Reference checks on finalists. Call every reference; ask about problems, not just satisfaction.
• Week 7: Negotiate terms with the preferred vendor — scope, acceptance criteria, exit clauses, IP ownership.
• Week 8: Award, kickoff, and begin with the assessment or pilot phase — never with the full transformation.

Any one of these is a caution; two or more is a disqualifier. Share this list with your whole evaluation team.

• Guaranteed outcomes before any assessment of your data or systems ("We will cut your costs 40%").
• A precise fixed price quoted before they have asked a single question about your data readiness.
• No production references — only pilots, demos, or "confidential" clients who can never be contacted.
• Evasive or generic answers on data handling, PIPEDA, or where your data physically goes.
• Proposals that skip straight to enterprise-wide deployment with no pilot phase or success gates.
• The senior people who pitched vanish after signing, replaced by an unnamed delivery team.
• Everything is one model or one vendor’s stack, regardless of your requirements ("hammer looking for nails").
• No mention of training, change management, or post-deployment support anywhere in the proposal.
• Pressure to sign quickly, discounts that expire this week, or resistance to written answers on the record.