Evaluating a new vendor's sales deck without just believing it

Background

A vendor's sales deck and their security/compliance one-pager are both marketing documents, written to answer the questions that make the product look good and to stay quiet on the ones that don't. Reading one and asking an AI tool to "summarise the key points" just compresses the marketing - it doesn't tell you anything the vendor didn't already want you to know. The useful question isn't "what does this say", it's "what would a genuinely thorough buyer ask that this deck is carefully not answering".

That reframe turns a generic summarisation task into something worth doing before a procurement call: read the material specifically for absence - the certification it doesn't mention, the SLA number that's vague where every other number is precise, the data-residency question answered for one region and silent on yours.

Setup

The shape that gets past the marketing:

• Role - a sceptical buyer's advisor, not a summariser.
• Context - the actual sales/marketing material, read for what it avoids.
• Inputs - what actually matters for your organisation specifically (data residency, compliance framework, integration needs).
• Task - turn silence and vagueness into named questions for the call.
• Constraints - never treat marketing language as a verified claim.

Reading a vendor deck for what it doesn't say

You're a sceptical buyer's advisor reading a vendor's sales material,
looking for what it avoids answering, not summarising what it claims.

Context: I'll paste or describe a vendor's pitch deck, website copy, or
security one-pager. My organisation has specific requirements it needs to
meet. Flag anything it's vague about, silent on, or that reads like
marketing standing in for a fact.

Inputs:
- Vendor material: [PASTE OR SUMMARISE THE KEY CLAIMS]
- Our actual requirements: [e.g. UK/EU DATA RESIDENCY, A SPECIFIC
  COMPLIANCE FRAMEWORK, SSO VIA A SPECIFIC IDENTITY PROVIDER, AN SLA
  ABOVE A CERTAIN UPTIME]
- What we're replacing or comparing this against, if anything:
  [DESCRIBE, WITHOUT NAMING THE OTHER VENDOR IF THIS IS GOING BACK TO
  EITHER OF THEM]

Task: list every claim in the material that's precise and verifiable
(a specific certification, a specific uptime SLA, a named data centre
region) separately from every claim that's vague ("enterprise-grade
security", "industry-leading uptime", "GDPR compliant" with no
specifics). For each vague claim, write the exact question to ask on the
call that would force a specific answer.

Constraints: don't infer that a vague claim means the vendor is hiding
something bad - only that it's unverified. The output is a question list,
not an accusation.

Turning the question list into something the vendor has to answer specifically

A generic "tell us about your security" question in a sales call gets a generic answer. A specific one doesn't.

You're sharpening a list of vendor-evaluation questions so each one forces
a specific, checkable answer rather than a reassurance.

Context: turn each vague question into one that names the exact standard,
number, or document you want referenced in the answer.

Inputs:
- Draft questions: [PASTE THE LIST FROM ABOVE]
- Frameworks/standards relevant to us: [e.g. ISO 27001, SOC 2, A NAMED
  DATA PROTECTION REGULATION, A SPECIFIC UPTIME PERCENTAGE]

Task: rewrite each question so a vendor answering honestly has to cite a
specific certificate, number, region, or document - not a general
reassurance. E.g. turn "how do you handle security" into "which named
certifications do you currently hold, and can you provide the
certificate or audit summary directly, not a marketing page referencing
it."

Constraints: keep the list to the questions that actually matter for our
stated requirements - don't pad it with generic due-diligence questions
that don't connect to anything we actually need answered.

Scoring the answers you actually got back

After the call, the temptation is to write up an impression. Score it against the same specific criteria instead.

You're scoring vendor answers against the specific questions asked, not
against how confident the vendor sounded.

Context: I'll give you the question and the actual answer given on the
call. Score whether the answer was specific and verifiable, vague, or a
non-answer, and say what's still missing.

Inputs:
- Question and answer pairs: [QUESTION - ANSWER GIVEN, FOR EACH]

Task: for each pair, classify the answer as Verified (specific, checkable,
ideally with a document offered), Vague (a reassurance with no specific
backing), or Avoided (didn't actually answer the question asked). List
what document or confirmation would move each Vague or Avoided answer to
Verified.

Constraints: don't soften "Avoided" to "Vague" just because the vendor
sounded confident delivering it - score the content of the answer, not
the tone.