Verified against ChatGPT · 2026-08-12
Prep for a vendor contract review call so you walk in with the right questions, not just the document
Turns a vendor contract draft into a prioritized list of questions and points to raise on the review call, organized around what actually matters for this specific vendor relationship rather than a generic contract checklist.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Help me prepare for a review call about the vendor contract below by turning it into a prioritized list of questions and points to raise — not a legal review, a call-prep tool. VENDOR CONTRACT DRAFT Draft MSA from a cloud infrastructure vendor, including an SLA exhibit. WHAT WE'RE BUYING Managed database hosting for our production environment. WHY THIS VENDOR MATTERS TO US This would host our core production database — an outage here takes our whole product down. WHO'S ON THE CALL Our CTO, Head of Finance, and me (Operations Lead). PHASE 1: SCAN FOR WHAT NEEDS A QUESTION Read the draft and identify every place where the contract is vague, silent, or leaves something to the vendor's discretion on a point that matters to how we'd actually operate under it — SLA specifics, what happens on outage or breach, data ownership if we stop using the service, and price change mechanics are common blind spots but check the actual text, not just this generic list. PHASE 2: TURN EACH GAP INTO A QUESTION For each gap, write the actual question to ask on the call, phrased the way you'd say it out loud, not a restatement of the contract issue in legal terms. Prioritize by what would hurt most if left unresolved and only discovered later. PHASE 3: PREP TALKING POINTS FOR THE PARTICIPANTS Given who's on the call, note briefly who's best positioned to ask which question (a technical question probably lands better from whoever knows the technical stack, a budget question from whoever owns the budget). WHAT NOT TO DO Do not answer the questions yourself by guessing what the vendor's likely answer is — the point is to walk in prepared to ask, not to pre-fill the vendor's position. Do not state whether any specific term is legally enforceable or standard for this industry; flag it as a question for legal only if it seems like something outside what this team should decide informally. OUTPUT FORMAT 1. Prioritized question list (highest-stakes first), each phrased conversationally. 2. Suggested asker for each question based on who's on the call. 3. A short separate list of anything that should go to legal for review rather than be resolved live on the call. 4. A closing note that this is call-prep, not a legal review — the final contract should be reviewed by a qualified lawyer before signature, especially anything flagged for legal above.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Vendor contract calls tend to go badly not because someone missed a clause but because the gaps — the things the contract is silent about — never get surfaced until they matter, usually during an actual outage or dispute; scanning specifically for vagueness and silence rather than just "problems" targets that pattern directly, since a model asked to find problems in a contract will focus on what's explicitly there and can walk right past what was left out, which is exactly where operational risk with a critical vendor tends to hide. Phasing this into scan-then-question-then-assign keeps the questions grounded in the actual contract text instead of drifting into a generic "things to ask vendors" list — the named blind spots (SLA specifics, breach/outage consequences, data portability, price mechanics) are given as things to check for in this text, not asserted as present, which keeps the output tied to what this draft specifically does or doesn't say. Assigning a suggested asker based on the real call participants matters practically: a technical SLA question landing from the CTO carries different weight and gets a different quality of vendor answer than the same question from Operations, and skipping this step produces a list that reads right but doesn't map to how the actual conversation will unfold. The instruction against pre-filling the vendor's likely answer addresses a subtle failure where a model, having just identified a gap, immediately starts speculating about what the vendor probably means or intends — which defeats the purpose of a live question and can anchor the team on an assumption that turns out to be wrong when the vendor actually answers.
What you get back
1. "What happens to our data if we terminate the contract — do we get an export, and how long do we have to retrieve it?" — Suggested asker: CTO (technical/data implications). Priority: high, since this hosts our core production database. 2. "Can you walk us through exactly what counts as a qualifying outage under the SLA, and what the credit actually looks like in dollars?" — Suggested asker: Head of Finance. Legal review list: the liability cap language in Section 11 should go to legal before signature. This is call-prep, not a legal review — a qualified lawyer should review the final contract before signing.
Verified against
ChatGPT GPT-5.1 · 2026-08-12
Changelog
- 2026-08-12 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
