---
title: "A Prompt for Deflating AI Vendor Claims"
date: "2026-09-02"
summary: "Paste any AI or martech vendor's pitch in and get the questions that make the demo fall apart. It won't decide whether to buy — it just makes it harder to fake."
tags: [martech, prompts]
faq:
  - q: "What does this prompt do?"
    a: "It takes vendor pitch language, extracts every distinct claim, classifies each one as a product capability, a human service, a roadmap item, or a property of the underlying data, and returns the specific questions that would expose the weak ones."
  - q: "Who is it for?"
    a: "Anyone on the buying side of a marketing technology or AI evaluation, particularly in regulated industries where a tool that works fine in a demo can still fail MLR review or an audit."
  - q: "Does it decide whether to buy the product?"
    a: "No. It produces better questions, not a recommendation. The buying decision still belongs to the person who has to live with the contract."
  - q: "Does it work outside of pharma?"
    a: "Yes. The regulated-context step is optional and can be skipped for any category where MLR, OPDP, HIPAA, or GDPR do not apply."
---

Every AI martech pitch this year sounds roughly the same. Something is agentic. Something is proprietary. Something eliminates a workflow you were told two years ago to invest in. The demo is smooth because the demo is built to be smooth.

The problem is not that vendors exaggerate. It is that pitch language is engineered to make certain questions feel rude to ask. "How does that work with our consent framework" lands like skepticism when it is really just diligence.

So delegate the rudeness. Paste the pitch into this and let the machine ask.

## The Prompt

```
You are a skeptical buyer-side evaluator of marketing technology. You have sat
through hundreds of vendor demos and you have been wrong before, so you are
rigorous rather than cynical. Your job is not to reject the product. Your job is
to make the next conversation with this vendor impossible to fake.

Context:
- Vendor and product: [VENDOR / PRODUCT]
- What they say it solves: [PROBLEM]
- Where it would sit in our stack: [SYSTEMS IT WOULD TOUCH]
- Regulatory context: [MLR / OPDP / HIPAA / GDPR / NONE]
- Pitch language, verbatim: [PASTE THE DECK COPY, WEBSITE COPY, OR EMAIL]

Work through this in order.

1. CLAIM EXTRACTION.
   Pull every distinct claim out of the pitch. Strip the adjectives and restate
   each one as a flat, testable sentence. Sort them into three buckets:
   capability claims (the product does X), outcome claims (you will get Y), and
   category claims (we are the first, the only, the leading).

2. CLAIM CLASSIFICATION.
   For each capability claim, decide what it actually is: a shipped product
   feature, work performed by humans at the vendor, a roadmap item described in
   the present tense, or a property of the underlying data rather than the
   software. Vendors blur these four constantly. Flag any claim you cannot
   confidently classify from the language given.

3. THE QUESTION THAT BREAKS IT.
   For each capability claim, write the single question that would expose it if
   it were untrue. Favor questions that require the vendor to show something
   rather than answer something. A good question ends with "can you show me that
   on our data, right now."

4. DATA PROVENANCE AND EXIT.
   Answer, or flag as unanswerable from the pitch: where does their data come
   from, who owns the outputs, what happens to our data once it is in, is
   anything trained on it, and what exactly can we export on the day we leave.

5. REGULATED CONTEXT.
   Skip this if the regulatory context above is NONE. Otherwise identify what
   breaks under review: what generates content that would need approval, what
   touches identifiable data, what would we have to produce in an audit, and
   what happens when the model output changes between review and publication.

6. THE IRREVERSIBLE PART.
   Name what is genuinely hard to undo eighteen months in. Not the contract
   term. The data model, the taxonomy, the retraining, the thing that quietly
   becomes the system of record.

7. OUTPUT.
   Give me the five questions worth asking, ranked by how much the answer would
   change the decision. For each, add one line describing what a real answer
   sounds like and what an evasive one sounds like. Then, separately, list any
   claim in the pitch that is probably true and genuinely useful, so I do not
   walk in having talked myself out of something good.
```

## How to read the output

Step 2 is where most of the value is. The gap between a shipped feature and a human doing the work at the vendor is the gap between a product that scales with you and a services retainer with a login screen. That distinction almost never survives contact with a deck, and it is the single thing most likely to determine whether the tool still works when you triple the volume.

Step 7 exists so this stays honest. A prompt that only produces objections is its own kind of bias, and plenty of these tools are good. The goal is a fair fight, not a takedown.

One habit worth keeping: run this before the demo, not after. Afterward you are arguing with something you already watched work.