Back to Details

vendor-evaluation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Vendor Evaluation

供应商评估

Pick the right tool or service, negotiate fair terms, and avoid the lock-in traps. Stack-agnostic. Applies to SaaS, infrastructure providers, agencies, and any external dependency.
挑选合适的工具或服务，协商公平条款，避免锁定陷阱。与技术栈无关，适用于SaaS、基础设施提供商、代理机构及任何外部依赖项。

When to use

使用场景

  • Selecting a tool or vendor for a new need
  • Evaluating alternatives to a current vendor
  • Build vs buy analysis
  • Renewal coming up: should we stay or switch?
  • Running a formal RFP or RFI
  • Comparing finalists in a vendor selection
  • Negotiating a contract
  • Assessing vendor risk (financial, security, dependency)
  • 为新需求选择工具或供应商
  • 评估当前供应商的替代方案
  • 自研vs采购分析
  • 服务即将续约：留用还是切换？
  • 发起正式的RFP或RFI（信息请求书）
  • 对比供应商筛选中的入围者
  • 谈判合同
  • 评估供应商风险（财务、安全、依赖风险）

When NOT to use

非适用场景

  • General cost reduction (use 
    cost-optimization
    )
  • Specific contract legal terms (those go to legal)
  • Performance issues with an existing vendor (try fixing before switching)
  • Hiring an agency for a one-off project (lighter framework needed)
  • 一般性成本削减（使用
    cost-optimization
    ）
  • 特定合同法律条款（此类问题请咨询法务）
  • 现有供应商的性能问题（先尝试修复再考虑切换）
  • 为一次性项目聘请代理机构（需更轻量化的框架）

Required inputs

必要输入

  • The need (what problem are you solving, what would success look like)
  • Constraints (budget, timeline, integration requirements)
  • Stakeholders (users, IT, security, finance, legal)
  • Existing context (what's already used, what's been tried)
  • Compliance requirements
  • 需求说明（要解决什么问题，成功的标准是什么）
  • 约束条件（预算、时间线、集成要求）
  • 相关利益方（用户、IT、安全、财务、法务）
  • 现有环境（已使用的工具、已尝试过的方案）
  • 合规要求

The framework: 5 phases

框架：5个阶段

A structured vendor evaluation. Skip phases at your peril.
一套结构化的供应商评估流程，请勿随意跳过阶段。

Phase 1: Define the need

阶段1：明确需求

Before looking at vendors, define what you actually need.
  • What problem are you solving?
  • What's the user / use case?
  • What does "success" look like in 6 months? In 2 years?
  • What's the budget (range, not just ceiling)?
  • What's the timeline?
  • Are there must-have integrations or constraints?
The temptation: skip this and start demoing. Vendors are happy to show off; you end up choosing what looks shiny rather than what fits.
在考察供应商之前，先明确您的实际需求。
  • 要解决什么问题？
  • 用户/使用场景是什么？
  • 6个月后、2年后的“成功”标准分别是什么？
  • 预算范围（不仅是上限）是多少？
  • 时间线是怎样的？
  • 是否有必须满足的集成要求或约束条件？
常见误区：跳过此阶段直接开始演示。供应商乐于展示产品亮点，但最终您可能会选择看起来光鲜却不契合需求的工具。

Phase 2: Build vs buy

阶段2：自研vs采购决策

Before evaluating vendors, decide whether you should build instead.
Build when:
  • It's core to the business (differentiating)
  • The need is so specific no vendor matches
  • The economics work at your scale
  • You have the team to maintain it
  • Vendor lock-in would be unacceptable
Buy when:
  • It's table stakes (not differentiating)
  • The need is well-served by existing products
  • The economics favor it
  • The team should focus elsewhere
  • The vendor's specialization beats your generalism
Most teams over-build. The rule of thumb: buy unless there's a strong reason to build. Then question even that strong reason.
在评估供应商之前，先决定是自研还是采购。
选择自研的情况：
  • 该功能是业务核心（具备差异化优势）
  • 需求过于特殊，没有供应商能匹配
  • 在您的业务规模下，自研更具经济性
  • 您有团队能够维护该功能
  • 供应商锁定风险不可接受
选择采购的情况：
  • 该功能是基础必备项（无差异化）
  • 现有产品已能很好地满足需求
  • 采购更具经济性
  • 团队应聚焦于其他核心业务
  • 供应商的专业能力优于您的通用团队
大多数团队过度自研。经验法则：除非有充分理由自研，否则优先选择采购。即便有充分理由，也要再次审慎考量。

Phase 3: Generate the shortlist

阶段3：生成候选名单

Cast a wider net than feels comfortable, then narrow.
Sources:
  • Internal team's existing knowledge
  • Industry analyst reports (Gartner, Forrester, etc.)
  • Peer recommendations (other companies similar to yours)
  • Reviews (G2, Capterra; with caveats about review quality)
  • Adjacent vendors you already use (often have the feature you need)
  • Open-source alternatives
Cast wide first. Aim for 5-8 candidates. Then narrow to 2-4 finalists for deep evaluation.
先广泛筛选，再逐步缩小范围。
信息来源：
  • 内部团队的现有经验
  • 行业分析师报告（如Gartner、Forrester等）
  • 同行推荐（与您公司规模类似的企业）
  • 用户评价（如G2、Capterra；注意评价质量）
  • 您已合作的关联供应商（通常具备您需要的功能）
  • 开源替代方案
先广泛撒网，目标是5-8个候选者。然后缩小至2-4个入围者进行深度评估。

Phase 4: Score the finalists

阶段4：为入围者评分

Use a scorecard. Without one, you'll be swayed by demo theatrics or who has the friendliest sales rep.
Scorecard dimensions (weight by your situation):
Functional fit (40%): Does it do what you need? Edge cases handled? UX quality. Workflow fit.
Technical fit (15%): Integration with your stack. API quality and completeness. Data export and portability. Performance at your scale. Self-hosted, hybrid, or SaaS-only.
Operational fit (10%): Onboarding effort. Training and adoption. Documentation quality. Support quality (test by submitting a ticket). SLAs.
Security and compliance (10%): SOC 2, ISO 27001, HIPAA, etc., as applicable. Data residency. Encryption at rest and in transit. Access controls and audit logs. Penetration test results (ask). Subprocessors.
Vendor health (10%): Years in business. Funding and runway (or revenue if private). Customer base size and similar customers. Public references. Roadmap visibility.
Cost (10%): License or subscription cost. Implementation and onboarding cost. Training cost. Integration cost. Opportunity cost (in-house resource time). Switching cost (in case of failure).
Lock-in risk (5%): Data export quality. Standard formats vs proprietary. Migration paths to alternatives. Open standards alignment. Contract escape clauses.
Score each finalist 1-5 on each dimension. Multiply by weight. Sum.
The score isn't gospel. It surfaces the tradeoffs.
使用评分卡。没有评分卡的话，您可能会被演示效果或友好的销售代表影响判断。
评分卡维度（可根据您的情况调整权重）：
功能契合度（40%）： 是否能满足需求？是否能处理边缘场景？用户体验质量。工作流契合度。
技术契合度（15%）： 与您技术栈的集成能力。API的质量与完整性。数据导出与可移植性。在您业务规模下的性能表现。是否支持自建、混合或仅SaaS部署。
运营契合度（10%）： 上线部署难度。培训与推广难度。文档质量。支持服务质量（可通过提交工单测试）。服务水平协议（SLA）。
安全与合规（10%）： 适用的SOC 2、ISO 27001、HIPAA等认证。数据驻留要求。静态与传输数据加密。访问控制与审计日志。渗透测试结果（可向供应商索要）。分包商情况。
供应商健康度（10%）： 经营年限。资金储备与 runway（若为私有企业则看营收）。客户规模及同类客户情况。公开参考案例。 roadmap透明度。
成本（10%）： 许可或订阅费用。实施与上线费用。培训费用。集成费用。机会成本（内部资源投入时间）。切换成本（若失败需更换的成本）。
锁定风险（5%）： 数据导出质量。标准格式vs专有格式。向替代方案迁移的路径。是否符合开放标准。合同退出条款。
为每个入围者在各维度上打1-5分，乘以权重后求和。
评分并非绝对标准，它只是呈现权衡取舍。

Phase 5: Negotiate

阶段5：谈判

Most enterprise contracts are negotiable. Most aren't negotiated.
What's negotiable:
  • Price (multi-year, volume, prepayment, end-of-quarter timing)
  • Terms (payment schedule, renewal terms)
  • Success commitments (training, onboarding, support)
  • SLAs (uptime, response time, credits)
  • Termination clauses (auto-renewal, notice period, data export)
  • Liability caps and indemnity (legal will care about these)
  • Subprocessors and data handling (security/legal cares)
Common negotiation moves:
  • Multi-year discount (3-year for a 15-30% discount is common)
  • Volume tiers (commit to higher usage for a per-unit discount)
  • Annual prepayment for a discount
  • Free or discounted onboarding
  • Pilot pricing (trial period at reduced rate)
  • "Most favored customer" clauses (if your size warrants)
What to avoid:
  • Multi-year lock with no escape clause for material breach
  • Auto-renewal with short notice window (under 60 days; want longer)
  • "All right, no further negotiation" stance from the start
  • Signing without legal review
大多数企业合同是可协商的，但多数企业并未进行谈判。
可协商内容：
  • 价格（多年合作、批量采购、预付款、季末时机）
  • 条款（付款计划、续约条款）
  • 成功承诺（培训、上线、支持）
  • SLA（ uptime、响应时间、赔付）
  • 终止条款（自动续约、通知期、数据导出）
  • 责任限额与赔偿（法务会关注这些）
  • 分包商与数据处理（安全/法务会关注）
常见谈判策略：
  • 多年合作折扣（3年合作通常可享15-30%折扣）
  • 批量阶梯定价（承诺更高用量以获取单位折扣）
  • 年度预付款折扣
  • 免费或折扣价的上线服务
  • 试点定价（试用期享受优惠费率）
  • “最惠客户”条款（若您的企业规模达标）
需避免的情况：
  • 多年锁定且无重大违约退出条款
  • 自动续约且通知期过短（少于60天；应争取更长时间）
  • 一开始就摆出“没得谈”的姿态
  • 未经法务审核就签署合同

Workflow

工作流程

Step 1: Define the need

步骤1：明确需求

Write a one-page brief: what we need, why, success criteria, constraints, stakeholders.
撰写一页简短说明：需求内容、原因、成功标准、约束条件、相关利益方。

Step 2: Build vs buy

步骤2：自研vs采购决策

Honestly answer the build/buy question. Document the rationale.
诚实地回答自研或采购的问题，并记录理由。

Step 3: Generate shortlist

步骤3：生成候选名单

Wider net first, narrowed via desk research:
  • Read summaries
  • Skim reviews
  • Look at customer logos
  • Skim docs
  • Skim API specs
Eliminate obvious misfits. Land on 2-4 finalists.
先广泛筛选，再通过案头研究缩小范围：
  • 阅读摘要
  • 浏览评价
  • 查看客户案例
  • 浏览文档
  • 浏览API规格
剔除明显不符合的选项，最终确定2-4个入围者。

Step 4: Run demos and trials

步骤4：进行演示与试用

For each finalist:
  • Demo with the use case (don't take their default demo; bring yours)
  • Trial period if possible
  • Reference calls with similar customers
  • Pilot with real data if feasible
Don't be charmed by the polished demo. Try it with your real workflow.
针对每个入围者：
  • 结合您的使用场景进行演示（不要使用供应商的默认演示，用您自己的场景）
  • 如有可能，进行试用期测试
  • 与同类客户进行参考访谈
  • 如有可行，用真实数据进行试点
不要被 polished 的演示迷惑，要用您的真实工作流测试工具。

Step 5: Run security and compliance review

步骤5：开展安全与合规审查

Critical for any vendor handling sensitive data:
  • Request SOC 2 / ISO 27001 reports
  • Review their security questionnaire (most have one ready)
  • Verify data handling matches your requirements
  • Identify subprocessors
This can take weeks for enterprise vendors. Start early.
对于处理敏感数据的供应商，此步骤至关重要：
  • 索要SOC 2 / ISO 27001报告
  • 审查他们的安全问卷（多数供应商已有现成问卷）
  • 验证数据处理是否符合您的要求
  • 确认分包商情况
对于企业级供应商，此步骤可能需要数周时间，请尽早启动。

Step 6: Score

步骤6：评分

Apply the scorecard. Do this collaboratively with stakeholders.
The scoring conversation matters more than the final number. It surfaces disagreement (one person scored UX 5, another scored 2: why?).
应用评分卡，与相关利益方协作完成。
评分讨论比最终分数更重要，它能暴露分歧（比如有人给用户体验打5分，有人打2分：原因是什么？）。

Step 7: Negotiate

步骤7：谈判

With the apparent winner:
  • Open negotiation by asking for terms (not just price)
  • Be willing to walk
  • Run negotiations with #2 in parallel where appropriate (gives you leverage)
与潜在胜出者：
  • 从询问条款（而非仅价格）开始谈判
  • 要有放弃的准备
  • 适当与第二名并行谈判（这能给您带来筹码）

Step 8: Plan the rollout

步骤8：规划部署

Contract signing is the start, not the end. Plan:
  • Onboarding owner
  • Training plan
  • Migration plan if replacing an incumbent
  • Success criteria at 30, 90, 180 days
  • Renewal calendar
合同签署只是开始，而非结束。规划内容包括：
  • 上线负责人
  • 培训计划
  • 若替换现有供应商，制定迁移计划
  • 30天、90天、180天的成功标准
  • 续约日历

Step 9: Document

步骤9：文档记录

Record:
  • The decision and the rationale
  • Alternatives considered
  • Scorecard results
  • Negotiated terms
  • Renewal date and notice deadlines
  • Owner of the relationship
This is gold for the next renewal or the next similar evaluation.
记录以下内容：
  • 决策及理由
  • 考虑过的替代方案
  • 评分卡结果
  • 协商后的条款
  • 续约日期与通知截止日期
  • 供应商关系负责人
这些记录对下次续约或类似评估非常有价值。

Failure patterns

常见失败模式

Skipping the needs definition. Demoing first. Buying what's shiny. Realizing 6 months in that the actual need wasn't met.
Single-source decisions. Talking to one vendor; deciding. No comparison. Probably overpaying or under-fitting.
Charisma-driven decisions. Buying based on the sales rep's likability. The product is what you'll use for years; the rep won't be there.
Reference calls that the vendor curated. Of course their references love them. Find references the vendor didn't suggest.
Glossing over security. Security review skipped because of timeline pressure. Then a breach. Slow down or accept the risk explicitly.
Demos that don't match the use case. Their default demo, not yours. Always do a use-case demo.
Trial that doesn't simulate real usage. A trial with synthetic data tells you the product works in synthetic conditions. Use real (or close to real) data.
Negotiating only on price. Terms, SLAs, and exit clauses matter more for long-term satisfaction than 5% price.
Auto-renewal without notice tracking. Renewal happens; rate goes up 15%. No one was watching. Track renewals; review with notice.
Lock-in without exit plan. Tightly integrating into a vendor's proprietary surface. When you want to leave, you can't. Plan exit at the start.
Multi-year contract for an unproven vendor. Save the multi-year for vendors you trust. New vendor: shorter term, evaluate after.
No internal champion. Tool selected; no one drives adoption. Tool sits unused. Identify the champion before signing.
Negotiating after a verbal commitment. "Yes, we want to buy" means they have less reason to negotiate. Keep options open until terms are settled.
Ignoring red flags in security review. Vendor's security responses are evasive or incomplete. Treat as a no.
Comparing apples to oranges. Vendors price differently (per user, per usage, flat). Build a comparable cost model at your scale.
跳过需求定义阶段：先看演示，选择光鲜的工具，6个月后才发现未满足实际需求。
单一来源决策：只和一家供应商沟通就决定，没有对比，可能多花钱或适配性不足。
受个人魅力影响的决策：因销售代表讨人喜欢而选择产品，但您要使用的是产品，而非销售代表，他们不会一直负责您的业务。
使用供应商安排的参考访谈：他们提供的参考客户当然会称赞他们，要找供应商未推荐的参考客户。
忽视安全审查：因时间压力跳过安全审查，随后发生数据泄露。要么放慢速度，要么明确接受风险。
演示与使用场景不符：使用供应商的默认演示而非您的场景，务必进行基于使用场景的演示。
试用未模拟真实使用：用模拟数据试用只能说明产品在模拟环境下可用，要用真实（或接近真实）的数据。
仅就价格谈判：条款、SLA和退出条款对长期满意度的影响远大于5%的价格优惠。
未跟踪自动续约通知：自动续约生效，费率上涨15%，却无人关注。跟踪续约日期，提前进行审查。
无退出计划的锁定：深度集成到供应商的专有系统中，想切换时却无法做到，从一开始就要规划退出方案。
为未经验证的供应商签订多年合同：多年合同留给您信任的供应商，新供应商选择短期合同，后续再评估。
无内部负责人：选定工具后，无人推动推广，工具被闲置。签署合同前要确定内部负责人。
口头承诺后再谈判：“我们要买”意味着供应商更没有谈判的动力，在条款确定前保持选项开放。
忽视安全审查中的警示信号：供应商的安全回复含糊不清或不完整，直接排除该供应商。
不当对比：供应商定价方式不同（按用户、按用量、固定价格），要构建适合您业务规模的可比成本模型。

Output format

输出格式

A vendor evaluation document includes:
  • Need brief: problem, success criteria, constraints
  • Build vs buy decision: with rationale
  • Shortlist: 2-4 finalists with brief description
  • Scorecard: filled out per finalist, or state the gap per the data-availability rule
  • Demo and trial notes: what was learned
  • Security and compliance summary: findings per finalist
  • Reference call notes: what customers said
  • Recommendation: which vendor, with rationale
  • Negotiated terms: what was agreed
  • Rollout plan: onboarding, training, migration
  • Renewal calendar: with notice deadline
供应商评估文档应包含：
  • 需求简报：问题、成功标准、约束条件
  • 自研vs采购决策：附带理由
  • 候选名单：2-4个入围者及简要说明
  • 评分卡：每个入围者的评分结果，或根据数据可用性规则说明缺口
  • 演示与试用笔记：学到的内容
  • 安全与合规总结：每个入围者的审查结果
  • 参考访谈笔记：客户反馈
  • 推荐方案：选择的供应商及理由
  • 协商后的条款：达成的协议
  • 部署计划：上线、培训、迁移
  • 续约日历：包含通知截止日期

If required data is unavailable

若必要数据缺失

This skill's output depends on data, measurements, or tool results it cannot generate on its own. When a required input, tool, or data source is unavailable or unverifiable, the sanctioned output is the deliverable with the gap stated: what was needed, what was actually obtained or verified, and which parts of the output are affected. Fabricating, estimating, or interpolating a required number to complete the deliverable is never sanctioned. A stated gap is a complete answer.
本技能的输出依赖于自身无法生成的数据、测量结果或工具输出。当必要输入、工具或数据源不可用或无法验证时，标准输出是在交付物中说明缺口：所需内容、实际获取或验证的内容，以及输出中受影响的部分。绝不允许编造、估算或插值所需数据来完成交付物，说明缺口即为完整答案。

Reference files

参考文件

  • references/evaluation-rubric.md
     - Scoring template with weighted dimensions, 1-5 scale criteria for each dimension, and a worked vendor-comparison example.
  • references/evaluation-rubric.md
     - 带权重维度的评分模板，各维度的1-5分评分标准，以及供应商对比示例。