---
name: vendor-evaluator
description: Runs a structured, weighted vendor or product selection scorecard with transparent scoring, pros/cons, and a recommendation memo for the decision-maker.
version: 1.0.0
author: VantagePoint Networks
audience: IT Managers, Procurement Leads, Infrastructure Directors, CTOs
output_format: Formatted Markdown evaluation pack with requirements matrix, weighted scorecard, per-vendor analysis, and board-ready recommendation memo.
license: MIT
---

# Vendor Evaluator

A structured walkthrough that converts "we need a new firewall" into a defensible, auditable, board-presentable selection decision.

## How to use this skill

1. Download this `SKILL.md` file.
2. Place it in `~/.claude/commands/` (macOS/Linux) or `%USERPROFILE%\.claude\commands\` (Windows).
3. Run `/vendor-evaluator` in Claude Code. Tell it what you're buying and why. Answer the scoping questions. Feed it the vendor information you have (datasheets, proposals, demo notes). Receive the evaluation pack.

## When to use this

- You have three shortlisted vendors and need to choose one without it becoming "whoever the CTO golfs with".
- You have to justify a 6-figure spend to finance or the board and need a defensible paper trail.
- You're preparing an RFP response framework - the weighted criteria become the RFP scoring sheet.
- You're reviewing a renewal and want to check whether incumbent is still the right choice or just the easy choice.
- You're running a POC and want objective success criteria defined before testing starts (not after).

## What you'll get

- **Requirements register** - functional, non-functional, commercial, strategic - with weights.
- **Weighted scorecard** per vendor, with scores broken down by category.
- **Per-vendor analysis** - strengths, weaknesses, deal-breakers, risks.
- **Commercial summary** - 3-year TCO comparison with assumptions documented.
- **Risk matrix** - vendor risk, technical risk, implementation risk.
- **Gap analysis** against the incumbent (if there is one).
- **Recommendation memo** for the decision-maker - 1 page, executive-readable, with explicit reasoning.
- **Appendix** - the raw scoring sheet and any disqualifying evidence.

## Clarifying questions I will ask you

1. **What are you buying, in a single product category?** (Next-gen firewall, wireless platform, SIEM, MDM, RMM, endpoint backup)
2. **Why now?** (End of life, incident, growth, compliance, cost pressure, strategy refresh)
3. **Who are the candidates?** (List the vendors/products you want scored.)
4. **Who is making the decision?** (CTO, IT Director, Procurement, Board, joint)
5. **What's the budget envelope?** (Upper bound, 3-year TCO, one-off + recurring split)
6. **What's the timeline?** (Must-live-by date, when the contract must be signed, any renewal trigger)
7. **What's the incumbent, if any, and why are you considering replacing?**
8. **What are your must-haves?** (Things that, if missing, disqualify the vendor regardless of price)
9. **What are your nice-to-haves?** (Will tip the balance but not decide)
10. **Non-functional must-haves:** (UK data residency, FedRAMP, SOC 2 Type 2, specific integrations)
11. **Who uses this daily?** (L1 agents, senior engineers, end users) - usability weight depends on this.
12. **Is there a reference customer you want to talk to?**

## Output template

```markdown
# Vendor Evaluation: <category> - <decision date>

**Evaluation owner:** <name / role>
**Decision-maker:** <name / role>
**Decision deadline:** YYYY-MM-DD
**Budget envelope:** <figure> over <period>
**Incumbent (if any):** <name>

## 1. Executive Summary
> <Two paragraphs: (a) why we ran this evaluation, (b) the recommendation and its rationale in one line. Should stand alone for an executive who won't read past section 2.>

## 2. Recommendation
> **Selected vendor:** <name>
> **Key reason:** <one sentence>
> **Total 3-year cost:** <figure>
> **Next step:** <negotiate MSA / issue PO / formal POC>

| Criterion | Result |
|---|---|
| Met all must-haves | Yes / No |
| Fit within budget | Yes / +N% / -N% |
| Timeline achievable | Yes / At risk / No |
| Reference check done | Yes / No / In progress |

## 3. Requirements Register
Weights sum to 100. "Must" criteria act as gates - failing any of them disqualifies the vendor regardless of total score.

| # | Requirement | Category | Type | Weight |
|---|---|---|---|---|
| F01 | <functional must-have> | Functional | Must | 0 (gate) |
| F02 | <functional requirement> | Functional | Scored | 12 |
| F03 | <...> | Functional | Scored | 10 |
| N01 | <non-functional, e.g. UK data residency> | Non-functional | Must | 0 (gate) |
| N02 | <e.g. SOC 2 Type 2> | Non-functional | Scored | 8 |
| C01 | Fit within 3-year budget | Commercial | Must | 0 (gate) |
| C02 | 3-year TCO | Commercial | Scored | 15 |
| C03 | Lock-in / portability | Commercial | Scored | 6 |
| S01 | Strategic alignment | Strategic | Scored | 10 |
| S02 | Vendor viability | Strategic | Scored | 8 |
| U01 | Operator day-to-day usability | Usability | Scored | 10 |
| I01 | Integration with existing stack | Integration | Scored | 11 |
| R01 | Implementation risk | Risk | Scored | 10 |

## 4. Vendor Comparison at a Glance
| Criterion (weight) | Vendor A | Vendor B | Vendor C | Incumbent |
|---|---|---|---|---|
| F02 (12) | 4/5 = 48 | 5/5 = 60 | 3/5 = 36 | 3/5 = 36 |
| F03 (10) | 3/5 = 30 | 4/5 = 40 | 5/5 = 50 | 2/5 = 20 |
| <...> | | | | |
| **Weighted total** | **N** | **N** | **N** | **N** |
| Must-haves passed | Y/N | Y/N | Y/N | Y/N |

## 5. Per-Vendor Analysis

### Vendor A
**One-line summary:** <characterise vendor in a sentence>

**Strengths**
- <specific, evidence-backed>
- <specific, evidence-backed>

**Weaknesses**
- <specific, evidence-backed>
- <specific, evidence-backed>

**Deal-breakers (if any):** <none | explicit gate failures>

**Commercial**
| Element | 3-year cost |
|---|---|
| Hardware / licences (one-off) | |
| Subscription / support (annual x 3) | |
| Professional services (implementation) | |
| Training | |
| **Total 3-year TCO** | |

**Risks**
- <risk>: mitigated by <control>
- <risk>: mitigated by <control>

**Reference customers contacted:** <names + tenure>
**Reference check verdict:** <positive / mixed / negative / not yet done>

### Vendor B
<same structure>

### Vendor C
<same structure>

### Incumbent (if applicable)
<same structure - include honest view of why replacement is being considered>

## 6. 3-Year TCO Comparison
All figures in <currency>, excluding VAT. Assumes <key assumptions e.g. 250 users, 10% annual growth>.

| Line item | Vendor A | Vendor B | Vendor C | Incumbent |
|---|---|---|---|---|
| Year 1 (incl. setup) | | | | |
| Year 2 | | | | |
| Year 3 | | | | |
| **3-year total** | | | | |
| Cost per user per year | | | | |

**TCO assumptions (must be reviewed):**
- <assumption 1>
- <assumption 2>

## 7. Risk Matrix
| Risk | Vendor A | Vendor B | Vendor C | Rationale |
|---|---|---|---|---|
| Vendor viability (financial, M&A) | L/M/H | L/M/H | L/M/H | <> |
| Technical maturity | L/M/H | L/M/H | L/M/H | <> |
| Migration / implementation | L/M/H | L/M/H | L/M/H | <> |
| Operational complexity | L/M/H | L/M/H | L/M/H | <> |
| Lock-in / switching cost | L/M/H | L/M/H | L/M/H | <> |

## 8. Gap Analysis vs Incumbent (if applicable)
| Area | Incumbent today | Selected vendor | Delta |
|---|---|---|---|
| <area> | <> | <> | +/- |

## 9. Recommendation Memo (for the decision-maker)

**To:** <decision-maker name + role>
**From:** <evaluation owner>
**Date:** YYYY-MM-DD
**Re:** <category> selection

After a structured evaluation of <N> vendors against <N> weighted criteria, our recommendation is **<vendor>**.

**Why this vendor wins:**
- <1-2 concrete evidence-based reasons>
- <1-2 concrete evidence-based reasons>

**What we accept by choosing them:**
- <honest statement of the weaker areas - shows rigour>

**What changes if we pick them:**
- <impact on operations, support model, cost trajectory>

**If we do nothing / keep incumbent:**
- <what we lose and what it costs us>

**Next steps:**
1. Commercial negotiation - target save: <%>, extended terms: <features>.
2. Reference checks still outstanding: <list>.
3. Proof of concept (POC) success criteria: <3 bullets, measurable>.
4. Contract review by Legal - key clauses: <data residency, exit, IP>.
5. Kickoff date target: YYYY-MM-DD.

---

## 10. Appendix: Evidence Log
What each score is based on. An auditor or a challenger should be able to trace any score back to a source.

| Criterion | Vendor | Score | Evidence source (URL / document / demo date / email) |
|---|---|---|---|
| F02 | Vendor A | 4 | Demo 2026-03-15, slide 18 of capabilities deck |
| F02 | Vendor B | 5 | Documented in admin guide v3.4 section 7 |
| <...> | | | |
```

## Example invocation

**User:** "/vendor-evaluator - we're picking a new SIEM. Candidates are Sentinel, Splunk, and Elastic. Budget 120k over 3 years. We're moving away from LogRhythm because support is poor and we need UK data residency. About 500 EPS average, spike to 2000."

**What the skill will do:**
1. Ask about must-haves (UK residency, specific integrations like M365, Entra ID, on-prem firewalls), scoring weights, who operates it daily (in-house SOC or MSSP?), and whether MDR is bundled or separate.
2. Build the requirements register with EPS / data volume as a scored criterion and UK residency + specific log source integrations as gates.
3. Score each vendor against the register using whatever datasheets / proposals you pasted, flagging where the score is from vendor marketing vs independent verification.
4. Produce a TCO table that specifically calls out ingest-based vs entity-based pricing differences and the impact of the 2000 EPS spike.
5. Generate the recommendation memo with explicit "what we accept" and "if we do nothing" sections.

## Notes for the requester

- **Must-haves are gates, not heavy-weighted items.** If UK data residency is non-negotiable, set it as a must. A vendor without it is disqualified regardless of being cheapest or fastest.
- **Feed real evidence, not reputation.** "Splunk is the enterprise choice" doesn't score a point. "Splunk supports our specific SAP ingest per their docs section 4.2" does.
- **Be honest about the incumbent.** If they're the safe choice, score them that way. Don't rig the evaluation to reach a pre-decided answer - it destroys the value of the process.
- **POC success criteria must be written before POC starts.** The skill will include a placeholder in the memo - fill it in and agree with stakeholders before kicking off, otherwise the POC outcome will be whatever the loudest voice says it is.
- **"Good" looks like:** your CFO reads the memo in 3 minutes and greenlights the spend. An unsuccessful vendor can read the pack, agree with the reasoning, and leave with their dignity.