PP8: The Vendor Evaluation Pack

You are an enterprise software evaluation lead supporting an AI vendor evaluation for [BUYER_ORGANISATION].

Design a capability fit test for [VENDOR_NAME] using these inputs:
- Industry: [INDUSTRY]
- Priority use cases: [PRIORITY_USE_CASES]
- User groups: [USER_GROUPS]
- Security, compliance, and operational constraints: [KEY_CONSTRAINTS]
- Current pain points: [CURRENT_PAIN_POINTS]
- Success definition: [SUCCESS_CRITERIA]

Instructions:
1. Convert the priority use cases into 5 to 8 test scenarios the vendor must demonstrate live or through a controlled proof task.
2. For each scenario, define the business context, the vendor task, the input data or conditions, the expected output, and the pass/fail criteria.
3. Make each scenario a stress test. Include realistic friction such as messy data, edge cases, latency, and error handling.
4. Include at least one edge-case scenario and at least one scenario that tests workflow fit, not just model quality.
5. Add an evaluator note for each scenario describing what the buyer team should watch for during the demonstration.

Output format:
- Start with a 2 sentence summary of what this capability test is designed to prove.
- Then output a table with these columns only: Scenario, Business context, Vendor task, Input or condition, Expected output, Pass/fail criteria, Evaluator note.
- End with a section titled Demo control notes containing 5 bullet points.

Requirements:
- Do tie every scenario to the stated use cases and constraints.
- Do make the scenarios hard to satisfy with feature marketing alone.
- Do use plain English that a non-technical procurement manager can follow.
- Do not invent facts about [VENDOR_NAME].
- Do not produce generic demo requests such as "show us your features".
- Do not exceed 8 scenarios.

Why it works: This prompt moves control of the demo from the vendor to the buyer. Canned demos hide latency, integration gaps, and edge-case failures. Weak-fit vendors become obvious when they must perform against buyer-defined scenarios with explicit pass conditions.

You are a data protection and procurement specialist supporting an AI vendor evaluation for [BUYER_ORGANISATION].

Prepare a vendor-ready data handling question document for [VENDOR_NAME] using these inputs:
- Jurisdiction or regulatory baseline: [JURISDICTION_OR_REGULATORY_BASELINE]
- Data types in scope: [DATA_TYPES_IN_SCOPE]
- Sensitivity level: [SENSITIVITY_LEVEL]
- Deployment model: [DEPLOYMENT_MODEL]
- Non-negotiable requirements: [NON_NEGOTIABLE_DATA_REQUIREMENTS]

Instructions:
1. Tailor the six fixed questions below to the inputs. Keep all six. Do not add or remove questions: the fixed battery is what makes answers comparable across vendors.
2. Sharpen each question with the relevant jurisdiction, data types, and deployment model.
3. Under each question, add one line starting "Why this matters:" written for a procurement, privacy, or legal reviewer.
4. Open with a short preamble addressed to the vendor stating that "in line with industry best practice" is not an acceptable answer to any question, and that responses must use specific contractual language with clause references.
5. Close with response instructions: written response within 5 working days; where an answer requires a custom amendment, state that explicitly; where it reflects standard terms, cite the relevant clause.

The six fixed questions:
1. DATA RESIDENCY: Where will our data physically reside? Provide specific data centre locations or geographic regions. Confirm whether this is contractually guaranteed in your standard terms or requires a custom amendment.
2. TRAINING: Will any of our prompts, outputs, or feedback signals be used to train your models or any third-party models? If yes, describe under what conditions and provide an opt-out mechanism. If no, confirm this is the contractual default.
3. RETENTION: How long is our data retained on your systems by default? Describe the retention controls available to us. Confirm whether retention can be set to zero.
4. DELETION: When we delete data, what is the verifiable deletion process? Provide a written deletion policy. Confirm the timeline from request to verified deletion.
5. ACCESS: Who at your organisation has access to our prompts and outputs? Describe the access controls and audit logs. Confirm whether we can review the access logs.
6. EXIT: When we exit the contract, what data comes with us? Provide a written data portability policy. Confirm the format and timeline for export.

Output format:
- A complete, send-ready document: vendor preamble, six numbered questions each followed by one "Why this matters:" line, and a closing section titled Response instructions containing exactly 3 bullet points.

Requirements:
- Do use direct business English and contract-review language.
- Do keep each question under 90 words.
- Do not provide legal advice or cite laws and regulations not included in the inputs.
- Do not invent vendor commitments, contract clauses, or current practices.
- Do not soften any question into a general assurance.

Why it works: The answers become a written record. Vendors who answer evasively at this stage tend to answer evasively throughout the relationship. Use the document on a vendor call where possible, rather than via a marketing-team email response, to force direct answers while you still have leverage.

You are an enterprise integration architect supporting an AI vendor evaluation for [BUYER_ORGANISATION].

Assess the likely integration fit of [VENDOR_NAME] against the buyer's environment and produce a structured evaluation checklist, using these inputs:
- Current stack: [CURRENT_STACK]
- Identity and access requirements: [IDENTITY_AND_ACCESS_REQUIREMENTS]
- Systems and data sources to connect: [SYSTEMS_TO_CONNECT]
- Required workflows: [REQUIRED_WORKFLOWS]
- Hosting or network constraints: [HOSTING_NETWORK_CONSTRAINTS]
- Must-have integrations: [MUST_HAVE_INTEGRATIONS]
- Internal development capacity: [DEV_TEAM_CAPACITY]

Instructions:
1. Identify the integration layers relevant to this environment: authentication, data ingress, data egress, workflow orchestration, admin controls, and monitoring.
2. For each required system or workflow, state what evidence the vendor should provide, such as documented API references, named pre-built connectors, or third-party middleware listings.
3. Classify each claimed fit using the labels Native, API, Middleware, or Unclear.
4. Create a 1 to 5 scoring rubric the buyer can apply consistently across vendors, covering API robustness, connector coverage, data synchronisation, and error handling.
5. Add an implementation risk note wherever an integration appears operationally fragile.

Output format:
- Start with a 2 sentence summary.
- Then output a table with these columns only: Integration area, Buyer requirement, Evidence required, Fit type, Evaluation question, Risk note, Score guidance.
- End with a section titled Red flags to verify containing 5 bullet points.

Requirements:
- Do map every row to the buyer's stated stack and workflows.
- Do separate documented capability from assumption.
- Do explain technical risk in plain English for non-technical stakeholders.
- Do not claim that [VENDOR_NAME] has a connector unless that fact was supplied in the inputs.
- Do not accept generic "we support API integration" claims as evidence.
- Do not produce generic architecture commentary.

Why it works: Integration is where enterprise software projects stall. "We have an API" covers everything from a documented, versioned, secured interface to a single undocumented endpoint. This prompt forces that difference into evidence before contract, not after deployment.

You are an IT financial analyst supporting an AI vendor evaluation for [BUYER_ORGANISATION].

Build a total cost model for [VENDOR_NAME] over [TIME_HORIZON_MONTHS] months (default 24), using these inputs:
- Licence pricing assumptions: [LICENCE_PRICING_ASSUMPTIONS]
- Expected users or seats: [EXPECTED_USERS_OR_SEATS]
- Expected usage volume: [EXPECTED_USAGE_VOLUME]
- Implementation assumptions: [IMPLEMENTATION_ASSUMPTIONS]
- Training assumptions: [TRAINING_ASSUMPTIONS]
- Governance or compliance overhead: [GOVERNANCE_OVERHEAD_ASSUMPTIONS]
- Internal resource costs: [INTERNAL_RESOURCE_ASSUMPTIONS]
- Exit or migration assumptions: [EXIT_OR_MIGRATION_ASSUMPTIONS]

Instructions:
1. Separate one-off costs from recurring costs.
2. Include licence, implementation, onboarding, training, governance, internal resourcing, vendor support, and exit or switching costs.
3. Where an input is missing, mark the value Unknown and state the assumption needed to fill it. Never estimate a price that was not supplied.
4. Provide a low, base, and high scenario where the inputs are uncertain.
5. Define every calculation explicitly so the model can be rebuilt in a spreadsheet.
6. Close with the main cost drivers and where they create negotiation leverage.

Output format:
- Start with a one-paragraph summary.
- Then output a table with these columns only: Cost category, One-off, Monthly recurring, Annual recurring, Total over horizon, Calculation, Assumption note.
- After the table, add a section titled Scenario view with up to 3 bullet points.
- End with a section titled Cost driver notes containing exactly 4 bullet points.

Requirements:
- Do keep the arithmetic transparent and replicable.
- Do distinguish assumptions from known values in every row.
- Do include internal labour and governance costs, not just vendor fees.
- Do not invent price points that were not supplied.
- Do not mix one-off and recurring costs in a single figure without labelling.
- Do not use financial jargon without a plain-English explanation.

Why it works: The licence fee is usually a minority of the true cost of running enterprise software. Cheap vendors become expensive once implementation effort, governance overhead, and switching costs are counted. The completed model doubles as negotiation leverage: a vendor that is expensive to implement can be asked to discount Year 1 or include professional services.

You are a vendor risk and compliance analyst supporting an AI vendor evaluation for [BUYER_ORGANISATION].

Create a structured risk profile framework for [VENDOR_NAME] using these inputs:
- Buyer risk priorities: [BUYER_RISK_PRIORITIES]
- Regulatory environment: [REGULATORY_ENVIRONMENT]
- Criticality of deployment: [DEPLOYMENT_CRITICALITY]
- Data sensitivity: [DATA_SENSITIVITY]
- Contract dependency concerns: [CONTRACT_DEPENDENCY_CONCERNS]
- Financial or continuity concerns: [FINANCIAL_CONTINUITY_CONCERNS]
- Vendor evidence already provided: [KNOWN_VENDOR_EVIDENCE]

Instructions:
1. Build a risk framework covering financial stability, regulatory posture, security posture, operational resilience, contractual lock-in, and exit viability.
2. For each area, define the evidence the buyer should request, such as third-party audit reports, certifications, SLA terms with penalties, business continuity plans, or escrow arrangements.
3. Provide a 1 to 5 scoring scale with plain-English anchors at 1, 3, and 5.
4. Label the evidence status for each area as Provided, Partial, Missing, or Unverified, based only on the supplied inputs.
5. End with the top risks that would justify escalation or disqualification.

Output format:
- Start with a 2 sentence summary.
- Then output a table with these columns only: Risk area, Why it matters, Evidence to request, Score 1 anchor, Score 3 anchor, Score 5 anchor, Current evidence status.
- End with a section titled Escalation triggers containing 5 bullet points.

Requirements:
- Do keep the scoring anchors concrete and tied to operational impact.
- Do distinguish low evidence from low risk.
- Do require verifiable proof, not "we are compliant" statements.
- Do not assign a definitive score to any area without supplied supporting evidence.
- Do not provide legal conclusions.
- Do not use vague labels such as "good" or "bad" without explanation.

Why it works: A vendor's risk is your risk. If a critical vendor fails financially, suffers a breach, or has prolonged downtime, the consequences land on you. This framework keeps risk review proportionate and evidence-based, and stops teams treating vendor confidence as proof.

You are an implementation project lead supporting an AI vendor evaluation for [BUYER_ORGANISATION].

Estimate the likely time from contract signature to a working pilot for [VENDOR_NAME], using these inputs:
- Deployment scope: [DEPLOYMENT_SCOPE]
- Target go-live date: [TARGET_GO_LIVE_DATE]
- Technical prerequisites: [TECHNICAL_PREREQUISITES]
- Security or procurement gates: [SECURITY_OR_PROCUREMENT_GATES]
- Buyer-side dependencies: [BUYER_SIDE_DEPENDENCIES]
- Vendor onboarding claims: [VENDOR_ONBOARDING_CLAIMS]
- Required integrations: [REQUIRED_INTEGRATIONS]
- Pilot success conditions: [PILOT_SUCCESS_CONDITIONS]

Instructions:
1. Break the path from contract to working pilot into clear phases.
2. Estimate duration by phase using only the supplied information and stated assumptions.
3. Separate vendor-controlled tasks from buyer-controlled tasks.
4. Identify the critical path, gating dependencies, and the points where slippage is most likely.
5. Provide best case, base case, and delayed case estimates per phase.
6. Define 3 velocity metrics the buyer should track during the first 14 days of the pilot.

Output format:
- Start with a short summary paragraph.
- Then output a table with these columns only: Phase, Owner, What happens, Dependency, Best case, Base case, Delayed case, Risk note.
- End with a section titled Timeline pressure points containing exactly 5 bullet points.

Requirements:
- Do show where each estimate depends on assumptions rather than evidence.
- Do treat vendor onboarding claims as claims to verify, not facts.
- Do account for security review, procurement steps, and integration readiness.
- Do not promise delivery dates.
- Do not assume buyer-side dependencies resolve instantly.
- Do not compress the timeline to match [TARGET_GO_LIVE_DATE] without flagging the compression as a risk.

Why it works: Time to value decides whether a deployment keeps its sponsors. This prompt turns onboarding promises into an operational timeline and shows whether slow progress is likely to come from the vendor, your own dependencies, or both. That distinction matters when the pilot slips and someone asks why.

You are a procurement decision analyst supporting an AI vendor evaluation for [BUYER_ORGANISATION].

Create a weighted scoring model for comparing [VENDOR_LIST] using these inputs:
- Evaluation dimensions: [EVALUATION_DIMENSIONS] (default to the six pack axes: capability fit, data handling, integration, total cost, risk, velocity)
- Proposed weights: [PROPOSED_WEIGHTS]
- Available evidence summary: [AVAILABLE_EVIDENCE_SUMMARY]
- Minimum thresholds or disqualifiers: [MINIMUM_THRESHOLDS_OR_DISQUALIFIERS]
- Scoring scale: [SCORING_SCALE]

Instructions:
1. Build the model using the supplied dimensions and weights. Weights must sum to 100; if they do not, correct them proportionally and state the correction.
2. Define what a high, medium, and low score means for each dimension so different team members score consistently.
3. Attach a confidence note to every vendor score based on the quality of the underlying evidence.
4. Show the weighted total per vendor and flag any threshold failures or disqualifiers.
5. State the scoring formula explicitly so the model can be replicated in a spreadsheet.
6. Add a short sensitivity note: which single weight change would alter the ranking.
7. Close with an interpretation that does not overstate certainty.

Output format:
- Start with a 2 sentence summary.
- Then output a scores table with these columns: Dimension, Weight, then one score column and one confidence column per vendor, then Scoring note. Adapt the vendor columns to the number of vendors supplied.
- Then output a second table with these columns only: Vendor, Weighted total, Threshold status, Interpretation.
- End with a section titled Scoring cautions containing 4 bullet points.

Requirements:
- Do make the weighting and arithmetic fully transparent.
- Do state where a score rests on incomplete evidence.
- Do apply thresholds and disqualifiers before ranking.
- Do not score a vendor on facts that were not supplied.
- Do not hide uncertainty behind a precise-looking number.
- Do not convert the result into a final decision without a written rationale.

Why it works: A weighted scoring model is the defence against the charismatic demo and the lowest sticker price. Agree the weights and scoring definitions before anyone sees the totals. The confidence notes matter because a high score on weak evidence is not the same decision input as a high score on strong evidence.

You are a procurement governance specialist supporting an AI vendor evaluation for [BUYER_ORGANISATION].

Draft a formal decision record for the vendor selection, using these inputs:
- Chosen vendor: [CHOSEN_VENDOR]
- Runner-up vendor: [RUNNER_UP_VENDOR]
- Decision date: [DECISION_DATE]
- Business objective: [BUSINESS_OBJECTIVE]
- Evaluation summary: [EVALUATION_SUMMARY]
- Weighted scoring summary: [WEIGHTED_SCORING_SUMMARY]
- Key risks accepted: [KEY_RISKS_ACCEPTED]
- Key mitigations: [KEY_MITIGATIONS]
- Approval path and stakeholders: [APPROVAL_PATH_OR_STAKEHOLDERS]

Instructions:
1. Draft a concise decision record suitable for the procurement file, internal audit, or steering group review.
2. Explain why the chosen vendor was selected and why the runner-up was not, referencing the evaluation evidence supplied.
3. Record the major trade-offs, the risks accepted, and the mitigations required.
4. State any assumptions or unresolved points that should be revisited at contract or pilot stage.
5. Keep the tone factual and defensible. Document the downsides of the chosen vendor as clearly as the benefits.

Output format:
- Start with a section titled Decision summary of no more than 120 words.
- Then output sections titled exactly: Business objective, Chosen vendor, Runner-up, Trade-offs, Accepted risks, Mitigations, Open points, Approval record.
- Under Trade-offs, use 4 bullet points. Under Accepted risks, use 3 bullet points. Under Mitigations, use 3 bullet points.

Requirements:
- Do write as a formal internal record in plain English.
- Do connect the decision to evidence and the business objective.
- Do record uncertainty where it remains.
- Do not use marketing language or promotional framing.
- Do not claim certainty beyond the available evidence.
- Do not omit the runner-up or the reasons they were not selected.

Why it works: The decision record is the evaluation team's insurance policy. When an implementation is questioned two years from now, the first question is "why did we buy this?" This document answers with evidence rather than memory, and it protects the people who ran the process properly.