conditional-customer-success

条件性客户成功

适用于存在持续性人际关系的产品的条件性技能。此技能绝不能在每种产品情境下都加载。只有当产品拥有账户、续约、QBR，或专门的客户成功团队时，才会加载。如果不具备这些条件——例如内部工具、纯交易型产品，或没有基于账户开展互动的公共服务——此技能会拒绝执行，并将调用方转至其他技能。

何时加载（应触发示例）

示例	符合条件的原因
配有指定客户经理的 B2B 订阅产品	拥有账户、续约和专门的客户成功团队
定期开展季度业务回顾的企业级 SaaS	QBR 周期、基于账户层级的互动
需要分析合同组合的续约风险	续约证据、客户流失风险信号
配有专门客户成功团队来管理客户健康计划的产品	成功计划、健康度跟踪
已发现扩展账户的机会，但采用情况信号不一	扩展机会伴随关系背景
客户反馈闭环——发现洞察、进行产品改进，并需要与客户沟通	闭环客户之声

何时不使用

对于没有账户、续约、QBR 或客户成功团队的产品，绝不能加载此技能。请参阅下方的应不触发示例。

何时不加载（应不触发示例）

当产品情境不具备所需的前提条件时，绝不能加载此技能。此技能必须拒绝执行，并将调用方转至其他技能。

示例	不适用的原因
没有账户、续约或 QBR 的内部开发者工具	不存在持续性的人际关系；没有客户成功团队
纯交易型电子商务产品——一次性购买，不管理账户	没有账户、续约、QBR 或客户成功团队
公共服务福利申请门户——没有基于账户层级的互动，也没有客户成功团队	没有账户（客户成功语境下）、续约或 QBR
采用订阅计费、但没有客户成功人际关系的消费者手机游戏	仅有订阅并不足够；不存在客户成功人际关系
由社区提供支持、但没有付费账户的开源项目	没有账户、续约或客户成功团队
面向单个团队的内部分析仪表板	团队之外不存在持续性关系；没有客户成功团队

拒绝规则：如果没有任何应触发条件——也就是说，产品没有账户、续约、QBR 或客户成功团队——此技能必须拒绝执行，并提供适用性评估，记录缺失的前提条件，同时将调用方转至最合适的技能（product-analytics-and-measurement、product-adoption 或 product-lifecycle-learning）。

产品／关系模式

此技能定义了客户成功实践的适用条件，以及针对四种不同模式所需的调整。这里的任何模式都不默认采用 SaaS。

1. B2B 订阅

完全适用。 账户、续约、QBR、扩展层级和专门的客户成功团队，是典型的适用情境。所有产出物均适用：成功计划、健康度／风险记录、升级路径、交接协议和闭环反馈。

2. 交易型（非订阅）

部分适用——需调整。 产品可能拥有回头客和账户关系，但没有正式订阅。客户成功方面的调整：

• 成功计划侧重于重复购买模式和再次下单结果，而非订阅续约日期。
• 健康度证据采用购买频率、订单金额趋势和账户互动信号，而非 MRR 或客户流失指标。
• QBR 调整为由购买里程碑或账户层级触发的定期业务回顾，而非按日历日期安排。
• 当购买频率下降或账户进入休眠状态时触发升级。

3. 公共服务

最小化适用范围——优先路由。 公共服务产品通常面向公民或受益人，而非“账户”。只有在存在明确的账户制互动（例如，案例管理门户）时，才适用 CS。

• 成功计划应转变为服务成果计划，而非商业计划。
• 健康状况的证据应采用服务可及性公平性、不同群体间的完成率差距和无障碍障碍等指标——绝不使用商业指标。
• 升级应路由至项目治理层，而非商业领导层。
• 隐私边界更加严格：不得将公民数据挪作他用。参见 references/privacy-and-human-judgment.md。

如果不存在账户制互动，应拒绝，并路由至 product-adoption（用于服务采用情况诊断）和 product-analytics-and-measurement（用于服务成果衡量）。

4. 内部产品

有条件适用——强烈建议路由至其他领域。 内部产品可能拥有“内部客户”（其他团队、业务部门），但只有在存在定期的人际关系和结构化互动时，才适用 CS。

• 成功计划应转变为内部服务级别协议，而非商业计划。
• 健康状况的证据应采用内部采用率、工作流完成情况和节省时间等指标——绝不使用收入或 MRR。
• QBR 应转变为内部服务评审，并围绕团队成果展开。
• 升级应路由至内部治理层，而非商业领导层。

如果内部产品不存在定期的人际关系（例如，单一团队使用的分析仪表板），应拒绝，并路由至 product-adoption 或 product-lifecycle-learning。

核心产物

每项产物都是决策支持工具，绝不是自动化决策。

1. 适用性判定

在应用任何客户成功方法之前，先进行适用性评估。如果产品情境中没有账户、续约、QBR 或 CS 团队，应拒绝并将调用方路由至其他领域。记录缺少哪些前提条件。

模板：templates/applicability-decision.md

2. 成功计划

结构化记录客户期望的成果、与之匹配的产品能力、可衡量的里程碑，以及指定的关系负责人。不是销售计划，不是支持工单，也不是项目计划。成功计划是一份持续更新的产物，用于将客户意图与产品证据联系起来。

模板：templates/success-plan.md

3. 健康状况／风险记录

一份基于证据的记录，绝不是自动生成的评分。针对每个健康维度，记录以下内容：

• 信号（可观察到的证据，而非代理指标）。
• 来源（分析数据、采用情况、直接观察）。
• 趋势（变化方向和近期情况）。
• 可信度（证据的可靠程度）。
• 冲突信号（呈现分歧，而非强行达成共识）。

模板：templates/health-risk-record.md

4. 升级路径

定义从信号到决策者的路径，并设置明确的人工判断关卡。每次升级都必须先由人作出决定，再采取行动。该路径应定义：

• 触发信号及其阈值。
• 升级负责人（明确的角色，而非系统）。
• 评审频率。
• 决策选项（以及各选项的决策者）。
• 未能作出决定时的后备方案。

模板：templates/escalation-and-feedback-closure.md

5. 移交协议

明确移交给产品、支持和工程团队，并划分清晰的职责边界：

移交事项	触发条件	接收团队	材料
基于客户证据的功能请求	在 ≥3 个账户中验证出相同模式	产品	成功计划摘录 + 健康状况证据
支持升级	影响账户的阻塞问题	支持	包含账户背景的升级记录
存在账户风险的技术缺陷	可复现的 Bug，影响 ≥1 个账户	工程	缺陷记录 + 账户影响评估
需要采取生命周期措施的流失风险	健康状况持续下降，且 2+ 次补救尝试失败	产品生命周期学习	健康状况/风险记录 + 补救历史

6. 闭环反馈

从客户洞察到产品变更，再到客户沟通的路径：

Customer Insight → Validate (pattern? isolated?) →
  Product Decision (build / defer / decline) →
    Implementation → Communication Back to Customer →
      Close Loop (record evidence)

每一步都会记录。“向客户反馈处理结果”是必需环节——闭环意味着客户知道其反馈得到了怎样的处理。参见 templates/escalation-and-feedback-closure.md。

隐私与人工判断边界

这些边界不可妥协。

客户反馈不得变成监控

• 收集反馈须征得同意，并说明用途。
• 使用范围不得超出所述用途。
• 可以汇总数据以发现模式；不得超出所述用途跟踪个人行为。
• 在团队间共享的客户数据应限于最低必要范围。

健康度评分用于辅助决策，不用于自动决策

• 健康状况信号是一种证据；不得据此自动采取行动（不得自动判定流失，也不得未经人工审核自动升级）。
• 必须呈现相互矛盾的信号，不得将其平均后合并为单一评分。
• 健康状况/风险记录须包含每个信号的置信度和来源。

升级决策必须经过人工判断

• 每个升级触发条件都须由人工决策后才能采取任何行动。
• 升级路径须明确由谁基于哪些证据、从哪些选项中作出决策。
• “未作出决策”状态须设定明确的后续措施——进一步升级，而非自动行动。

客户数据的隐私边界

• 与客户身份相关的数据不得嵌入共享给 CS 团队以外人员的模板中。
• 在团队间共享健康状况证据时，应使用匿名化或汇总后的信号。
• 数据保留和访问权限由产品的隐私政策管理，而非由 CS 实践决定。

有关完整边界说明，请参见 references/privacy-and-human-judgment.md。

路由与相关技能

此技能将请求路由到专业技能，而非重新推导其方法。所有路由引用均使用指向现有目录的相对路径；对于尚未落地的技能，则使用文字说明。

路由至（现有技能）

技能	所属职责	本技能如何使用
../product-analytics-and-measurement/SKILL.md	指标树、跟踪计划、埋点 QA、度量治理	为健康度／风险记录提供健康状况证据和指标定义
../product-adoption/SKILL.md	入门引导、激活、行为改变、功能发现、持续使用	将采用情况信号（激活、功能采用、持续使用）作为健康度维度
../product-experimentation/SKILL.md	实验设计、结果解读、发布／不发布决策	当客户成功证据表明需要实验时使用（例如，对有风险账户进行干预测试）
../go-to-market/SKILL.md	获客活动、营销转化	不负责此项。客户成功仅使用获客背景信息。
../crm/SKILL.md	HubSpot CRM 操作——联系人记录、交易渠道视图、已确认的交易阶段变更	为健康度／风险记录和 QBR 准备提供账户记录以及渠道／健康状况背景信息

路由至（正文引用——尚未落地的技能）

技能	所属职责	本技能如何路由至该技能
product-lifecycle-learning	退役沟通计划、产品停售期间的客户处理、迁移支持协调、跨产品组合的流失模式学习	在健康状况持续恶化（2 次以上补救尝试失败）时升级处理，以采取生命周期行动。将流失和停售信号转交该技能，用于产品组合层面的学习。

不负责

• 统计推断或实验设计——由 data-scientist 和 product-experimentation 负责。
• 产品分析埋点——由 product-analytics-and-measurement 负责。
• 获客、营销转化或活动设计——由 go-to-market 负责。
• 产品路线图或产品组合优先级排序——由 product-roadmapping-and-portfolio 负责。
• 客户支持运营或工单管理——由支持工具类技能负责。
• 合同谈判、定价或法律条款——由 go-to-market 和法律策略类技能负责。

文件索引

文件	用途	加载时机
references/discovery-brief.md	梳理现有相关内容、职责边界和路由决策	首次加载——必需的背景信息
references/privacy-and-human-judgment.md	完整的隐私与人类判断边界、监控风险指南、同意框架	出现隐私或判断相关问题时
templates/applicability-decision.md	结构化适用性评估——根据证据决定拒绝或继续	考虑将客户成功方法应用于任何产品时
templates/success-plan.md	客户成功计划，包含预期成果、里程碑和证据关卡	制定或审查成功计划时
templates/health-risk-record.md	基于证据的健康度／风险记录，包含信号、来源、趋势、置信度及相互冲突的信号跟踪	进行健康度评审、准备 QBR 或分析续约风险时
templates/escalation-and-feedback-closure.md	升级路径定义和闭环反馈记录	设计升级流程或运行反馈闭环时

QBR 和互动节奏

季度业务回顾（QBR）结构

QBR 是一次证据审查，而不是销售演示。其结构如下：

1. 成功计划回顾 — 对照预期成果检查进度和里程碑达成情况。
2. 健康度证据 — 列出每个维度及其信号、趋势和置信度。呈现相互矛盾的信号，不取平均值。
3. 采用情况证据 — 功能采用情况、激活趋势、持续使用模式（基于产品采用情况证据）。
4. 风险审查 — 未解决的风险、缓解状态、升级历史。
5. 后续计划 — 调整下一周期的成功计划、扩展机会（转交市场团队推进商务流程），以及风险缓解行动。
6. 反馈闭环状态 — 未处理的反馈项、已做出的产品决策、向客户反馈的状态。

在 B2B 订阅模式之外触发 QBR

对于非订阅模式，QBR 由事件触发，而非由日历日期触发：

模式	QBR 触发条件
交易型	达到购买里程碑阈值、账户等级变更或闲置 6 个月
公共服务	服务审查周期、发现公平性差距或无障碍审计结果
内部产品	内部服务审查周期、团队重组或采用率下降

输出约定

1. 在应用任何 CS 方法之前，记录一项适用性决策。
2. 制定一份成功计划，包含预期成果、里程碑、证据关卡，以及指定的关系负责人。
3. 创建一份健康度/风险记录，列出每个维度的证据，而非评分。
4. 制定一条升级路径，明确标出需要人工判断的关卡。
5. 创建一份闭环记录，追踪客户洞察 → 产品决策 → 客户沟通。
6. 创建交接至产品、支持或工程团队的交接记录，包含账户背景和证据。