Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Vendor lifecycle — weighted selection scorecards, risk tiering, renewal and notice-deadline tracking, spend concentration, and SLA credits. Use when selecting a vendor, preparing a renewal, or reviewing a vendor portfolio.
.claude/skills/borghei-vendor-management/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-05 | ✗→✓ | ▲ Improved | 215% | 0% |
| case-07 | ✗→✓ | ▲ Improved | 163% | 0% |
| case-08 | ✗→✓ | ▲ Improved | 166% | 0% |
| case-09 | ✗→✓ | ▲ Improved | 191% | 0% |
| case-12 | ✗→✓ | ▲ Improved | 192% | 0% |
Covers the vendor lifecycle from selection to exit. Two failures dominate this discipline: tiering vendors by spend rather than by blast radius, and losing every point of renewal leverage to a missed notice deadline. This skill is built around preventing both.
Before generating, confirm these inputs. If any is unknown or vague, ASK — do not assume:
Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.
bashpython3 business-operations/vendor-management/scripts/vendor_scorecard.py \ --input business-operations/vendor-management/assets/sample_vendor_candidates.json \ --format text
as_of explicitly so the analysis is reproducible and reviewable later.bashpython3 business-operations/vendor-management/scripts/portfolio_analyzer.py \ --input business-operations/vendor-management/assets/sample_portfolio.json \ --format text
bashpython3 business-operations/vendor-management/scripts/sla_report.py \ --input business-operations/vendor-management/assets/sample_sla.json \ --format json
Score data sensitivity plus business criticality, then apply modifiers.
| Data classification | Points | | Business criticality | Points | |--------------------|--------|---|---------------------|--------| | PHI / health | 4 | | Critical (revenue stops in hours) | 4 | | PII | 3 | | High (core function stops in a day) | 3 | | Financial | 3 | | Medium (productivity loss) | 2 | | Confidential | 2 | | Low (inconvenience) | 1 | | Internal | 1 | | | | | Public | 0 | | | |
Modifiers: no ready alternative +2 · network access to your systems +2 · subprocessors +1 · non-adequate jurisdiction +1 · vendor under 20 people +1.
| Total | Tier | Core obligations | |-------|------|------------------| | 8+ | Tier 1 critical | Annual security review, quarterly business review, tested exit plan, SLA with credits | | 6-7 | Tier 2 high | Full questionnaire at onboarding, semi-annual review, documented exit plan | | 4-5 | Tier 3 moderate | Short-form questionnaire, annual review, verified data export | | Under 4 | Tier 4 low | Confirm what data it touches; nothing further |
Tier by blast radius, not spend. The $8K tool holding your entire customer list outranks the $400K hosting contract holding nothing sensitive.
| Source | Worth | Requires | |--------|-------|----------| | A real alternative | 10-30% | 3-6 weeks of genuine evaluation, an internal sponsor willing to switch | | Vendor fiscal timing | 10-25% | Knowing their year-end and aligning your close to it | | Multi-year commitment | 10-20% | Price protection, exit-on-SLA-failure, and an increase cap — all three | | Volume / consolidation | 15-30% | Real growth, not aspirational seat counts | | Reference or case study | 5-15% | Marketing time, not money | | Annual prepay | 5-10% | Cash-flow float, and a viability check first |
Not leverage: complaining about price, threatening to leave without an alternative, escalating without a specific ask, or loyalty — long tenure lowers vendor risk, which is why tenured accounts are often priced higher.
| Days before renewal | Action | |--------------------|--------| | 180 | Usage vs entitlement; confirm owner; decide renew / renegotiate / exit | | 150 | Open the alternative evaluation if renegotiating seriously | | 120 | First vendor conversation — signal expectations before they build the quote | | 90 | Notice deadline on most annual contracts. Serve notice if there is any doubt. | | 60 | Negotiate substance: price, increase cap, true-down, SLA credits, exit rights | | 30 | Close; anything open now resolves in the vendor's favour |
Serving notice is not leaving — it converts an auto-renewal into a negotiation.
| Term | Target | |------|--------| | Annual increase cap | CPI, or 3-5% maximum | | Seat true-down rights | At renewal, without penalty | | Termination for SLA failure | Defined breach threshold, no penalty | | Data export format | Open, documented, and tested | | Subprocessor change notice | 30 days with an objection right | | Assignment on acquisition | Consent required, or an exit right |
Seat true-down is the most valuable and least-requested term: nearly every SaaS contract lets you add seats mid-term and forbids reducing them.
Mistake: Applying diligence proportional to contract value — heavy scrutiny on the big infrastructure contract, a credit card and no questions for the $8,000 tool. Why it happens: Procurement owns the process and procurement thresholds are denominated in money. Approval workflows trigger on spend because that is what finance systems can see. Instead: Tier on data sensitivity and business criticality, with modifiers for substitutability and subprocessors. The small tool holding your customer list has a far larger blast radius than the large contract holding nothing sensitive, and it is exactly the one that gets bought on a card without a security review.
Mistake: Tracking renewal dates only, then finding at day 60 that the 90-day notice window closed a month ago and the contract has auto-renewed for another year. Why it happens: Renewal dates are what contracts and calendars display. The notice deadline is a derived date nobody computes, and auto-renew clauses are written to be easy to miss. Instead: Track both dates per contract, and treat the notice deadline as the real one. Serve notice at the deadline as routine on anything you intend to renegotiate — it reopens the contract without committing you to leave. An unowned contract is the one this happens to, so assign an internal owner to every vendor.
Mistake: Choosing the vendor, then building a weighted scorecard whose weights and scores produce that vendor as the winner. Why it happens: Rarely cynical. Someone forms a view during the demos, and weights get set afterwards with that view in the room — each individual weight feels defensible while the set of them is not. Instead: Set and record the weights, with named anchors for what a 10 and a 5 look like, before any candidate is scored. Then run the sensitivity check: if the winner changes when one weight moves 50%, the result is an artifact of the weighting rather than a finding about the vendors, and the decision owner needs to see that before signing.
Mistake: Accepting a 99.9% uptime commitment with a 2% service credit and considering the risk managed. Why it happens: The SLA exists, it has numbers in it, and it satisfies the checklist item. Nobody computes what the credit is actually worth against what an outage costs. Instead: Price the remedy. A 2% credit on a $20K quarter is $400 for an outage that may cost you far more — that is a rounding error the vendor has already priced in, not a control. Negotiate tiered credits (5/10/25%), a cap above 20% of period fees, and a termination right after repeated breach. Losing the account changes vendor behaviour; credits do not. And measure availability against the error budget, not the percentage — missing 99.9% by half a point is nearly six times the permitted downtime.
| File | Purpose | |------|---------| | scripts/vendor_scorecard.py | Must-have gating, weighted scoring, cost-value ratio, and a weight-sensitivity check on the result | | scripts/portfolio_analyzer.py | Renewal and notice-deadline tracking, derived risk tiers, HHI spend concentration, consolidation candidates | | scripts/sla_report.py | SLA compliance with error-budget severity, credit tiers against the contractual cap, and multi-period trend | | references/vendor-risk-tiering.md | Tiering model, per-tier obligations, onboarding diligence, concentration risk, monitoring signals, vendor distress indicators | | references/renewal-negotiation-leverage.md | Renewal calendar, ranked leverage sources, terms beyond price, making SLAs bite, negotiation sequence, exit execution | | assets/vendor-selection-scorecard.md | Selection deliverable: must-haves, weighted criteria with anchors, stability check, risk tier, commercial position | | assets/vendor-review-template.md | Business review: SLA performance, usage vs entitlement, risk checks, renewal plan with milestone dates | | assets/sample_vendor_candidates.json | Four candidates including one disqualified on a must-have and a near-tie between the top two | | assets/sample_portfolio.json | Ten-vendor portfolio with a locked auto-renewal, an unowned contract, and a consolidation candidate | | assets/sample_sla.json | Five metrics in both directions with credit tiers, a capped credit total, and a degrading trend |
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→fail | 27,893 | 22,585 | -19% | 1 | 1 | 0% | 4,253 | 6,496 | +53% | 0 | 0 | — |
case-02 | fail→fail | 41,162 | 36,847 | -10% | 1 | 1 | 0% | 2,205 | 9,225 | +318% | 0 | 0 | — |
case-03 | fail→fail | 24,566 | 8,174 | -67% | 1 | 1 | 0% | 4,034 | 3,338 | -17% | 0 | 0 | — |
case-04 | pass→pass | 12,787 | 9,653 | -25% | 1 | 1 | 0% | 1,940 | 4,391 | +126% | 0 | 0 | — |
case-05 | fail→pass | 10,574 | 15,116 | +43% | 1 | 1 | 0% | 1,711 | 5,388 | +215% | 0 | 0 | — |
case-06 | pass→pass | 13,923 | 13,651 | -2% | 1 | 1 | 0% | 1,988 | 4,809 | +142% | 0 | 0 | — |
case-07 | fail→pass | 12,312 | 13,059 | +6% | 1 | 1 | 0% | 1,884 | 4,962 | +163% | 0 | 0 | — |
case-08 | fail→pass | 10,928 | 6,260 | -43% | 1 | 1 | 0% | 1,466 | 3,894 | +166% | 0 | 0 | — |
case-09 | fail→pass | 11,338 | 12,786 | +13% | 1 | 1 | 0% | 1,647 | 4,798 | +191% | 0 | 0 | — |
case-10 | pass→pass | 11,041 | 13,072 | +18% | 1 | 1 | 0% | 1,606 | 4,775 | +197% | 0 | 0 | — |
case-11 | pass→pass | 8,731 | 11,509 | +32% | 1 | 1 | 0% | 1,317 | 4,510 | +242% | 0 | 0 | — |
case-12 | fail→pass | 11,645 | 13,120 | +13% | 1 | 1 | 0% | 1,615 | 4,721 | +192% | 0 | 0 | — |
case-13 | pass→pass | 9,461 | 16,428 | +74% | 1 | 1 | 0% | 1,362 | 5,315 | +290% | 0 | 0 | — |
case-14 | pass→pass | 9,077 | 9,820 | +8% | 1 | 1 | 0% | 1,486 | 4,660 | +214% | 0 | 0 | — |
case-15 | fail→pass | 13,452 | 13,826 | +3% | 1 | 1 | 0% | 1,986 | 5,183 | +161% | 0 | 0 | — |
case-16 | pass→pass | 9,104 | 10,180 | +12% | 1 | 1 | 0% | 1,317 | 4,375 | +232% | 0 | 0 | — |
case-17 | fail→pass | 9,703 | 6,732 | -31% | 1 | 1 | 0% | 1,552 | 4,046 | +161% | 0 | 0 | — |
case-18 | pass→pass | 17,305 | 18,889 | +9% | 1 | 1 | 0% | 2,474 | 5,615 | +127% | 0 | 0 | — |
case-19 | fail→pass | 4,826 | 3,209 | -34% | 1 | 1 | 0% | 704 | 3,398 | +383% | 0 | 0 | — |
case-20 | fail→pass | 3,656 | 3,019 | -17% | 1 | 1 | 0% | 538 | 3,430 | +538% | 0 | 0 | — |
case-21 | fail→pass | 4,052 | 3,159 | -22% | 1 | 1 | 0% | 539 | 3,414 | +533% | 0 | 0 | — |
case-22 | pass→pass | 15,800 | 30,421 | +93% | 1 | 1 | 0% | 2,899 | 7,419 | +156% | 0 | 0 | — |
case-23 | pass→pass | 14,289 | 19,172 | +34% | 1 | 1 | 0% | 2,767 | 6,092 | +120% | 0 | 0 | — |
case-24 | pass→pass | 12,469 | 15,725 | +26% | 1 | 1 | 0% | 2,374 | 5,845 | +146% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 24 cases were attempted, and 22 counted toward the lift figure. The other 2 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +42 percentage points is the difference between those two pass rates over the 22 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.