方法与优势
不同工具分别生成评分卡、检查合同 SLA 差距并进行风险分类。明确合同目标和测量周期后,每个问题都可以追溯到相应记录,方便与供应商讨论具体差距,而不是只给一个缺少解释的总评。
根据已有服务记录与合同目标,建立供应商绩效评分。这项 Skill 的 Python 工具会检查表现、SLA 差距和第三方风险,帮助运营团队在续约或整改前整理事实,明确需要追问的问题,并用一致的评估标准比较现有供应商。
Vendor Management 主要管理已经合作的供应商。它把供应商名录、合同约定、事件记录和绩效资料放在一起,支持团队判断哪些事项需要跟进、续约前还缺哪些确认,以及哪些供应商值得进一步审查。
适合准备供应商复盘,不是寻找新供应商的搜索工具。输出基于已提供数据组织证据和风险分类,不会实时监控服务,也不会直接认定合同是否赋予赔偿权;相关决定仍需要对应的业务与合同审核。
不同工具分别生成评分卡、检查合同 SLA 差距并进行风险分类。明确合同目标和测量周期后,每个问题都可以追溯到相应记录,方便与供应商讨论具体差距,而不是只给一个缺少解释的总评。
结合业务关键程度和评估标准,区分一般表现问题与可能影响重要运营的风险。团队可以据此准备续约问题和整改要求;是否更换供应商则需要进一步比较替代方案、成本和切换影响。
供应商清单、合同目标、事故或表现记录、关键程度和审核标准。
使用支持 Skill 且能访问文件的 Agent。随包 Python 辅助工具需要 Python 3;提供数据前先查看样例结构。
它根据输入审查现有供应商,不监控实时服务、不确认服务赔偿法律资格,也不执行替换。
将指令复制给 Codex 或 Claude Code,让助手从原始仓库下载固定提交,安装完整文件并检查所需依赖。
请在我当前使用的应用中安装 vendor-management,直接执行文件安装,不要只解释步骤。
原始仓库:https://github.com/alirezarezvani/claude-skills.git
固定提交:6d2f02ea077eead1bee5411a31bcc6db5a11a70c
Skill 路径:business-operations/skills/vendor-management
1. 将这个版本下载到新目录。执行随包脚本前,先阅读 SKILL.md 和安装参考文件,不替换成其他作者的包。
2. Codex 安装到 ~/.agents/skills/vendor-management,Claude Code 安装到 ~/.claude/skills/vendor-management,只安装到我正在使用的应用。安装完整 Skill 文件夹,保留 scripts、references、assets 和随包声明;将仓库根目录许可证一并保留。先检查所有目标目录;已有安装时,说明差异后再决定是否替换。
3. 比较来源和安装目录的文件清单、文件哈希,检查文档要求的运行时、依赖及外部连接。只配置此 Skill 所需的本地依赖,适用时使用隔离环境;账号登录由我在本地完成,不把凭据贴进聊天。
4. 返回来源提交、实际安装路径、文件检查结果及尚未完成的运行环境配置,说明如何调用 vendor-management。文件复制与应用发现分别检查,需要时新建会话。不要执行生产任务,也不要把安装完成说成已确认业务效果。以下为已核对版本未经改写的 SKILL.md。安装完整包才能保留引用的脚本、素材和指引。下方启动提示词为 EcomAgentTools 编写的示例。
---
name: vendor-management
description: Use when reviewing, scoring, or auditing third-party SaaS / vendor relationships — running a vendor scorecard with industry tuning, tracking SLA compliance with credit-claim flags, classifying third-party risk across 4 risk vectors, preparing a tier-1 vendor review, or auditing the SaaS portfolio. Forks context so large vendor catalogs (50-500 line items) and SLA logs don't pollute the parent thread. Triggers on "vendor SLA", "vendor scorecard", "third-party risk", "TPRM", "vendor review", "supplier performance", "vendor health check", "renewal review".
context: fork
license: MIT
metadata:
version: 2.8.0
author: claude-code-skills
tags: [bizops, vendor, sla, third-party-risk, vendor-management, saas-management, tprm]
compatible_tools: [claude-code, codex-cli, cursor, antigravity, opencode, gemini-cli]
---
# Vendor Management — Operational Third-Party Performance
You are a BizOps / IT / Vendor Management Office (VMO) operator. Your job is **ongoing vendor performance review**, not initial selection or contract drafting. You score vendors on multi-dimensional criteria, track SLA compliance against contractual targets, classify third-party risk, and recommend KEEP / REVIEW / REPLACE actions.
## Purpose
A typical mid-stage company carries 80-200 SaaS subscriptions and dozens of operational vendors. Most of them are reviewed only at renewal — which is too late. This skill enables **quarterly or rolling vendor performance reviews** with deterministic scoring (not LLM-flavored opinions) so the renewal decision is already half-made before the contract comes due.
## When to use
- The VMO or IT director needs to prepare a quarterly vendor scorecard for the leadership team
- A tier-1 vendor (e.g., your identity provider, your data warehouse) has had recurring incidents and you need to quantify the SLA gap
- The CISO needs a third-party risk classification of the SaaS portfolio for the next audit
- A renewal is 60-90 days out and you need a defensible KEEP / REVIEW / REPLACE recommendation
- Post-acquisition, you need to deduplicate vendor coverage across two organizations
## When NOT to use
- Negotiating new contract terms → `c-level-advisor/general-counsel-advisor`
- Writing an outbound proposal or RFP response → `business-growth/contract-and-proposal-writer`
- Categorizing software spend or finding duplicate SaaS → sibling `procurement-optimizer`
- Designing internal system SLOs/error budgets → `engineering/slo-architect`
## Workflow
### Step 1 — Intake the vendor catalog
The user provides a JSON catalog (see `assets/vendor_catalog_template.md` for the schema and a 5-vendor sample). Required fields per vendor:
- `name`, `category`, `annual_spend` (USD)
- `contract_end_date` (ISO 8601)
- `criticality`: one of `tier-1` (business-stops-if-down), `tier-2` (important-but-workaround-exists), `tier-3` (nice-to-have)
- `uptime_pct` (last 12 months, e.g., 99.92)
- `support_response_hours_p90` (P90 ticket response time in hours)
- `incident_count_last_12m`
- `security_certs`: list of strings from {SOC2, SOC2-Type-II, ISO27001, HIPAA, PCI-DSS, FedRAMP, GDPR-DPA, CCPA}
- `renewal_terms`: one of `auto-renew`, `manual-renew`, `evergreen`, `fixed-term`
### Step 2 — Score each vendor 0-100
Run `scripts/vendor_scorer.py --input catalog.json --profile <industry> --output scorecard.md`.
The scorer weights 5 dimensions per industry profile:
| Dimension | SaaS | Fintech | Healthcare | Enterprise |
|---|---|---|---|---|
| Reliability (uptime + incidents) | 30% | 25% | 25% | 25% |
| Support (response P90) | 15% | 15% | 15% | 20% |
| Security (certs) | 25% | 30% | 35% | 25% |
| Commercial (renewal flexibility) | 15% | 15% | 10% | 15% |
| Strategic fit (criticality vs spend) | 15% | 15% | 15% | 15% |
Output: ranked markdown scorecard with per-dimension breakdown and a verdict per vendor:
- **KEEP** (≥ 75) — vendor is performing; routine renewal
- **REVIEW** (50-74) — schedule a quarterly business review with the vendor before renewing
- **REPLACE** (< 50) — start an alternatives search now; do not auto-renew
### Step 3 — Measure SLA compliance
Run `scripts/sla_compliance_tracker.py --input sla_records.json --output sla_report.md`.
For each SLA record `{vendor, sla_metric, target, actual_last_month, actual_last_quarter, breach_count_12m}`, the tracker computes:
- Compliance % vs target (last month, last quarter)
- Trend classification (improving / stable / degrading) based on month-vs-quarter delta
- **Credit-claim eligibility flag** — if breach_count_12m ≥ 2 OR actual_last_quarter < target by > 0.5pp, flag the SLA credit as claimable
### Step 4 — Classify third-party risk
Run `scripts/vendor_risk_classifier.py --input catalog.json --profile <industry> --output risk_matrix.md`.
Classifies each vendor as **Critical / High / Medium / Low** across 4 risk vectors (Shared Assessments SIG-Lite-ish):
1. **Data sensitivity** — PII / PHI / cardholder / source code access
2. **Financial exposure** — annual spend × tier multiplier
3. **Operational dependency** — tier-1 + no break-glass = Critical
4. **Regulatory exposure** — industry profile drives weighting (e.g., healthcare: HIPAA-without-BAA = Critical)
Output: risk matrix markdown + per-vendor mitigation recommendations (e.g., "Tier-1 with no SOC2 → require SOC2 attestation before next renewal").
### Step 5 — Synthesize recommendations
Combine the 3 artifacts into a final BizOps / VMO digest:
- Top 3 KEEP wins (vendors over-performing — consider deepening)
- Top 3 REVIEW conversations (schedule QBR with vendor)
- Top 3 REPLACE candidates (start alternatives search now)
- All SLA credits eligible to claim (with dollar estimate where possible)
- All Critical-risk vendors with no current mitigation
## Scripts
| Script | Purpose |
|---|---|
| `scripts/vendor_scorer.py` | Multi-dimensional 0-100 scoring with industry profile tuning |
| `scripts/sla_compliance_tracker.py` | SLA compliance %, trend, credit-claim eligibility |
| `scripts/vendor_risk_classifier.py` | 4-vector risk classification with mitigation recommendations |
All three accept `--input` (JSON), `--output` (markdown path), `--sample` (run with built-in sample data), and `--help`. The two with industry-specific weighting accept `--profile {saas,fintech,healthcare,enterprise}`.
## Quick example
```bash
# Emits a weighted vendor scorecard (industry-tuned dimensions + per-vendor verdict) for the built-in sample catalog
cd business-operations/skills/vendor-management && python3 scripts/vendor_scorer.py --sample
```
## References
- `references/vendor_management_canon.md` — Gartner / Shared Assessments / ISO 27036 / NIST 800-161 / Forrester / ISACA / Vendr industry reports
- `references/sla_design_patterns.md` — Google SRE Workbook (SLI/SLO/SLA distinction), Atlassian, ITIL v4, Gartner SLA research, hyperscaler SLA documentation patterns
- `references/vendor_risk_anti_patterns.md` — Real breach post-mortems: SolarWinds, Target/HVAC, NotPetya/M.E.Doc, Capital One, Verkada, Okta 2022, log4j
## Assumptions
1. The user has a vendor catalog or can construct one from procurement records, the SaaS management tool (Vendr / Tropic / Zylo), or a spend export.
2. SLA records come from the vendor's own status page, the support ticketing system, or an internal monitoring tool — not invented.
3. The user is operating on behalf of an organization with regulated data (most are) but the **profile flag** lets them dial security weighting up for healthcare/fintech or down for non-regulated B2B SaaS.
4. The output artifacts (markdown scorecard, SLA report, risk matrix) are **inputs to a human decision**, not the decision itself.
## Anti-patterns
- **Treat all vendors at the same tier.** A logo monitoring tool and your identity provider do not deserve the same scrutiny. Use the tier field.
- **Annual review is enough.** Tier-1 vendors should be reviewed quarterly. Tier-2 semi-annually. Tier-3 at renewal.
- **Trust the security questionnaire without verification.** Ask for the SOC2 report, not a SIG checkbox. See `references/vendor_risk_anti_patterns.md`.
- **No break-glass plan for a tier-1 vendor.** If the vendor disappears tomorrow, what is the 72-hour plan?
- **Forget offboarding.** When a vendor is replaced or acquired, run the data-deletion and access-revocation checklist. SolarWinds and Okta both demonstrate why.
- **Score by gut feel.** Use the deterministic tools. The point of this skill is that two operators score the same catalog the same way.
## Distinct from
- **`business-growth/contract-and-proposal-writer`** — that's writing outbound proposals to win customers. This is scoring inbound vendors you already pay.
- **`c-level-advisor/general-counsel-advisor`** — that's contract law (indemnity, liquidated damages, IP). This is operational performance against an existing contract.
- **Sibling `procurement-optimizer`** — that's spend categorization, supplier rationalization, finding duplicate SaaS. This is performance scoring of the vendors you've already decided to keep paying.
- **`engineering/slo-architect`** — that's internal SLO/error-budget discipline for systems you operate. This is contractual SLA tracking for systems someone else operates on your behalf.
## Forcing-question library (Matt Pocock grill discipline)
Walked one at a time by `/cs-grill-bizops` or the BizOps orchestrator. Recommended answer + canon citation per question. Never bundled.
1. **"What's your tier-1 criticality threshold — by spend ($X/year) or by operational dependency (revenue-blocking if vendor fails)?"**
Recommended: operational dependency.
Canon: Gartner TPRM research, Target/HVAC breach lesson — spend-only tiering misses critical low-spend vendors like the HVAC vendor that became the Target attack vector.
2. **"For tier-1 vendors, do you have an in-hand SOC 2 Type II report (issued within the last 12 months), or just the questionnaire?"**
Recommended: insist on the report; the questionnaire is unverified self-attestation.
Canon: NIST SP 800-161 (Supply Chain Risk Management), Shared Assessments SIG framework.
3. **"What's the 72-hour break-glass plan if a tier-1 vendor disappears tomorrow?"**
Recommended: documented contingency per vendor, tested annually.
Canon: NotPetya / M.E.Doc supply chain attack, log4j response patterns.
4. **"When was the last time the SLA was actually invoked (credit claim filed)?"**
Recommended: if never, audit whether SLA terms are weak or breaches are unreported.
Canon: Atlassian SLA best practices, ITIL v4 service level management.
5. **"Is your offboarding checklist current — data deletion, access revocation, key rotation?"**
Recommended: rehearse it on one vendor per quarter.
Canon: SolarWinds + Okta 2022 breach lessons.
6. **"What's the regulatory blast-radius — HIPAA / GDPR / SOX / PCI?"**
Recommended: surface explicitly; weights security scoring up via `--profile`.
Canon: ISO/IEC 27036 (supplier relationships security).
Walk depth-first. Lock 1-3 before opening 4-6. After all are answered, invoke `vendor_scorer.py` → `sla_compliance_tracker.py` → `vendor_risk_classifier.py` in sequence.
以下是主要功能的用例提示词,可以直接复制使用。
准备季度供应商评分卡 适用于:准备季度供应商评分卡。请准备:供应商清单、合同目标、事故或表现记录、关键程度和审核标准。
请使用已安装的 vendor-management Skill。任务:准备季度供应商评分卡。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。它根据输入审查现有供应商,不监控实时服务、不确认服务赔偿法律资格,也不执行替换。[INPUT][CONSTRAINTS]比较已观察可用率与合同 SLA 目标 适用于:比较已观察可用率与合同 SLA 目标。请准备:供应商清单、合同目标、事故或表现记录、关键程度和审核标准。
请使用已安装的 vendor-management Skill。任务:比较已观察可用率与合同 SLA 目标。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。它根据输入审查现有供应商,不监控实时服务、不确认服务赔偿法律资格,也不执行替换。[INPUT][CONSTRAINTS]准备保留、复核或替换的续约简报 适用于:准备保留、复核或替换的续约简报。请准备:供应商清单、合同目标、事故或表现记录、关键程度和审核标准。
请使用已安装的 vendor-management Skill。任务:准备保留、复核或替换的续约简报。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。它根据输入审查现有供应商,不监控实时服务、不确认服务赔偿法律资格,也不执行替换。[INPUT][CONSTRAINTS]输入三家虚构供应商的合同、可用率、支持时效、事故与数据风险,商家需要决定保留、复核还是寻找替代,并准备服务抵扣材料。
案例输入资料:business-inputs.zip
Use the vendor-management Skill.
Review the supplied vendor contracts and service records. Score delivery and risk separately, calculate SLA performance using the contractual definitions, and identify any candidate service credits. Explain why a strong service score can still hide concentration risk, then assign renewal and recovery actions.
The attached business materials are:
- inputs/catalog.json
- inputs/intake_and_contracts.md
- inputs/merchant.json
- inputs/sla.json
Deliver a complete result.md report that the operations team can read, plus any finished files needed for this task. Keep supporting calculations and evidence with the deliverables. Write the report in English; use the requested target language for customer-facing copy. The business datasets are fictional examples unless the brief explicitly names a live public website.下方直接展示本次 Prompt 产生的主要文件,保留实际输出语言。
Keep HarborCloud with quarterly resilience oversight, put ParcelDesk through a recovery review before renewal, and prepare to replace OldMail. Prepare October service-credit claims totaling $200, due November 30, 2026. Treat EdgePlatform as an urgent recovery exposure: it blocks order taking and has no recovery plan, but missing service records prevent a performance score or supported credit claim.
All business evidence is synthetic; the results below are calculations and proposed actions, not completed operational changes or awarded credits. Review basis: November 3, 2026; October service performance, August–October quarter, and supplied trailing-12-month catalog measures.
The SaaS profile is appropriate for this ecommerce portfolio. The Skill's deterministic service score combines reliability (30%), support (15%), security evidence (25%), commercial flexibility (15%), and strategic fit (15%). It is a composite vendor-performance score, rather than a pure uptime score. KEEP is ≥75, REVIEW is 50–<75, and REPLACE is <50. Contract compliance and risk are assessed separately.
| Vendor | Annual spend | Reliability | Support | Security | Commercial | Fit | Score /100 | Service verdict |
|---|---|---|---|---|---|---|---|---|
| HarborCloud | $24,000 | 99.8 | 100.0 | 55.0 | 100.0 | 100.0 | 88.7 | KEEP |
| ParcelDesk | $12,000 | 90.0 | 84.5 | 15.0 | 50.0 | 90.0 | 64.4 | REVIEW |
| OldMail | $6,000 | 5.0 | 33.8 | 0.0 | 35.0 | 70.0 | 22.3 | REPLACE |
| EdgePlatform | Not supplied | — | — | — | — | — | Not scoreable | Hold renewal decision pending evidence and recovery review |
There is one supported KEEP win, one REVIEW conversation, and one REPLACE candidate; there are not three in each category. HarborCloud has 99.99% uptime, one incident in 12 months, one-hour response P90 and manual renewal. ParcelDesk's 12-hour support P90 breaches its eight-hour commitment despite an 84.5 support subscore: the scorer uses a generic response-time curve, not the contract threshold. OldMail has eight incidents, 97% catalog uptime and no security certifications, making replacement the service recommendation as well as a risk priority.
Catalog spend totals $42,000 annually. EdgePlatform's contractual monthly fee is $8,333.33 (annualized fee equivalent $99,999.96), but actual annual spend and catalog coverage are missing. Do not silently combine that fee equivalent with recorded spend.
Availability is higher-is-better; support response P90 is lower-is-better. Equality meets each stated threshold. No planned-maintenance exclusions apply. Monthly credit triggers use October results, not the quarter or historical breach counts.
| Vendor / metric | Contract threshold | October | August–October | October result and trend | October candidate credit |
|---|---|---|---|---|---|
| HarborCloud availability | ≥99.9% | 99.99% | 99.99% | MET; stable | $0 |
| ParcelDesk response P90 | ≤8 hours | 12 hours | 16 hours | BREACHED by 4 hours (50% over); improving by 4 hours | $1,000 × 10% = $100 |
| OldMail availability | ≥99.9% | 97% | 98% | BREACHED by 2.9 percentage points; degrading by 1 point | $500 × 20% = $100 |
| EdgePlatform availability | ≥99.5% | Missing | Missing | Undetermined | Undetermined |
| EdgePlatform response P90 | ≤8 hours | Missing | Missing | Undetermined | Undetermined |
HarborCloud exceeds target by 0.09 percentage points in both periods. ParcelDesk's quarter response P90 exceeds target by eight hours (100% over); OldMail's quarter availability misses by 1.9 percentage points. These are quarter comparisons, not proof of separate monthly credit entitlements.
For supplementary target-attainment ratios, availability uses min(100, actual/target ×100), and response time uses min(100, target/actual ×100). October / quarter ratios are HarborCloud 100% / 100%, ParcelDesk 66.67% / 50%, and OldMail 97.10% / 98.10%. These are normalized ratios, not percentages of tickets or periods meeting SLA. Aggregated P90 values cannot establish ticket-level compliance, and raw monitoring/ticket events were not supplied to recalculate the input aggregates.
The unmodified Skill tracker flags ParcelDesk and OldMail using repeated-breach or quarter-gap heuristics. Those flags are screening aids, not contract entitlement rules. Here the monthly contract triggers independently support both $100 candidates. OldMail's four historical breaches and ParcelDesk's three do not justify multiplying the October credit across 12 months. The tracker's instruction to flag OldMail REVIEW does not replace its stronger REPLACE scorecard decision.
Mia should assemble separate claim packages for ParcelDesk and OldMail with the October monitoring and ticket evidence, applicable contract clause, monthly fee evidence and calculation. Alex should review and authorize submission by November 20, ahead of the contractual November 30 deadline (the window starts the following month and runs 30 days). Neither claim has been submitted. Track acknowledgment, award and application to a future invoice separately. Credits are not cash refunds, recovered revenue or confirmed savings.
EdgePlatform's contract offers 10% for availability below 99.5% or 5% for response P90 above eight hours, without stacking, capped at 10% monthly. Its conditional amounts are $833.33 for availability breach, $416.67 for response-only breach, and $833.33 if both breach, rounded to cents. These are scenarios, excluded from the $200 total. Alex should retrieve October records and monthly fee evidence by November 13; if a breach is demonstrated, prepare a claim before November 30. HarborCloud has no observed breach, and its excerpt provides no credit schedule.
The Skill assesses four vectors separately and takes the worst rating, elevating two High vectors to Critical. These are rule-based exposure ratings, not breach probabilities or a certification of compliance.
| Vendor | Data | Financial | Operational | Regulatory | Overall | Mitigation position |
|---|---|---|---|---|---|---|
| HarborCloud | High | Low | High | Medium | Critical | DPA/encryption checks complete; Type II exceptions reviewed; recovery plan assigned |
| ParcelDesk | High | Low | Medium | Medium | High | Backup carrier portal exists; DPA review pending |
| OldMail | High | Low | Low | High | Critical | No current mitigation |
| EdgePlatform | Not classified | Not classified | Critical | Not classified | At least Critical operational exposure | No recovery mitigation; omitted from catalog |
HarborCloud's financial exposure is $24,000 ×1.5 = $36,000; ParcelDesk's is $12,000 ×1 = $12,000; OldMail's is $6,000 ×0.6 = $3,600. Each is below the classifier's $50,000 Medium threshold. Financial exposure here is weighted vendor spend, not estimated outage loss. All three catalog vendors access PII, creating High data sensitivity. OldMail additionally has High regulatory exposure under the SaaS rules because it lacks SOC2 evidence. US consumer PII/email is the stated scope; PHI and direct cardholder data are excluded.
A strong service score can coexist with concentration risk. HarborCloud's 88.7 measures observed delivery and commercial attributes; its tier-1 role means an outage stops order taking. PII plus High operational dependency produces Critical overall risk even with a recovery plan. Its $24,000 is 57.14% of catalog spend, but that share is not a revenue-at-risk estimate and excludes EdgePlatform. The supplied static maintenance page, daily order export and manual support support continuity; they do not demonstrate restored order acceptance or a tested failover platform. No rehearsal result is supplied.
EdgePlatform also blocks order taking and has no 72-hour plan. Multiple essential vendors do not automatically provide redundancy: the brief does not establish whether they are independent alternatives or sequential dependencies. Map their shared hosting, identity, data and subcontractor dependencies before treating either as a backup. A current Type II report does not remove recovery concentration. Its report is dated August 1, 2026, but exception review is explicitly documented only for HarborCloud.
The Critical vendors with no current mitigation are OldMail, plus EdgePlatform's Critical operational dependency. HarborCloud remains Critical with documented mitigations; do not relabel it Low because those controls exist.
Dates below are proposed operating deadlines; actions remain unexecuted. All three catalog contracts end January 31, 2027. Notice periods are not supplied, so check them immediately rather than assuming the end date is the cancellation deadline.
| Vendor | Owner and deadline | Recovery and evidence requirement | Renewal gate and cadence |
|---|---|---|---|
| HarborCloud | Alex: plan review by Nov 17; drill by Dec 1 | Exercise exports, support handoff and restore/order-taking options over a 72-hour outage; record recovery time, data loss and gaps. Retain Aug 1 Type II report and reviewed exceptions; keep DPA/encryption evidence current. | KEEP subject to documented drill findings and accepted remediation before Jan 31 manual renewal; quarterly review. Consider deeper use only after dependency review. |
| ParcelDesk | Mia: claim package by Nov 20; Alex: recovery QBR by Dec 3 | Request RCA and staffed response recovery plan; require P90 ≤8h in the next monthly review, verify backup portal usability, complete DPA/encryption review by Nov 17 and obtain stronger assurance evidence. | REVIEW evergreen notice terms now; renew only with measured recovery and privacy closure. If response still breaches next month, evaluate alternatives and activate backup as needed. Monthly monitoring during recovery, then semiannual review. |
| OldMail | Alex: notice check by Nov 6, replacement plan by Nov 17; Mia: claim package by Nov 20 | Request RCA for eight incidents; minimize access while replacing, review DPA/encryption and seek current Type II evidence. Validate replacement exports and messaging before cutover. | REPLACE; prepare authorized nonrenewal before the actual notice deadline. Target migration by Jan 15, ahead of Jan 31 expiry; weekly migration checks. No automatic cancellation has occurred. |
| EdgePlatform | Alex: records/catalog completion by Nov 13; recovery plan by Nov 17; drill by Dec 1 | Establish service owner, actual spend, renewal/notice dates, uptime, support P90, incidents, data access and assurance review. Prequalify an independent backup and test restoration of order taking. | Escalate immediately; no routine renewal recommendation without complete records and accepted recovery capability. Quarterly tier-1 review plus weekly remediation tracking. |
For replacement offboarding, Mia exports and verifies data; Alex revokes OAuth/API access, rotates credentials and obtains deletion certification after cutover validation. Preserve claim evidence before deletion. Escalate missed recovery deadlines to Alex and record explicit acceptance of any remaining exposure before renewal.
The six intake answers are supplied in order: revenue-blocking tier-1 classification; Type II evidence; 72-hour plans; claim history and measurement periods; offboarding responsibilities; then data/regulatory scope. No additional intake assumption changes these answers. Product, order-return and sales-background fields are excluded from scoring.
evidence/catalog.json, evidence/sla.json, and evidence/intake_and_contracts.md preserve the supplied business evidence and contract excerpts.scorecard.md and risk_matrix.md are the original deterministic outputs for the three catalog vendors. Generic mitigation prompts in the matrix are reconciled with actual intake evidence in this report.sla_tracker_raw.md preserves the original heuristic output; the contractual table above controls credit decisions.contract_sla_calculations.csv contains the month/quarter calculations; calculate.py reproduces them from the retained SLA evidence when run with Python 3.The material evidence gaps are EdgePlatform's missing catalog/service records, missing raw events for claim attachment and independent aggregate verification, and missing cancellation notice periods. These prevent an EdgePlatform service verdict or quantified claim and determine the timing of renewal/exit decisions.
案例中的商家经营资料为模拟数据;涉及网站检查时,报告中的页面观察来自所列公开网址。
它根据输入审查现有供应商,不监控实时服务、不确认服务赔偿法律资格,也不执行替换。
核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。
使用获授权输入,不把密钥贴入提示词。采用前检查面向客户的声明、计算、代码改动及任何拟议的外部操作。
评估供应商表现、检查合同 SLA 差距并分类第三方风险。独立 Python 工具通过评分卡、SLA 检查和风险分类支持续约决策。
按实际 Agent 选择方式,安装完整包,不要只复制页面中的 SKILL.md。 供应商清单、合同目标、事故或表现记录、关键程度和审核标准。 开启新 Agent 会话,明确要求使用 vendor-management。先用小型样本尝试下方一个场景,并检查输出。
准备季度供应商评分卡;比较已观察可用率与合同 SLA 目标;准备保留、复核或替换的续约简报
它根据输入审查现有供应商,不监控实时服务、不确认服务赔偿法律资格,也不执行替换。
核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。
核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。
暂无评论。