Reading an AI vendor deck: a teardown.
Three claims that show up in almost every AI vendor pitch, and the questions that reveal which version of those claims actually ships.
Three claims that show up in almost every AI vendor pitch, and the questions that reveal which version of those claims actually ships.
A specific kind of meeting happens about three times a quarter. A vendor has been pitching one of our clients for two months. The client wants a second opinion before signing. We get the deck, the recorded demo, the references, the SOW draft. The ask is some version of tell us what's real in this pitch and what isn't.
The pitches are not identical, but they rhyme. Three claims show up in nearly every one. Each can be true or false depending on what's underneath. The right questions distinguish the two.
This post walks the three.
The most common version is reduces ticket response time by 60% or reduces processing time by 80% or cuts onboarding from two days to thirty minutes. The number is specific. The metric is operational. The slide is confident.
The question is not whether the number is true. The number is almost always true for the customer it was measured on. The question is what version of X and what version of baseline produced the number.
The questions that pry it open:
What credible looks like, on this claim: the vendor produces a baseline measurement methodology, a definition of the metric, an explanation of what else changed in the workflow, and a same-metric measurement at 6, 12, and 18 months. Reduces X by N% becomes a paragraph of context, not a slide.
This appears on the slide titled Get started in 10 minutes or No engineering team needed. The pitch is that the AI sits above your existing systems and just works.
If the AI is doing anything other than reading and writing through a browser, this is rarely true. The product touches your CRM. Or your ticketing system. Or your payroll. Or your file storage. Each touch is an integration. Each integration has authentication, data shape, rate limits, error handling, and edge cases. Out of the box is the demo, not the deployment.
The questions:
What credible looks like: the vendor produces an integration list with linked connectors, a deployment guide that runs more than five pages, and a customer success story at your scale with the integration scope documented. Out of the box doesn't appear in the operational documents. It appears only on the marketing slide.
This is the social-proof slide. It usually includes a logo, a name, a quote, and a number. The number is the same shape as Claim 1, but the social proof shifts the conversation from will this work to if it worked for them, it will work for me.
The substitution is the problem. It worked for them is a claim about a customer who is not you. The right questions surface the differences:
What credible looks like: a reference customer at your scale, in your sector, with your stack, willing to take a 30-minute call without a vendor chaperone. If the vendor produces this, the social-proof claim is real. If they can't, it isn't.
These questions aren't traps. They are the questions any operator would ask if they had time to ask them. Most operators don't, because the diligence pace expected of an SMB or mid-market buyer is a fraction of the diligence pace expected of an enterprise buyer, and the budget for outside help is a fraction of what makes outside help pencil.
The point of running the questions is not to embarrass the vendor or to win a debate. The point is to find out which version of the product will ship into your operation. The vendor's responses, asked in the spirit of buying rather than rejecting, are usually honest. When they aren't honest, you find out before signing.
If you'd like a second opinion on a deck you're sitting with, the discovery call is the right starting point. Send the deck ahead of time. We'll walk it with you.