Most AI vendor meetings follow a predictable pattern: a polished demo calibrated to your stated problem, a slide deck full of recognizable logos, and a pricing conversation you weren't ready for. Companies that get real value from these meetings walk in with a different agenda — they've prepared their context, they have specific questions written down, and they know exactly what a red flag looks like when they hear it. This template is designed for first meetings with AI vendors or consultants, whether it's an initial discovery call, a solution demonstration, or a pre-engagement scoping session. Complete Part 1 before the meeting. Run through Parts 2–6 during it. Part 7 is your post-meeting debrief and scoring.
Why Most AI Vendor Meetings Waste Everyone's Time
The average AI vendor meeting produces three outcomes: the vendor learns your problem well enough to personalize their next pitch, you leave with a vague sense of whether the solution 'might work,' and your calendar has a follow-up call you'll feel guilty about declining. This happens because buyers arrive passive — they accept the vendor's meeting agenda rather than setting their own.
The meetings that produce real decisions are structured differently. The buyer has done 30 minutes of preparation: they've written down the exact process they're trying to improve, they have 3–5 specific metrics they want to move, and they have a list of questions that genuinely differentiate vendors — questions where different vendors will give meaningfully different answers. That preparation puts the buyer in control of the conversation.
This template gives you that preparation structure. It also provides a consistent scoring framework so your final decision is driven by fit and track record, not by who gave the most impressive demo.
Part 1: Before the Meeting — What to Prepare
Complete this section before the meeting and share it with everyone attending from your side.
Your problem statement (one sentence): Write down exactly what process or outcome you're trying to improve. Be specific. 'Improve customer service' is not a problem statement. 'Reduce first-response time for support tickets from 4 hours to under 1 hour, and deflect 40% of tickets that have existing FAQ answers' is.
Current baseline metrics: What are the numbers today? Volume (how many tickets, invoices, or applications per month), time per unit, error rate, cost per unit, headcount involved. Without a baseline, you cannot evaluate a vendor's ROI claims or compare their projected results to your current state.
Your data inventory: What systems are involved in this process today? ERP, CRM, helpdesk, homegrown database? What format is the data in? How much history do you have? Knowing this before the meeting lets you quickly pressure-test whether the vendor's solution can actually connect to your stack.
Your decision timeline: When do you need a solution in production? Working backwards from that date tells you what evaluation window you're working with and whether a proof of concept or pilot fits your schedule.
Who is in the room: Confirm who from your side is attending. You want at least a business owner who understands the process, someone with technical authority who can evaluate integration claims, and a clear line to the decision-maker.
Part 2: Questions About the Solution and Its Results
These questions separate solutions that have been proven in production from ones that are still primarily demo-ware.
1. Walk me through a customer similar to us — same industry, similar company size, similar use case. What did their results look like 90 days after go-live? 12 months after?
2. What is the realistic range of outcomes your customers see for our specific metric? What separates the customers at the top of that range from those at the bottom?
3. What assumptions does your ROI model make? What has to be true about our data, our workflow, or our team for us to hit those numbers?
4. What percentage of your customers are actively using the product 12 months after signing? What's your average NPS among customers who've been live for at least a year?
5. What does this solution not do well? Where have you seen customers struggle or get results below expectations?
6. Can we speak with two or three reference customers in our industry — specifically ones who didn't have a perfectly clean implementation?
Listen carefully to how vendors answer questions 5 and 6. A vendor who can't articulate their solution's limitations and who offers only pre-vetted references is managing your perception, not helping you make a good decision.
Part 3: Questions About Data and Integration
Data and integration issues kill more AI implementations than any other factor. These questions surface problems before you sign a contract.
1. What data sources does your solution need to access, and what format does the data need to be in?
2. We currently use [list your systems — ERP, CRM, helpdesk]. Do you have pre-built integrations with these, or does connecting to them require custom development?
3. What happens when the input data is messy or inconsistent? How does your solution handle edge cases, missing fields, or data quality problems?
4. Do you need access to our data to train or fine-tune the model, or does the solution work on general training data? If you use our data for training, who owns the model outputs?
5. What data leaves our environment and goes to your infrastructure? What data is passed to third-party model providers? Do you have a Business Associate Agreement available if we have HIPAA-covered data?
6. What does an integration timeline typically look like for a company at our stage? What are the most common causes of integration delays?
Pay attention to whether the vendor has an honest answer to question 3. Solutions that perform well on clean data often degrade sharply on real-world inputs. Ask what the fallback is when the model is uncertain — does it flag for human review, or does it silently produce a guess?
Part 4: Questions About Implementation and Ongoing Support
The signature date is not the finish line — it's the starting pistol. These questions tell you whether the vendor has an implementation program that matches how your team actually operates.
1. Who on your team leads our implementation? Are they an employee or a third-party partner? What is their current client load?
2. Walk me through a typical implementation timeline. What are the phases, what do you own, and what do we own?
3. How much time do you estimate our internal team will need to dedicate during implementation? Which roles?
4. What is the most common reason implementations run over schedule, and how do you handle it when that happens?
5. After go-live, what does ongoing support look like? What's your SLA for issue response? Do we have a named customer success manager or a support ticket queue?
6. How do you handle model updates and improvements? Do you push updates automatically, or do we control versioning?
7. If we decide this isn't working and need to exit, what does offboarding look like? Can we export our data and configurations?
Question 7 is not a negotiating tactic — it's a due diligence requirement. Any vendor who becomes uncomfortable discussing the exit process has something to hide about their off-ramp.
Part 5: Questions About Pricing and Contract Terms
AI vendor pricing is less standardized than traditional SaaS. These questions prevent the surprises that emerge after you sign.
1. Walk me through the full pricing structure. What's included in the base price, and what are the add-ons?
2. How does pricing scale? Is it per seat, per API call, per transaction, per GB processed? What does cost look like if our volume doubles?
3. Are there implementation fees, onboarding fees, or integration fees separate from the subscription?
4. What are the payment terms — annual upfront or monthly? Is there a discount for multi-year commitments?
5. What is the minimum contract length? What happens if we need to cancel before the term ends?
6. How much have you adjusted prices in the last two years? Are there contractual caps on annual price increases?
7. Are there usage overage fees? If we exceed the volume included in our plan, how is that billed?
For AI specifically, watch for pricing tied to underlying model API costs. If a vendor passes through API costs as a variable line item, your monthly bill can shift significantly when model pricing changes or when usage increases. Ask whether their pricing is gross-margin-protected or pass-through.
Part 6: Red Flags Checklist
Note if any of these appear during the meeting:
Demo only works on vendor-prepared data: If the vendor won't run the demo on your actual data or a representative sample, the solution may not handle real-world inputs well. A request to demo on your data is reasonable — a refusal is a red flag.
Vague or deflected answers about limitations: Every AI solution has failure modes. A vendor who claims their solution 'works across all use cases' or won't answer the limitations question honestly doesn't trust you with the truth.
Reference customers are pre-screened and coached: Ask whether you can reach out to the reference independently, or whether the vendor needs to 'set up' the call. The latter means the reference has been briefed on what to say.
Accuracy claims without methodology: '98% accuracy' means nothing without knowing — accuracy on what task, measured how, on what data distribution. Ask for the evaluation methodology behind any headline accuracy number.
Pressure to sign this quarter for a discount: Fiscal quarter pressure is a negotiating tactic, not a business reason. If the product is the right fit, it will be the right fit next month. If the discount disappears, push for equivalent value in other contract terms.
No clear data ownership and portability terms: If the vendor can't answer clearly who owns the model fine-tuned on your data and whether you can export it, get legal involved before signing.
Single-person implementation team: For any deployment of material complexity, one implementation manager handling 20+ clients simultaneously is a capacity problem. Ask about their team's current workload before committing.
Part 7: After the Meeting — Scoring and Next Steps
Complete this within 24 hours of the meeting, while details are fresh.
Impression score (1–5): Overall quality of the meeting and vendor's ability to answer your questions clearly and honestly.
Solution fit (1–5): How closely did their solution match your specific use case and requirements?
Data and integration confidence (1–5): Based on their answers, how confident are you that integration will go smoothly with your current systems?
Implementation quality (1–5): Do they have a credible, well-resourced implementation program?
Pricing alignment (1–5): Is their pricing model predictable and within your budget at scale?
Composite score: Average the five dimensions. Use this to compare across vendors, not as an absolute measure.
Required before final decision: Speak to at least two independent reference customers. Do not proceed to contract without this step.
If pursuing further: Define proof of concept success criteria before the POC starts — what metric, what threshold, over what time period, on what data. A POC without predefined success criteria is a sales activity, not an evaluation.
Decision timeline: Note your next step, who owns it, and the date by which you'll make a decision. Share this with the vendor.
Adapting This Template for AI Consultant Meetings
If you're meeting a consultant rather than a software vendor, adjust your questions to the consulting context.
Replace solution questions with methodology questions: Ask: 'Walk me through a typical engagement with a company at our stage. What do the first 90 days look like?' 'What frameworks do you use for use case prioritization and ROI modeling?' 'Where do most of your clients encounter unexpected challenges?'
Ask about the team delivering the work, not just the person in the meeting: Consultants often sell with a senior partner and deliver with junior staff. Ask specifically who will be doing the day-to-day work, what their background is, and how much of the senior partner's time you'll actually get after the contract is signed.
Understand their tool and vendor relationships: Some AI consultants have preferred tool partnerships that influence their recommendations. Ask directly: 'Do you have any referral or revenue-share relationships with specific vendors? If so, which ones?' A trustworthy consultant will answer this without hesitation.
Define outputs and success criteria upfront: Consulting engagements can run indefinitely without clear deliverables. Before signing, agree on: what are the specific outputs (report, implemented system, trained team, running dashboard), by what date, at what quality bar, and what happens if the engagement runs over scope.
Check references specifically from recent engagements: Consultant references from five years ago aren't useful. Ask for references from engagements completed in the last 18 months at companies at a similar stage and in a similar industry.
Frequently Asked Questions
Frequently Asked Questions
Three to five for a significant procurement — annual contract over $30,000 or a production system affecting core operations. Two may be sufficient for lower-stakes tools or when the market has limited competitive options. More than five creates diminishing returns and delays your decision without proportional information gain. Run the first round broadly, then do in-depth evaluation (proof of concept, reference calls, contract review) with your top two.
Share a representative sample, not your full dataset. The sample should reflect your real data's variety and messiness — not the cleanest examples — and should be scrubbed of any sensitive PII or regulated data unless you have a signed NDA and Data Processing Agreement in place. A vendor who can't run a credible demo on a realistic data sample is a signal worth noting: if they can't handle messy data in a demo, they likely can't handle it in production either.
A POC is a technical exercise: can this solution work with our data and integrate with our systems? A pilot is a business exercise: does this solution deliver the expected business outcomes in a real workflow with real users? POCs typically run 2–6 weeks. Pilots typically run 60–90 days. Both require predefined success criteria established before they start. Most companies need both — a POC to validate technical feasibility, then a limited pilot to validate business value before full deployment.
Calmly. Quarter-end pressure is a standard sales tactic that has nothing to do with whether the product is right for you. If the vendor is the right choice, ask for the same discount in exchange for a commitment to sign within a defined window after your evaluation is complete — typically 30–45 days. Most reputable vendors will accommodate a conditional commitment if you've genuinely engaged in the evaluation process. If they won't negotiate at all, that rigidity tells you something about how they handle post-contract requests too.
Ready to Get Started?
Find an AI ConsultantRelated Specialties
More Resources
90-Day AI Pilot Plan Template: Week-by-Week Execution Guide
A week-by-week 90-day AI pilot plan that gets real results. Covers kickoff, data prep, build, integration, training, launch, monitoring, and the go/no-go decision.
AI Acceptable Use Policy Template (For Small and Mid-Sized Businesses)
A plain-English AI acceptable use policy template — who can deploy AI, what data is off-limits, disclosure rules, and audit requirements. Adapt in 30 minutes.
AI Budget Calculator: How Much Should You Spend?
Estimate your AI implementation budget by company size, project complexity, and goals. Real benchmarks for consulting, model API spend, infrastructure, and ongoing costs.