What each part of the prompt does
- Must-haves as a gate
- Running pass or fail checks before any scoring stops a cheap vendor that lacks single sign-on, or a required data region, from winning on price. Out is out, with the reason on record.
- Total cost over the term
- List prices hide setup fees, paid training, seat minimums and add-ons. Summing every cost line across [TERM] is usually where the ranking shifts, and the table shows exactly which line moved it.
- Claimed versus verified
- Sales decks describe the roadmap as if it already shipped. Keeping claims apart from what you saw working in a demo or trial lets the reader weigh each strength by the evidence behind it.
- What would change the call
- A recommendation that names its own breaking point, such as a price rise or a failed security review, is easier to approve, because the decision-maker can see the assumptions and test them.
Variations to try
Same idea, one thing changed.
Two vendors, quick version You are a procurement analyst writing a short memo that lets a busy decision-maker choose between vendors. <context> What we need to buy and why: [NEED] Vendors being compared: [VENDORS] Quotes, proposals, demo notes and pricing pages: [VENDOR MATERIAL] Must-haves we will not compromise on: [MUST HAVES] Budget and contract term: [BUDGET], [TERM] Who decides: [DECISION MAKER] </context> <instructions> 1. Turn the must-haves into pass or fail checks and test every vendor against them first. A vendor that fails one is listed as out, with the reason. 2. For the remaining vendors, add up the total cost over [TERM]: licence or unit price, setup, training, add-ons and any minimum commitment found in the material. 3. Compare them on fit to the need, implementation effort, support, contract terms, and the cost of switching away if it goes wrong. 4. Recommend one vendor with the two strongest reasons. State what would make you change the recommendation. 5. List the questions each vendor still needs to answer before we sign. </instructions> <constraints> - Use only facts found in the vendor material. Where a figure is missing, write [ASK VENDOR] instead of estimating it. - Keep what a vendor claims apart from what we verified in a demo or trial. - Keep the memo neutral; the recommendation is the only place for opinion. - Keep the whole memo under 300 words. </constraints> <output_format> Recommendation: two sentences at the top, written for [DECISION MAKER]. Must-have check: a table with one row per vendor and a column per must-have, marked Pass, Fail or Unknown. Cost comparison: a table with each cost line per vendor and the total over the term. Trade-offs: three bullets per vendor, strongest first. Open questions: bullets grouped by vendor. </output_format>
Software with a security review You are a procurement analyst writing a short memo that lets a busy decision-maker choose between vendors. <context> What we need to buy and why: [NEED] Vendors being compared: [VENDORS] Quotes, proposals, demo notes and pricing pages: [VENDOR MATERIAL] Must-haves we will not compromise on: [MUST HAVES] Budget and contract term: [BUDGET], [TERM] Who decides: [DECISION MAKER] </context> <instructions> 1. Turn the must-haves into pass or fail checks and test every vendor against them first. A vendor that fails one is listed as out, with the reason. 2. For the remaining vendors, add up the total cost over [TERM]: licence or unit price, setup, training, add-ons and any minimum commitment found in the material. 3. Compare them on fit to the need, implementation effort, support, contract terms, and the cost of switching away if it goes wrong. 4. Recommend one vendor with the two strongest reasons. State what would make you change the recommendation. 5. Check each vendor's material for security and compliance items: single sign-on, data residency, certifications such as SOC 2 or ISO 27001, and data deletion when the contract ends. Mark anything not stated as [ASK VENDOR]. 6. List the questions each vendor still needs to answer before we sign. </instructions> <constraints> - Use only facts found in the vendor material. Where a figure is missing, write [ASK VENDOR] instead of estimating it. - Keep what a vendor claims apart from what we verified in a demo or trial. - Keep the memo neutral; the recommendation is the only place for opinion. </constraints> <output_format> Recommendation: two sentences at the top, written for [DECISION MAKER]. Must-have check: a table with one row per vendor and a column per must-have, marked Pass, Fail or Unknown. Cost comparison: a table with each cost line per vendor and the total over the term. Trade-offs: a short paragraph per remaining vendor. Open questions: bullets grouped by vendor. </output_format>
If the result isn't right
- Paste each vendor's material under its own heading inside [VENDOR MATERIAL]; notes mixed together are the main reason a feature gets credited to the wrong company.
- Send the Open questions section to each vendor as written; their answers, or their silence, often settle a close comparison.
- Keep [MUST HAVES] to five or fewer. A long list turns every vendor into a Fail and the memo stops helping anyone decide.