详细章节：基础概念与商品主数据

01 基础概念与商品主数据

本章面向刚进入云商品领域的新人和商品产品经理，目标是先建立一套稳定的“术语地图”和“主数据地图”：知道一个技术能力如何被定义成产品，如何进一步成为可售、可订购、可计量、可开票、可续约的云商品。

读完本章，你应该能做到：

• 区分能力、产品、商品、商品主对象、售卖方案、可购买规格、计量项、价格规则、权益规则、订阅关系。
• 判断一个技术能力是否已经具备产品化条件，而不是直接进入上架。
• 画出基础商品主数据模型，并说明每类数据由谁维护、被谁消费。
• 理解主数据治理、字段血缘和变更审批为什么是商品平台的核心能力。
• 设计基础 售卖方案、可购买规格、计量项、价格规则 关系，并识别互斥、叠加、折扣和账单风险。
• 理解 Plan 型产品的权益发放、消耗、过期、退款、超额和账单解释规则。

本章不讨论完整生命周期、上市打法、稳定性保障 门禁和经营复盘的全部细节，只聚焦商品成立之前和成立之初最关键的主数据基础。

1. 基础概念

云商品工作中最常见的混乱，是把“技术能力、产品、商品、套餐、规格、价格、权益”混成一件事。新人要先记住：云商品不是一个展示页，也不是一张报价表，而是一组能驱动购买、交付、计量、账单和服务解释的业务对象。

1.1 关键概念解释

1.2 必须建立的关系感

• 能力不等于产品：API 能调用，不代表有客户定位、服务等级承诺、成本、交付和售后解释。
• 产品不等于商品：产品定义清楚后，还要有 售卖方案、可购买规格、计量项、价格规则、权益和上架渠道，客户才可以买。
• 售卖方案 不是 可购买规格：售卖方案 是售卖包装，例如按量、包月、资源包；可购买规格 是购买规格，例如 Medium、Pro 或 2C4G。
• 计量项 不是 价格规则：计量项 记录用量，价格规则 把用量、周期、折扣和合同规则转换成金额。
• 官网不是主数据源：官网只是渠道投影，真正源头应是商品中台或产品定义系统。

1.3 新人理解路径

建议用一句话串起来：

我们先把技术能力定义成产品，再把产品包装成 商品主对象 和 售卖方案，拆成 可购买规格，指定 计量项 和 价格规则，最后用 权益规则 和 订阅关系 管住客户买后能用什么。

如果这句话中的任意对象没有定义清楚，后续通常会出现四类问题：销售解释不一致、客户购买不清楚、账单对不上、售后无法判断责任。

2. 产品化定义前置

产品化定义前置，是为了避免“技术能力刚能跑，就被包装成商品卖出去”。云商品 产品经理 的第一项责任不是填后台字段，而是判断这个能力是否已经具备产品条件。

2.1 产品化 就绪评审 要回答的问题

1. 目标客户是谁：中小自助客户、大客户、内部客户、开发者、行业客户是否不同？
2. 核心场景是什么：训练、推理、存储、分发、生成、分析、办公协作，场景越模糊，商品越难卖。
3. 能力边界是什么：支持哪些地域、并发、模型版本、数据格式、实例规格？不支持什么？
4. 交付方式是什么：控制台自助、API、销售开通、工单交付、专属部署还是混合模式？
5. 服务等级承诺 能否承诺：可用性、延迟、交付时效、容量保障是否有 稳定性保障 背书？
6. 成本能否测算：GPU、存储、带宽、模型推理、第三方服务、人工支持成本是否可估？
7. 合规和法务边界是什么：数据、内容安全、地域、合同、退款、禁承诺项是否明确？
8. 售后能否解释：客户问“为什么扣费、为什么失败、为什么不能买”时是否有口径？

2.2 关键交付物

• 产品化 就绪评审 结论：通过、带条件通过、退回补齐。
• 产品定义草稿：客户、场景、价值、边界、版本、依赖。
• 能力边界和不可承诺项：尤其是地域、容量、时延、效果、模型输出、安全合规。
• 服务等级承诺 初稿：哪些指标可承诺，哪些只能作为参考。
• 成本测算输入：单位成本、峰值成本、免费额度成本、折扣空间。
• 交付物清单：控制台、API、文档、工单、客服话术、销售材料。

2.3 工作步骤

1. 收集能力信息：让研发、算法或资源团队说明当前能力状态、限制和依赖。
2. 定义客户与场景：产品经理 明确首批目标客户和高频使用路径，不追求覆盖所有场景。
3. 拆解承诺与不可承诺：把销售容易承诺但系统未准备好的内容提前列出。
4. 拉齐成本和稳定性：财务 BP 给成本底线，稳定性保障 给容量和 服务等级承诺 边界。
5. 形成产品化结论：只有当客户、场景、边界、成本、服务等级承诺 和交付方式基本成立，才进入商品建模。

2.4 角色分工

2.5 常见风险

• 技术能力冒充产品：只有接口，没有客户定位、服务等级承诺、成本和售后路径。
• 不可承诺项后置：销售已经卖出，才发现地域、容量、效果或合规无法承诺。
• 成本未穿透：免费额度、促销价或高成本模型调用导致毛利被打穿。
• 交付方式不清：客户下单后不知道是自动开通、工单开通还是销售跟进。
• 文案过度营销：官网宣传与合同、服务等级承诺、账单解释不一致。

2.6 产品化小案例

Seedance Mini 如果目前只是一个视频生成模型能力，产品经理 不能直接把它放到控制台售卖。需要先确认：支持哪些分辨率和时长、生成失败是否扣费、队列拥塞如何处理、是否需要内容安全审核、单位生成成本是多少、客户能否自助购买资源包、官网效果示例是否代表正式承诺。

ECS GPU 训练实例 如果要成为商品，需要确认：GPU 型号、地域、库存、实例规格、交付时效、容量预约、包月和按量成本、服务等级承诺、故障赔付、销售是否能承诺固定交付日期。

3. 商品主数据模型

商品主数据模型是云商品平台的骨架。它不是单纯为了后台录入，而是为了让官网、控制台、销售报价、合同、订单、计量、账单、发票、客服和经营看板使用同一套可信来源。

3.1 核心实体

3.2 每个实体都要补齐的元信息

产品经理 不应只问“字段填了没有”，而要问：

• 业务定义：这个字段用业务语言怎么解释？
• 主键和展示字段：系统识别用什么，客户或运营看到什么？
• 维护方：谁有权修改？谁审批？
• 消费方：哪些系统读取它？官网、控制台、报价、账单是否都用？
• 生效规则：立即生效、灰度生效、下个计费周期生效还是合同续约后生效？
• 客户可见性：哪些字段能展示给客户，哪些只能内部使用？
• 变更影响：修改后会影响哪些存量订单、合同、账单和渠道？

3.3 主数据示例：Agent Plan Medium

一个 Agent Plan Medium 不能只建一个“Medium 套餐”名称，至少要拆成：

• 商品主对象：Agent 企业助手。
• 售卖方案：包月套餐 售卖方案、试用 售卖方案、超额付费 售卖方案。
• 可购买规格：Medium、Pro、Enterprise 等档位。
• 计量项：Token 消耗、联网搜索次数、视频生成秒数或任务数。
• 价格规则：包月目录价、企业合同价、促销价、超额单价。
• 权益规则：每日赠送额度、席位数、功能权限、额度有效期。
• 订阅关系：某客户购买 Medium 后的生效周期、剩余额度、续约状态。

3.4 主数据字段展示原则

• 对客户展示业务语言，不展示工程 key。例如展示“每日赠送额度”，不要展示 daily_free_quota。
• source、演示、confidence 等数据边界字段可以保留在内部，但对外应转写为“演示数据”“估算假设”“置信度”。
• 价格字段要明确是目录价、参考价、估算价、促销价、合同价还是正式报价。
• 权益字段要能回答客户最关心的问题：买了有什么、什么时候生效、何时过期、能否退款、用完后怎么办。

4. 主数据治理与血缘

商品平台之所以叫“中台”，不是因为它有很多表单，而是因为它要为多个渠道和系统提供一致、可追溯、可审批的主数据。主数据治理的核心问题是：字段从哪里来、谁能改、谁在用、改了影响谁。

4.1 治理要回答的五个问题

1. 谁是主数据源：价格来自财务系统还是商品中台？地域来自资源系统还是 产品经理 手填？
2. 字段归属方是谁：服务等级承诺 文案归 稳定性保障 和法务，毛利底线归财务，规格参数归研发和资源团队。
3. 下游系统怎么消费：官网、控制台、API/云市场、销售报价、合同、账单是否读取同一字段？
4. 变更影响哪些对象：新客户、存量客户、合同、订阅、账单、发票、渠道页面是否受影响？
5. 是否需要审批后生效：价格、计费模式、权益额度、地域可售、服务等级承诺 文案必须有审批和审计。

4.2 关键交付物

• 主数据血缘图：展示 商品主对象、售卖方案、可购买规格、计量项、价格规则、权益规则 到下游系统的流向。
• 字段归属矩阵：每个字段的 owner、审批人、维护入口和生效规则。
• 下游消费系统清单：官网、控制台、报价、合同、订单、计量、账单、客服、经营看板。
• 字段变更影响分析：说明影响客户、合同、账单、渠道和风险。
• 主数据完整性校验报告：缺字段、错字段、过期字段、渠道不一致。
• 渠道一致性检查报告：官网、控制台、销售报价和 API 输出是否一致。

4.3 角色分工

4.4 高风险字段

以下字段不能随意修改，必须有审批、灰度、通知和审计：

• 计费模式：按量改包月、包月改资源包，会影响订购、合同和账单。
• 价格：目录价、阶梯价、合同价、促销价、超额单价。
• 权益额度：每日赠送额度、资源包总量、席位数、功能权限。
• 地域可售：地域上线、下线、库存不足、容量预约。
• 服务等级承诺 和交付承诺：可用性、赔付、交付日期、性能指标。
• 退款和退订规则：是否退未消耗金额、赠送权益如何处理。

4.5 工作步骤：一次字段变更怎么做

1. 提出变更：说明变更字段、原因、期望生效时间。
2. 查血缘：列出消费该字段的所有系统和渠道。
3. 做影响分析：区分新购客户、存量订阅、合同客户、试用客户。
4. 生成审批摘要：给财务、稳定性保障、法务、销售或负责人审批。
5. 灰度或定时生效：避免立即影响全部客户。
6. 渠道同步检查：官网、控制台、报价单、API、客服话术同步。
7. 发布后巡检：看订单、计量、账单和客户反馈是否异常。

4.6 常见风险

• 官网文案已改，但控制台价格未改，导致客户质疑。
• 销售报价使用旧 可购买规格，订单系统已下线，导致合同无法履约。
• 权益额度在控制台展示更新，但权益系统仍按旧规则发放。
• 财务已批准促销价，但账单系统未接入促销规则。
• 字段没有审计记录，出现账单争议时无法还原谁在什么时候修改。

5. 售卖方案 / 可购买规格 / 计量项 / 价格规则 设计

售卖方案、可购买规格、计量项、价格规则 是云商品商业包装的核心。设计时不能只问“客户愿不愿意买”，还要问“系统能不能计量、账单能不能解释、销售能不能报价、财务能不能确认收入、客服能不能处理争议”。

5.1 四者关系

• 售卖方案：怎么卖。例如按量、包月、资源包、企业套餐、试用包、超额付费。
• 可购买规格：买哪档。例如 Small、Medium、Large，或 2C4G、4C8G。
• 计量项：按什么记录用量。例如 Token、实例小时、GB、请求次数、生成秒数。
• 价格规则：如何算钱。例如固定月费、单价、阶梯价、资源包抵扣价、合同折扣价。

一个 商品主对象 可以有多个 售卖方案；一个 售卖方案 可以包含多个 可购买规格；一个 可购买规格 可能关联一个或多个 计量项。需要特别注意：价格规则 通常不是只绑定 计量项，而是在具体售卖上下文中生效的价格规则，会同时受 商品主对象、售卖方案、可购买规格、计量项、可售地域、计费周期、币种/税费、客户合同、生效时间、承诺消费和资源包抵扣规则影响。计量项 记录“用量事实”，价格规则 在具体上下文中把用量、权益和合同条件转换成金额。

5.2 常见 售卖方案 类型

5.3 设计步骤

1. 从客户购买心理出发：客户是想低门槛试用、锁定预算、获得折扣，还是获得稳定交付？
2. 确定 售卖方案 组合：不要一开始设计过多 售卖方案，先覆盖主路径，再扩展资源包、试用和企业套餐。
3. 拆 可购买规格：可购买规格 要能表达规格差异，也要能被交付系统和账单系统识别。
4. 定义 计量项：计量项 必须可采集、可校验、可追溯，不能只是营销口径。
5. 定义 价格规则：明确目录价、折扣价、促销价、合同价和超额价的优先级。
6. 设计互斥和叠加规则：资源包、促销价、合同折扣、赠送额度是否能同时使用。
7. 做正式报价前检查：价格、税费、合同、服务等级承诺、容量和交付窗口是否确认。

5.4 互斥和叠加规则示例

以 Seedance Mini 为例，可能存在按量、资源包、促销价和合同折扣。产品经理 必须明确：

• 资源包是否优先抵扣按量消耗？
• 促销价是否仅适用于新购，不适用于续费？
• 合同折扣能否叠加促销价？
• 资源包过期后是否自动转为按量计费？
• 生成失败是否计入消耗？如果不计入，计量系统如何识别失败？
• 客户预算估算是否可以被销售当成正式报价？答案通常是否定的。

5.5 常见风险

• 售卖方案 过多：客户选择困难，销售难解释，系统规则复杂。
• 可购买规格 只服务营销：规格名称好看，但无法映射到真实交付能力。
• 计量项 不可审计：客户质疑账单时无法提供证据链。
• 价格规则 优先级不清：合同价、促销价、资源包抵扣重复叠加。
• 退款规则缺失：资源包未消耗金额、赠送额度、合同折扣无法处理。
• 报价边界混乱：估算价、参考价、目录价、正式报价被混用。

6. Plan 型产品与权益治理

Plan 型产品包括套餐、会员、企业版、按席位订阅等。它比单品型云商品复杂，因为客户买到的不是一个单一资源，而是一组额度、功能、有效期、权限、赠送和超额规则。

6.1 Plan 必须回答的问题

• 每天、每月或每个周期什么时候发放权益？
• 未用完额度是否过期？过期前是否提醒？
• 退订后是否还能继续使用已发放权益？
• 退款时赠送权益、已消耗权益和未消耗权益如何处理？
• 合同折扣、促销价、赠送额度能否叠加？
• 超额后是否自动扣费？是否需要管理员二次确认？
• 多个资源包或套餐同时存在时，消耗顺序是什么？
• 账单中如何解释赠送、抵扣、消耗、过期和超额？

6.2 关键交付物

• 权益规则表：权益类型、额度、周期、有效期、适用 可购买规格、客户可见说明。
• 额度发放规则：发放时间、发放对象、失败重试、补发机制。
• 消耗顺序规则：赠送额度、资源包、合同额度、按量扣费的优先级。
• 过期、退订、退款规则：权益冻结、回收、保留、补偿和财务处理。
• 超额付费确认页：客户管理员确认、预算提醒、是否自动续费。
• 账单解释模板：如何展示赠送、消耗、抵扣、过期和超额。
• Plan 毛利穿透分析：高成本能力、免费额度和促销对毛利的影响。

6.3 角色分工

6.4 Agent Plan Medium 示例

假设 Agent Plan Medium 的营销文案是“每天赠送 50 元等值 Token”。这句话背后至少要落成以下规则：

• 发放对象：购买 Medium 且订阅处于有效状态的客户组织。
• 发放时间：每天 0 点发放，失败后重试，补发需要审计。
• 有效期：当天有效、月底有效，还是订阅期内有效，必须明确。
• 消耗顺序：先消耗每日赠送 Token，再消耗资源包，最后进入超额付费。
• 超额规则：默认不自动扣费，客户管理员需要二次确认并设置预算上限。
• 退订规则：退订立即停止新权益发放；已发放未使用权益是否保留需写清。
• 退款规则：已消耗权益、赠送权益和现金购买权益要分开处理。
• 账单解释：展示“赠送额度抵扣”“资源包抵扣”“超额付费”三类明细。

6.5 常见风险

• 营销话术过度简化：“每天送 50 元”没有说明有效期、消耗顺序和超额规则。
• 默认自动扣费：客户以为套餐用完就停止，实际自动按量扣费，引发争议。
• 免费额度成本失控：高成本模型、联网搜索、视频生成被大量免费使用，毛利被打穿。
• 退订和退款不清：权益已发放但未消耗，财务和客服无法判断怎么处理。
• 客户看不懂账单：客户只看到扣费金额，看不到赠送抵扣和消耗依据。
• 多套餐叠加混乱：客户同时有会员、资源包和合同额度，消耗顺序不透明。

7. 综合工作流、案例与练习

7.1 从能力到主数据的标准工作流

1. 能力识别：确认技术能力、资源能力或模型能力是否稳定存在。
2. 产品化评审：补齐客户、场景、边界、服务等级承诺、成本和交付方式。
3. 建立 商品主对象：定义商品名称、产品族、描述、负责人、状态和客户可见口径。
4. 设计 售卖方案：选择按量、包月、资源包、试用、企业套餐或超额付费。
5. 拆分 可购买规格 和 Spec：把客户可购买档位映射到真实交付规格。
6. 定义 计量项：明确用量采集方式、口径、单位、精度和审计证据。
7. 定义 价格规则：确定目录价、阶梯价、促销价、合同价、超额价和优先级。
8. 定义 权益规则：明确权益发放、消耗、过期、退订、退款和超额规则。
9. 建立血缘和审批：确认字段 owner、下游系统、审批人、生效时间和回滚方案。
10. 渠道投影检查：官网、控制台、报价、合同、账单和客服话术保持一致。

7.2 案例 A：ECS GPU 包月商品

• 商品主对象：GPU 训练实例。
• 售卖方案：包月 售卖方案、按量 售卖方案、企业容量预约 售卖方案。
• 可购买规格：A10 1 卡、A100 4 卡、H 系列 8 卡等规格。
• 计量项：实例小时、GPU 小时、存储 GB、带宽流量。
• 价格规则：包月目录价、按量单价、大客户合同折扣。
• 权益规则：实例使用权、地域可用范围、服务等级承诺、容量预约权益。
• 关键风险：新加坡等地域容量不足时，不能承诺固定交付日期；折扣不能突破毛利底线；GPU 故障和 服务等级承诺 赔付要有法务口径。

练习：如果销售提出给金融客户 30 万预算的 GPU 训练方案，产品经理 应列出哪些 售卖方案、可购买规格、价格、地域和 服务等级承诺 检查项？

7.3 案例 B：Seedance Mini 资源包

• 商品主对象：视频生成服务。
• 售卖方案：按量 售卖方案、资源包 售卖方案、促销 售卖方案。
• 可购买规格：基础版、高清版、批量生成版。
• 计量项：生成秒数、生成次数、分辨率倍率、失败任务标识。
• 价格规则：按量单价、资源包折扣价、促销价、合同价。
• 权益规则：资源包余额、有效期、失败不扣费规则、内容安全限制。
• 关键风险：估算不等于正式报价；资源包和促销折扣不能无边界叠加；生成失败是否扣费要在计量和客服话术中一致。

练习：请设计 Seedance Mini 的资源包抵扣顺序，并说明合同折扣是否可以叠加促销价。

7.4 案例 C：Agent Plan 套餐权益

• 商品主对象：企业 Agent 套餐。
• 售卖方案：包月套餐、试用包、超额付费。
• 可购买规格：Small、Medium、Enterprise。
• 计量项：Token、联网搜索次数、工具调用次数、视频生成任务。
• 价格规则：月费、年费、合同折扣、超额单价。
• 权益规则：每日赠送额度、席位数、功能权限、超额二次确认。
• 关键风险：免费额度成本、自动扣费争议、退订退款口径、账单解释复杂。

练习：Agent Plan Medium 额度用完后，系统应该直接扣费、停止服务还是提示管理员确认？请写出你选择的规则和客户提示文案。

8. 产品经理 总检查清单

8.1 产品化检查

• [ ] 目标客户和核心场景已明确。
• [ ] 能力边界和不可承诺项已写清。
• [ ] 服务等级承诺、容量、地域和交付窗口已由 稳定性保障 确认。
• [ ] 成本输入和毛利底线已由财务确认。
• [ ] 法务和合规风险已识别。
• [ ] 客户买前、买后、账单和售后解释路径已准备。

8.2 主数据检查

• [ ] 商品主对象、售卖方案、可购买规格、Spec、计量项、价格规则、权益规则 已建模。
• [ ] 每个字段有业务说明、owner、维护入口和审批规则。
• [ ] 客户可见字段和内部字段已区分。
• [ ] 工程 key 不会直接展示给客户。
• [ ] 官网、控制台、报价、合同、订单、计量、账单消费口径已确认。
• [ ] 价格、权益、地域、服务等级承诺 等高风险字段有审计记录。

8.3 售卖方案 / 可购买规格 / 计量项 / 价格规则 检查

• [ ] 售卖方案 类型与客户购买路径匹配。
• [ ] 可购买规格 能映射到真实交付规格。
• [ ] 计量项 可采集、可校验、可追溯。
• [ ] 价格规则 明确目录价、促销价、合同价、超额价和优先级。
• [ ] 折扣、资源包、促销和合同价的互斥/叠加规则已定义。
• [ ] 退款、退订、降级、续费和过期规则已确认。

8.4 Plan 权益检查

• [ ] 权益发放时间、对象、周期和失败补发规则已定义。
• [ ] 消耗顺序、过期规则、退订规则和退款规则已定义。
• [ ] 超额付费默认需要客户管理员二次确认，或已明确例外依据。
• [ ] 免费额度和高成本能力已经做毛利穿透分析。
• [ ] 账单能解释赠送、抵扣、消耗、过期和超额。
• [ ] 客服和客户成功已有争议处理话术。

8.5 本章自测题

1. 为什么说 售卖方案 不是 可购买规格？请用一个包月套餐举例。
2. 计量项 和 价格规则 分别解决什么问题？为什么不能合并理解？
3. 如果 售卖方案 的计费模式从按量改为包月，会影响哪些下游系统？
4. Seedance Mini 官网介绍页、控制台购买页和销售报价单分别应该消费哪些主数据？
5. Agent Plan 的每日赠送额度调整，会影响哪些权益、账单、财务和客户体验问题？
6. 一个字段从“内部估算”变为“客户可见报价”，需要经过哪些检查？

8.6 新人完成本章后的产出

完成本章学习后，建议独立产出三份练习文档：

• 一份产品化定义草稿：选择一个能力，写清客户、场景、边界、服务等级承诺、成本和交付方式。
• 一份商品主数据草稿：画出 商品主对象、售卖方案、可购买规格、计量项、价格规则、权益规则 关系。
• 一份权益治理规则：选择一个 Plan，写清额度发放、消耗、过期、退订、退款和超额确认。

详细章节：生命周期、渠道发布与上市打法

生命周期、渠道发布与 上市打法 工作手册

本章面向云商品新人和产品经理，聚焦产品生命周期全流程、渠道发布与上下游协同、上市打法、销售方案与客户成交。

1. 本章使用方式

本章把大纲中的第 7、8、9 章合并成一套可执行工作手册：先判断产品能不能卖，再组织上架发布，最后用 上市打法 和销售方案把商品带到客户成交场景里。

新人阅读时请抓住三条主线：

• 生命周期主线：能力识别 → 产品化定义 → 商品化建模 → 审查 → 发布 → 灰度 → 验证 → 复盘 → 续约/扩容/下线。
• 渠道协同主线：同一套商品主数据，被官网、控制台、API/云市场、销售报价、客服话术以不同方式展示。
• 成交主线：上市打法 定义目标客户和卖点，销售识别预算和决策链，解决方案组合产品，财务/稳定性保障/法务守住报价、交付和承诺边界。

使用本章时，不要把它当成“上架流程说明”。正确用法是：每推进一个商品，都按阶段作业卡检查输入、输出、负责人和阻塞处理；每准备对外发布，都用渠道矩阵和报价前检查清单核对；每进入客户沟通，都先确认客户分层和禁承诺项。

2. 产品生命周期全流程

云商品生命周期不是单向流水线，而是多角色反复校准的闭环。标准流程如下：

1. 产品能力识别：判断一个技术能力、资源能力或服务能力是否具备商业化潜力。
2. 产品化定义：明确目标客户、核心场景、能力边界、服务等级承诺 初稿、交付物和不可承诺项。
3. IPD 立项和 产品需求文档：把机会变成正式产品项目，形成需求范围、里程碑和验收口径。
4. 商业测算：测算成本、目录价、折扣空间、毛利底线和收入确认风险。
5. 商品模型设计：定义 商品主对象、售卖方案、可购买规格、计量项、价格规则、可售地域、权益规则 等主数据。
6. 售卖方案 / 可购买规格 / 计量项 / 价格规则 设计：确定按量、包月、资源包、企业套餐、试用包等售卖方式。
7. 权益和合同规则设计：定义额度发放、消耗顺序、过期、退订、退款、超额付费和合同边界。
8. 稳定性保障 上架门禁：确认容量、限流、告警、灰度比例、回滚触发条件和可承诺 服务等级承诺。
9. 法务和合规审查：确认营销文案、合同条款、服务等级承诺、隐私、安全和地域合规边界。
10. 上市打法 和销售 enablement：准备目标客户分层、行业场景、卖点、常见问题说明、禁承诺项、销售话术和 battlecard。
11. 渠道发布：同步官网、控制台、API/云市场、销售资料、客服话术等渠道。
12. 灰度上线：按客户、地域、流量、可购买规格 或渠道范围逐步开放。
13. 订单、交付、计量、账单验证：验证客户能买、能开通、能使用、能计量、能出账、能解释。
14. 发布后巡检：上线后 24 小时内检查渠道一致性、订单闭环、计量账单、告警、客户反馈。
15. 经营复盘和版本迭代：看 成交规模、净收入、毛利、活跃客户、转化率、投诉、稳定性和销售反馈。
16. 续约、扩容、下线或替换：进入生命周期后半段，处理续约机会、扩容需求、存量迁移和商品下线。

判断某个阶段是否完成，不能只看“表单是否提交”。必须看四件事：输入是否齐、输出是否可被下游消费、负责人是否确认、阻塞是否有明确处理路径。

3. 阶段作业卡：输入、输出、负责人、阻塞处理

工作原则：任何高风险动作都先形成草稿、模拟计划或审批摘要，不能直接生产变更；任何对外承诺都必须能回连到产品定义、稳定性保障、财务和法务依据。

4. 渠道发布与上下游协同

渠道发布的核心不是“把内容复制到多个地方”，而是让不同渠道消费同一套主数据，并按各自场景做正确投影。

4.1 上游协同

• 产品/研发/算法/资源团队：提供能力边界、规格参数、计量口径、地域限制、版本依赖。
• 稳定性保障：提供容量、限流、告警、灰度、回滚、服务等级承诺 可承诺范围。
• 财务 BP：提供成本、价格、折扣、毛利、收入确认、资源包递延规则。
• 法务/合规：提供合同边界、隐私安全、合规材料、禁止承诺表述。
• 上市打法/运营：提供行业场景、核心卖点、常见问题说明、活动节奏和销售 enablement 材料。

4.2 下游协同

• 官网：用于公开介绍和获客，展示客户能理解的卖点、场景、价格入口和 常见问题说明。
• 控制台：用于自助购买、配置、用量查看、账单查看，字段必须与计量、权益和账单一致。
• API / 云市场：用于生态销售、自动化订购和第三方集成，需要稳定接口、上架资料和可售状态。
• 销售解决方案：用于大客户售前、报价、方案包和合同协同，可以组合但不能突破审批边界。
• 客服/客户成功：用于解释账单、处理争议、续约和健康度跟进，必须拿到客户友好话术。

4.3 渠道一致性原则

• 官网不是主数据源，商品中台/商品定义才是源头。
• 控制台购买页必须与价格、计量、权益、账单一致，否则客户买后一定会产生争议。
• 销售方案可以有定制组合，但正式报价前必须经过财务、稳定性保障、法务边界检查。
• 内部字段、成本字段、演示/演示/source/confidence 等不能直接对客户展示，需要转写为客户可理解语言。
• 渠道发布后必须做巡检：同一个 可购买规格、价格、地域、权益、服务等级承诺，在官网、控制台、销售报价和客服话术中不能互相矛盾。

5. 渠道矩阵

渠道发布的最低完成标准

• 每个渠道都有明确 owner，不允许“默认由 产品经理 同步所有渠道”。
• 每个渠道都能说明字段来源和审批状态。
• 客户可见内容必须区分：正式报价、估算、演示数据、参考价格、合同价。
• 发布后至少完成一次端到端巡检：官网入口 → 控制台购买 → 订单生成 → 权益开通 → 用量计量 → 账单展示 → 客服解释。

6. 上市打法 与销售方案

上市打法 的任务是把“商品能卖”转成“客户愿意买、销售知道怎么卖”。销售方案的任务是把客户预算、场景和约束，转成可报价、可交付、可签约的组合。

6.1 上市打法 必备内容

• 目标客户分层：大客户、中型客户、小客户/自助客户、行业客户、生态伙伴。
• 行业场景：金融、内容、电商、游戏、教育、制造等客户为什么需要这个商品。
• 核心卖点：用客户语言表达，不要只写技术参数。
• 竞品边界与行业竞争力：哪些场景我们有优势，哪些场景不要硬卖；对标客户常见替代方案、竞品价格包装、行业案例、迁移成本和差异化证据。
• 套餐组合：单品、资源包、企业套餐、试用包、超额包如何搭配。
• 常见问题说明：价格、交付、服务等级承诺、地域、账单、退款、超额、续约等常见问题。
• 销售禁承诺项：销售不能承诺的交付日期、效果、容量、折扣、合规结论。
• 正式报价前检查清单：确保报价不是口头估算。
• 云市场 与伙伴运营：如果通过云市场、生态伙伴或分销渠道售卖，要补充伙伴分佣、渠道价格一致性、上架材料、客户归属、售后责任和渠道经营指标。

6.2 销售方案必须回答的问题

• 客户预算是多少？预算是年度、季度还是项目制？
• 客户业务场景是什么？是生产核心链路、试点验证还是营销活动？
• 客户需要哪些地域、合规、审计、安全材料？
• 客户所在行业的竞品替代方案是什么？我们在价格、交付、稳定性、生态和案例上有什么可证明的竞争力？
• 客户需要什么 服务等级承诺？这个 服务等级承诺 是否被 稳定性保障 和法务确认？
• 产品组合如何拆分？主商品、配套商品、服务支持分别是什么？
• 预算如何拆到不同商品、资源包、服务和折扣？
• 报价假设是什么？哪些用量、地域、周期、并发、容量是假设？
• 风险和边界是什么？哪些内容不能写进合同或邮件承诺？
• 下一步动作是什么？谁跟客户确认需求，谁出正式报价，谁拉审批？

6.3 大客户与自助客户差异

• 大客户通常需要方案、合同、发票、审计、服务等级承诺、容量预约和折扣审批；推进节奏由销售和解决方案牵引。
• 自助客户更关注购买简单、价格清晰、额度好理解、账单能解释、用完是否自动扣费；体验由控制台和客服话术决定。
• 续约客户更关注稳定性、账单争议、用量健康和升级/降级空间；客户成功要把风险反馈给 产品经理。

7. 销售报价前检查

销售报价前必须区分三类输出：

• 预算估算：基于假设帮助客户判断大概费用，不能作为正式承诺。
• 报价草稿：销售/售前准备的方案，需要财务、稳定性保障、法务等审批。
• 正式报价：经过审批，可进入合同、订单或采购流程的价格和条款。

报价前检查清单

报价材料必须写明“有效期、适用地域、适用 可购买规格、计费周期、用量假设、是否含税、是否包含折扣、是否包含赠送额度、超额处理方式”。没有这些字段的报价，默认只能视为草稿。

8. 客户分层与禁承诺项

8.1 客户分层

8.2 禁承诺项

销售、上市打法、产品经理 在客户沟通中不得承诺以下内容，除非已经取得对应审批并能落入合同或正式报价：

• 未确认交付日期：例如“下周一定能开通新加坡 GPU 容量”。必须以 稳定性保障 确认的交付窗口为准。
• 未批准 服务等级承诺：例如“绝不会失败”“100% 可用”。只能使用批准后的 服务等级承诺 文案。
• 效果保证：例如“模型一定达到某准确率/转化率/播放量”。可以说明测试结果和适用条件，不能保证客户业务结果。
• 无限容量或无限额度：云资源、模型调用、队列并发都受容量、限流和成本约束。
• 自动折扣或永久低价：折扣要受财务和毛利边界约束，合同价也有有效期。
• 免费额度永不过期：赠送额度、试用额度、资源包都有发放、过期、退订和退款规则。
• 超额自动可用且不收费：超额付费应有客户管理员确认；不应默认自动扣费且不告知。
• 合规已经满足：隐私、安全、跨境、行业监管材料必须由法务/合规确认。
• 功能路线图必然上线：路线图只能作为规划沟通，不能成为合同承诺，除非已进入正式交付范围。
• 估算就是正式报价：估算必须标注假设和非正式属性，正式报价需审批。

8.3 客户沟通建议话术

• 对交付：当前可承诺范围以正式报价、合同或交付确认中的地域、容量和交付窗口为准；未确认部分我们可以协助预约，但不能作为正式承诺。
• 对价格：这份是基于当前用量假设的预算估算，正式报价需要完成商品、财务和合同审批。
• 对额度：资源包/赠送额度有有效期和使用规则，超额是否继续付费需要管理员确认。
• 对效果：我们可以提供基准测试、案例和 PoC 方法，但实际业务效果取决于数据、场景和使用方式。

9. 产品经理 检查清单

9.1 产品化检查

• [ ] 目标客户、核心场景、首发范围已经明确。
• [ ] 能力边界和不可承诺项已经写入产品定义。
• [ ] 交付物、服务等级承诺 初稿、地域和容量限制已经确认。
• [ ] 研发/稳定性保障/财务/法务已对各自边界给出结论。
• [ ] 首发 MVP 与后续版本已经拆开，未上线能力没有进入对外承诺。

9.2 商品化检查

• [ ] 商品主对象、售卖方案、可购买规格、计量项、价格规则、可售地域、权益规则 已建模。
• [ ] 售卖方案 与 可购买规格、计量项、价格、权益、合同规则关系一致。
• [ ] 资源包、包月、按量、试用、企业套餐之间的互斥和叠加规则明确。
• [ ] 退款、退订、过期、超额、降级、升级规则明确。
• [ ] 高风险字段有字段 owner、审批人和变更影响分析。

9.3 发布检查

• [ ] 稳定性保障 就绪 checklist 已通过，灰度和回滚方案已确认。
• [ ] 法务/合规审查已通过，官网和销售文案无过度承诺。
• [ ] 官网、控制台、API/云市场、销售资料、客服话术已纳入渠道发布矩阵。
• [ ] 控制台购买、订单、开通、计量、账单、发票至少完成一轮验证。
• [ ] 发布后 24 小时巡检 owner、指标和升级路径已经确定。

9.4 上市打法 与销售检查

• [ ] 目标客户分层、行业场景、核心卖点和 常见问题说明 已准备。
• [ ] 销售禁承诺项已同步给销售、售前、客服和客户成功。
• [ ] 报价前检查清单已嵌入销售流程。
• [ ] 估算、报价草稿、正式报价在材料中有清晰区分。
• [ ] 重点客户方案中的容量、服务等级承诺、合规和折扣已完成相应审批。

9.5 发布后经营检查

• [ ] 成交规模、净收入、毛利、活跃客户、转化率、投诉和账单争议有监控。
• [ ] 发布问题有 owner、截止时间和复盘结论。
• [ ] 客户反馈能回流到产品定义、商品规则和销售话术。
• [ ] 续约、扩容、降级、下线和替换路径已经规划。

10. 常见阻塞处理速查

本章小结

生命周期协同的关键，不是把商品“发布出去”，而是确保产品定义、商品主数据、渠道展示、销售报价、交付能力、合同承诺和账单解释处在同一套事实之上。对新人和 产品经理 来说，最重要的工作习惯是：凡是对客户可见的内容，都要能追溯到主数据和审批依据；凡是跨团队阻塞，都要明确 owner、输出物和处理时限。

详细章节：财务商业化与运营治理

03 财务商业化与运营治理

本章依据 docs/cloud-commodity-workbook-outline.md 第 10-17 章扩写，面向产品经理解释财务、稳定性保障、客户成功与经营治理口径。

1. 本章定位与阅读方式

本章只讨论商品发布前后最容易被低估的治理问题：财务能不能算清楚、稳定性保障 能不能扛住、客户能不能买明白、异常能不能闭环、发布后是否健康、续约是否可预警、不同角色是否看同一套事实。

对产品经理来说，财务、稳定性保障、客户成功不是“审批部门”，而是把技术能力变成可持续商业商品的专业边界：

• 财务商业化回答：卖出去的钱是否能被确认成收入，扣除成本后是否有毛利，折扣和退款是否可控。
• 稳定性保障 上架门禁回答：商品能不能稳定交付，容量、限流、告警、灰度、回滚是否可执行。
• 客户成功回答：客户买前是否理解规则，买后是否解释得清，续约前是否能提前识别风险。
• 运营治理回答：正向销售、反向变更、异常事故、发布巡检和经营复盘是否有统一口径。

阅读本章时，建议始终用四个问题审视每个动作：

1. 这个动作影响哪些客户、合同、账单和渠道展示？
2. 是否影响收入确认、毛利、服务等级承诺 或续约？
3. 是否需要审批、灰度、回滚和客户通知？
4. 事后能否通过数据、日志、报表和客户沟通记录追溯？

2. 财务商业化与经营口径

2.1 产品经理必须理解的财务口径

云商品不是“有订单就算成功”。同一个商品在 成交规模、净收入、毛利、现金流和收入确认上的表现可能完全不同。

• 成交规模：订单或合同口径的成交规模，适合看市场声量和目标达成，但不能直接代表公司赚到的钱。
• 净收入：扣除退款、退订、补偿、渠道分佣等影响后的收入口径，更接近真实经营质量。
• 年度经常性收入 / 月度经常性收入：年度或月度经常性收入，适合看订阅型、包月型、企业套餐型商品的稳定盘。
• 毛利率：收入扣除直接成本后的盈利能力。AI 推理、GPU、联网搜索、视频生成等高成本能力尤其要看毛利。
• 销售机会池：还未成交但有机会转化的销售机会金额，不能等同收入。
• 资源包消耗率：客户购买的预付额度被消耗的进度，影响递延收入结转和续约判断。
• 账单争议金额：客户对账单不认可的金额，可能导致回款延迟、退款、续约风险和口碑损失。
• 收入确认风险：收款、开票、交付和消耗之间不一致时，财务不能简单把钱全部确认为收入。

产品经理要避免只汇报“卖了多少”。更健康的表达是：本月 成交规模、净收入、毛利率、有效 年度经常性收入、新增付费客户、资源包消耗率、账单争议金额、续约风险金额分别是多少，以及偏离原因是什么。

2.2 不同商业模式的收入确认解释

• 按量付费：客户实际用多少，按计量记录和价格规则生成账单。风险在于计量延迟、计量缺失、重复计量、客户不理解单位换算。
• 包月 / 包年：客户购买一段时间内的固定权益或规格。收入通常需要按服务期分摊，不能只看一次性收款；实际确认口径仍以合同履约义务、服务交付方式和公司财务政策为准。
• 资源包：客户先买额度，后续逐步消耗。财务上通常涉及递延收入管理，但具体收入确认要依据合同履约义务、服务期限、消耗规则、过期规则、breakage 估计和适用会计准则确定；多数按用量消耗型资源包会随消耗逐步结转，最终口径必须由财务确认。
• 免费额度 / 赠送权益：客户不付费但平台有真实成本，需要进入成本归集和毛利测算，不能被当作“无成本营销”。
• 合同价 / 折扣价 / 促销价：必须有优先级和互斥规则。多种优惠叠加可能导致毛利击穿。
• 退款 / 退订 / 补偿券：不只是客服动作，还会影响权益回收、账单重算、收入冲回和客户成功记录。

2.3 关键指标看板

2.4 财务风险边界

产品经理在设计商品时必须守住以下边界：

1. 估算不是正式报价：预算测算、ROI 计算、演示页价格都要标注假设，正式报价以合同、报价单或控制台确认页为准。
2. 折扣不能无限叠加：合同折扣、促销价、渠道券、资源包优惠需要互斥或优先级。
3. 毛利底线必须可审批：低于毛利底线的报价，必须进入财务 BP 和业务负责人审批。
4. 免费额度有成本：尤其是 AI 模型、视频生成、GPU 训练等高成本能力，赠送额度必须进入成本测算。
5. 资源包不能简单按收款或开票确认收入：收款、开票、合同履约、服务交付和用量消耗可能不同步，收入确认应以合同履约义务和财务确认口径为准；开票更多影响税务和应收管理。
6. 退款退订要联动权益和账单：不能只退钱，不回收未用权益或不重算账单。

2.5 产品经理 必须问财务的 5 个问题

产品经理不替财务判断会计准则，但必须把财务判断需要的业务事实提前整理清楚。每个新商品、套餐或促销上线前，至少问清五件事：

1. 这笔钱在什么条件下才能确认收入，是下单、开通、服务期经过、用量消耗，还是客户验收？
2. 赠送额度、试用包、资源包、补偿券和渠道券分别如何归集成本，是否会影响毛利底线？
3. 合同折扣、促销价、资源包优惠、渠道分佣能否叠加，优先级和互斥规则是什么？
4. 退款、退订、账单冲正和发票调整分别由谁审批，是否会影响历史报表和客户续约？
5. 自助购买页、销售报价单和合同中哪些价格表述必须经过财务确认，哪些只能作为估算假设？

2.6 财务异常处理 SOP

1. 发现异常：来源可能是账单争议、毛利看板、销售反馈、客户工单或财务月结。
2. 冻结扩散：对疑似错误价格、错误折扣、错误计量先暂停新增使用或新增报价，避免影响扩大。
3. 定位对象：确认 商品主对象、售卖方案、可购买规格、计量项、价格规则、Contract、订阅关系、Bill 的具体版本。
4. 评估影响：列出影响客户、订单、合同、账单、收入确认、发票和毛利金额。
5. 制定方案：选择补账、冲正、退款、补偿券、权益调整、合同补充协议或价格回滚。
6. 审批确认：财务 BP、商品 产品经理、销售负责人、法务和必要时经营负责人确认。
7. 客户沟通：用客户能理解的语言说明原因、影响金额、处理方式和完成时间。
8. 复盘沉淀：补充价格校验、折扣互斥、计量校验、账单解释模板和巡检规则。

3. 稳定性保障 上架门禁与稳定性

3.1 稳定性保障 为什么是上架门禁

稳定性保障 的目标不是上线后救火，而是在商品可售前判断“承诺是否可交付”。云商品一旦进入官网、控制台、销售报价和合同，就会形成客户预期。若容量、限流、告警、灰度、回滚没有准备好，问题会从技术事故扩大成收入损失、账单争议和续约风险。

产品经理要把 稳定性保障 评审当作商品上架的必要 checkpoint，而不是可选会签。

3.2 稳定性保障 就绪 checklist

3.3 稳定性关键指标

• 可用性：客户能否正常购买、调用、交付和查看账单。
• 错误率：API 调用失败、生成失败、订单失败、计量写入失败的比例。
• 延迟 / 排队时长：尤其适用于模型生成、GPU 训练、批处理任务。
• 容量水位：资源池、地域、队列、配额、并发和库存的使用率。
• 限流触发次数：判断是否接近容量边界，也用于客户解释。
• 告警响应时间：从触发到有人处理的时间。
• 回滚耗时：从决策回滚到恢复客户可用的时间。
• 服务等级承诺 违约次数和影响客户数：直接关联赔付、满意度和续约风险。

3.4 稳定性保障 风险边界

1. 未经 稳定性保障 确认的地域，不承诺固定交付日期。
2. 未完成压测的商品，不承诺大促峰值能力。
3. 未配置限流和降级的高成本能力，不应开放无限自助购买。
4. 稳定性保障 负责确认技术可达性、容量、服务稳定性目标、告警、回滚和故障响应能力；合同级 服务等级承诺、赔付和客户承诺必须由 稳定性保障、法务、财务和业务负责人共同确认，不能仅凭 稳定性保障 结论对外承诺。
5. 服务等级承诺 文案必须和合同、官网、销售话术、控制台一致。
6. 容量不足时，优先保护已付费客户、合同承诺客户和关键业务链路。
7. 技术事故需要同步经营影响：受影响 成交规模、账单金额、客户数、续约风险。

3.5 稳定性异常 SOP

1. 识别等级：按影响客户数、收入金额、核心链路、服务等级承诺 违约可能性定级。
2. 止血优先：限流、降级、暂停新购、切换备用资源或回滚版本。
3. 同步口径：稳定性保障 给出技术事实，产品经理 转成业务影响，销售/客服使用统一客户话术。
4. 客户分层处理：合同客户、重点客户、自助客户分别给出通知方式和补偿策略。
5. 恢复验证：验证购买、调用、计量、账单、告警均恢复，而不是只看服务重启。
6. 事故复盘：沉淀根因、影响范围、时间线、赔付、改进项和负责人。

3.6 示例：大促队列不健康

若 Seedance Mini 大促期间生成队列积压，产品经理 不应只问“多久恢复”。正确动作是：确认排队时长、失败率、影响客户数、是否继续扣费、是否触发 服务等级承诺、是否暂停活动入口、是否通知销售停止承诺即时交付，以及是否需要给客户展示“当前排队较长，预计完成时间”。

4. 客户自助购买与售后解释

4.1 自助购买的产品原则

自助购买不是把内部后台开放给客户，而是把复杂商品规则翻译成客户能理解、能确认、能追溯的购买体验。

客户买前最关心五件事：买的是什么、多少钱、能用多久、用完怎么办、出问题找谁。产品经理需要把 售卖方案、可购买规格、计量项、价格规则、权益规则 翻译成清晰页面，而不是暴露内部字段。

4.2 买前确认页必须说清楚

• 商品类型：按量、包月、资源包、企业套餐、试用包或组合方案。
• 价格属性：目录价、促销价、合同价、估算价还是正式报价。
• 计费单位：Token、GB、实例小时、请求数、席位数等，要提供例子。
• 生效时间：立即生效、次日生效、审批后生效或交付后生效。
• 权益规则：额度、有效期、发放周期、消耗顺序、是否过期。
• 超额规则：用完后是否停止、降级、提醒、二次确认或自动按量计费。
• 退款退订：可退条件、不可退条件、已消耗权益处理方式。
• 服务等级承诺 和交付边界：哪些地域可用，哪些能力不承诺固定完成时间。

4.3 售后解释模板

客户问“为什么账单比估算高”时，建议解释为：

您购买前看到的是基于输入假设的费用估算，不是最终账单。最终账单会根据实际使用量、计费单位、价格规则、折扣和资源包抵扣情况生成。我们可以一起核对本账期的用量明细、资源包抵扣、超额部分和适用价格。

客户问“赠送 Token 为什么过期”时，建议解释为：

赠送额度属于套餐权益，按规则在指定周期内发放并在有效期结束后过期。购买页和权益说明中会展示有效期。已过期额度通常不能恢复，但如因系统异常导致展示或扣减错误，我们会按争议流程核查。

客户问“生成失败为什么扣费”时，建议解释为：

是否计费取决于您购买时确认的商品规则、合同条款和计量口径中对成功、失败、取消、超时等状态的定义。我们会核对请求状态、计量记录、账单记录和相关服务日志；如果属于平台异常导致的错误扣费，会按规则冲正或补偿。

客户问“合同价和控制台价为什么不同”时，建议解释为：

控制台展示通常是目录价或当前公开价。合同价是基于您的合同、采购范围、折扣审批和有效期形成的专属价格。最终以合同约定或已确认订单为准。

4.4 自助场景的风险边界

1. 客户只能看到自己的合同、账单、用量和权益，不能看到其他客户价格。
2. 估算页必须标注假设和非正式报价属性。
3. 超额付费默认不应静默发生，尤其是高成本能力，应由管理员二次确认。
4. 演示数据、演示 数据、置信度字段不能包装成官方承诺。
5. 客户可见字段必须使用业务语言，不展示工程 key、内部状态码和未解释缩写。
6. 售后解释要以可核验数据为依据：订单、用量、计量、价格、账单、合同版本。

5. 异常链路、反向链路与治理

5.1 为什么反向链路比新上架更复杂

新上架通常没有存量客户，问题主要是定义是否完整。反向变更面对的是已经购买、已经签约、已经计费、已经形成客户预期的商品。任何改规格、调价、可购买规格 下线、权益调整、退款退订，都可能同时影响客户体验、合同有效性、账单准确性、收入确认和渠道展示。

5.2 常见异常分类

5.3 变更影响分析模板

每个异常或反向变更，都应先生成影响分析，而不是直接改生产数据。

• 变更对象：商品主对象 / 售卖方案 / 可购买规格 / 计量项 / 价格规则 / 权益规则 / 可售地域。
• 变更原因：业务需求、成本变化、合规要求、事故修复、客户请求。
• 影响客户：客户数量、重点客户名单、到期客户、合同客户、自助客户。
• 影响合同：是否改变已签约价格、权益、服务等级承诺、地域和交付承诺。
• 影响账单：是否需要重算、补账、冲正、退款或发票调整。
• 影响渠道：官网、控制台、云市场、销售报价、客服知识库是否同步。
• 财务影响：成交规模、净收入、毛利、递延收入、争议金额。
• 稳定性保障 影响：容量、限流、告警、灰度、回滚、服务等级承诺。
• 客户沟通：是否需要公告、站内信、销售一对一通知或客服话术。
• 回滚方案：什么条件触发回滚，回滚后数据如何修复。

5.4 存量客户保护策略

涉及存量客户的调价、可购买规格 下线、权益调整和地域下线，不能只看新规则是否合理，还要先确定存量客户保护策略：

• 沿用旧规则：存量合同期内继续使用旧价格、旧权益或旧 可购买规格，适合合同承诺明确、客户影响大的场景。
• 合同到期切换：当前合同不变，续约时切换新规则，适合价格和权益体系升级。
• 客户可选迁移：提供新旧方案对比，让客户自主选择迁移时间，适合有替代方案的商品。
• 强制迁移：仅适用于安全、合规、资源不可用等必须下线场景，需要充分通知周期、替代方案和审批依据。
• 替代或补偿方案：对受影响客户提供替代地域、替代 可购买规格、补偿券或服务期延长，并明确财务和法务口径。

产品经理 在审批摘要中必须写清：影响客户清单、合同依据、通知周期、迁移路径、客户成功 owner、争议处理口径和是否影响收入确认。

5.5 异常处理 SOP

1. 登记异常：记录触发来源、发现时间、发现人、初步影响对象。
2. 定级定责：指定 产品经理 owner，并拉齐财务、稳定性保障、研发、销售、客服、法务。
3. 影响分析：先出影响分析和审批摘要，不直接变更生产配置。
4. 灰度验证：在小客户、测试组织、单地域或单渠道验证。
5. 审批发布：高风险动作必须有财务、稳定性保障、法务或经营负责人审批。
6. 客户通知：根据影响程度选择公告、邮件、站内信、销售通知或工单回复。
7. 全量执行：按计划变更，并记录版本、时间、操作者和回滚点。
8. 巡检闭环：验证渠道、订单、计量、账单、客户反馈和经营指标。
9. 复盘治理：沉淀自动校验、审批规则、话术模板和监控指标。

5.6 典型例子：套餐额度调整

如果 Agent Plan Medium 要调整每日赠送额度，不能只改权益字段。要同时检查：存量客户是否沿用旧规则、合同是否写明额度、官网和控制台是否同步、账单解释是否变化、毛利是否改善或恶化、客户是否需要提前通知、超额付费确认页是否需要更新。

6. 发布后巡检与运营健康

6.1 上架成功不等于业务健康

商品显示“已发布”只能说明配置进入渠道，不代表客户能顺利购买、订单能创建、计量能写入、账单能生成、销售能正确报价、客服能解释清楚。发布后 24 小时是发现配置错误、渠道不一致和链路断点的黄金窗口。

6.2 发布后 24 小时巡检清单

6.3 发布后健康日报结构

• 今日结论：健康、观察中、需干预、需回滚。
• 关键指标：访问、购买、订单、交付、计量、账单、错误率、客户反馈。
• 风险列表：按客户影响和收入影响排序。
• 阻塞事项：负责人、截止时间、升级路径。
• 客户声音：高频问题、争议点、需更新 常见问题说明 的内容。
• 下一步动作：继续灰度、扩大流量、暂停销售、修复配置或回滚。

6.4 渠道一致性重点

发布后最常见问题是价格和权益不一致。例如官网写“每日赠送 50 元等值 Token”，控制台显示 40 元，账单解释又按 Token 数量展示。产品经理要建立统一口径：客户看到的营销语言、购买页确认语言、账单解释语言可以不同，但底层规则必须一致，且能互相解释。

6.5 巡检异常处置

若发现控制台价和销售报价不一致：

1. 暂停使用错误报价继续成交。
2. 确认主数据源和生效版本。
3. 判断已成交客户是否受影响。
4. 财务确认是否需要补差、冲正或合同补充说明。
5. 销售和客服使用统一解释口径。
6. 修复渠道同步，并加入下一次巡检规则。

7. 续约、客户成功与增长

7.1 续约不是到期前才开始

云商品的续约风险通常在账单争议、服务等级承诺 事故、用量异常、成本超预算、权益解释不清时就已经出现。客户成功要把这些信号提前转成续约雷达，而不是等合同到期再补救。

7.2 续约雷达指标

7.3 客户健康度评分建议

可用 100 分制做轻量评分。以下权重是产品经理做续约雷达时的示例，不是固定行业标准；真实业务要按产品类型、客户层级、合同周期和成本结构校准：

• 用量健康 25 分：是否稳定、是否符合购买目的。
• 账单健康 20 分：是否有争议、争议是否关闭。
• 稳定性 20 分：是否出现 服务等级承诺 事故、恢复是否满意。
• 商务健康 15 分：付款、合同、折扣、采购流程是否顺畅。
• 关系健康 10 分：客户关键人是否明确，沟通是否顺畅。
• 增长机会 10 分：是否有升级、扩容、交叉销售机会。

低于 60 分应进入续约风险清单；60-80 分需要客户成功主动跟进；80 分以上可推进扩容或行业案例沉淀。

7.4 客户成功 SOP

1. 建档：记录客户购买商品、合同金额、到期日、使用场景、关键联系人。
2. 监控：每周查看用量、账单、工单、服务等级承诺、资源包消耗和健康评分。
3. 识别风险：将账单争议、使用下降、事故投诉、采购延迟标记为风险。
4. 制定动作：销售负责商务推进，客户成功负责使用健康，产品经理 负责规则或体验问题，稳定性保障 负责稳定性改进。
5. 客户沟通：用事实和数据解释问题，给出下一步时间表。
6. 续约复盘：无论续约成功、缩容还是流失，都要回连到商品规则、价格、稳定性和服务问题。

7.5 用量高不一定健康

客户用量高可能说明产品有价值，也可能说明成本失控、额度消耗过快、即将触发超额账单。产品经理在看续约机会时，要同时看收入、毛利、账单争议和客户满意度。

8. 组织层级、指标与分角色关注点

8.1 同一套事实，不同角色视角

云商品治理最大的组织问题，是每个角色只看自己熟悉的指标。销售看能不能卖，财务看毛利，稳定性保障 看稳定性，客户成功看续约，老板看目标。产品经理要把这些视角翻译到同一套商品事实上。

8.2 分角色关注点

8.3 组织层指标框架

• 增长指标：成交规模、净收入、年度经常性收入、月度经常性收入、销售机会池、新增付费客户、转化率。
• 质量指标：毛利率、折扣率、资源包消耗率、收入确认风险、账单争议金额。
• 稳定性指标：可用性、错误率、容量水位、服务等级承诺 事故、告警响应时间。
• 客户指标：活跃客户、客户健康度、续约概率、续约风险金额、满意度、工单关闭时长。
• 效率指标：上架周期、审批耗时、异常关闭时长、巡检覆盖率、字段一致性通过率。
• 目标拆解指标：季度/月度目标值、实际值、差距、差距原因、责任 owner、下一步动作和预计追回时间。
• 长期指标：续约率、扩容率、客户健康度、产品覆盖率、长期留存率。
• 战略指标：市场份额、客户结构、行业竞争力、重点行业渗透率、战略投入产出。

8.4 示例：GPU 容量不足时各角色怎么问

• 老板：影响多少 成交规模、多少重点客户、什么时候恢复、谁负责。
• 稳定性保障：哪个地域、哪个资源池、容量水位多少、是否限流或扩容。
• 销售：哪些订单不能交付，客户该怎么解释，能否换地域或替代方案。
• 财务：收入确认是否延迟，是否触发赔付或退款，毛利是否变化。
• 客户成功：哪些客户续约受影响，是否需要主动通知和补偿。
• 产品经理：商品可售状态是否要调整，购买页和销售话术是否要更新。

9. 客户场景与解释边界

9.1 大客户场景

大客户通常不是直接点购买，而是经过方案、报价、合同、采购、交付和验收。其核心关注是合同价、服务等级承诺、稳定性、审计、交付窗口、容量预约和服务承诺。

产品经理要支持销售和解决方案明确：哪些能力已经产品化，哪些只是方案集成；哪些地域有容量，哪些需要预约；哪些 服务等级承诺 能写进合同，哪些只能作为目标值；哪些折扣需要财务审批。

9.2 小客户自助场景

小客户关注购买是否简单、价格是否透明、额度是否能解释、用完是否自动扣费、能否快速升级。页面应该优先回答“我现在买会发生什么”，而不是展示复杂规则。

对小客户尤其要避免三类误解：把估算当正式报价、把赠送额度当永久额度、把失败重试当免费使用。

9.3 续约客户场景

续约客户更关注历史体验：账单是否清楚、服务等级承诺 是否稳定、工单是否及时、用量是否匹配业务、是否需要升级或降级、竞品是否更便宜。客户成功要提前准备健康报告，而不是只发送续约报价。

9.4 客户采购场景

采购关注正式报价、合同、发票、税务、付款条件、交付证明和服务承诺。产品经理不需要替代财务和法务，但要保证商品规则能支持采购材料：报价有效期、价格口径、服务范围、退款退订边界、发票项目和交付验收依据。

9.5 客户管理员场景

客户管理员关注权限、预算、额度、通知人、超额付费确认和组织内成本分摊。对于 Plan 型或高成本商品，应提供预算上限、用量提醒、管理员二次确认、通知联系人和权限隔离。

9.6 行业差异示例

• 金融客户：更重视合规、审计、服务等级承诺、合同边界、数据安全和稳定交付。
• 内容行业客户：更重视峰值弹性、生成速度、成本可控、活动保障和快速扩容。
• 开发者 / 中小企业：更重视价格透明、接入简单、账单解释和自助升级。

9.7 对外解释边界

1. 不把内部成本、毛利底线、审批意见直接暴露给客户。
2. 不承诺未经 稳定性保障 和法务确认的 服务等级承诺、地域、交付日期和赔付。
3. 不把演示效果、估算结果、测试数据包装成正式承诺。
4. 不用内部字段解释客户问题，要转成业务语言。
5. 不在客户争议中先归因客户错误，应先核对订单、计量、账单和合同事实。

10. 本章交付物清单

产品经理在推进云商品商业化与运营治理时，至少应沉淀以下交付物：

• 财务商业化评审：商业测算、毛利底线、折扣规则、收入确认口径、资源包递延规则。
• 经营健康看板：成交规模、净收入、年度经常性收入/月度经常性收入、毛利、活跃付费客户、争议金额、续约风险。
• 稳定性保障 上架门禁清单：容量、压测、限流、告警、灰度、回滚、服务等级承诺、通知机制。
• 客户购买确认页：商品类型、计费单位、权益规则、超额规则、退款退订和报价边界。
• 售后解释模板：账单争议、赠送额度、生成失败扣费、合同价差异、地域不可售。
• 变更影响分析：客户、合同、账单、渠道、财务、稳定性保障、客户沟通和回滚方案。
• 异常处理 SOP：登记、定级、影响分析、灰度、审批、通知、执行、巡检、复盘。
• 发布后巡检报告：官网、控制台、销售报价、订单、交付、计量、账单、告警、客户反馈。
• 续约雷达：到期时间、年度经常性收入、用量健康、账单争议、服务等级承诺、满意度、竞品风险和下一步动作。
• 分角色经营视图：销售、解决方案、财务、稳定性保障、法务、客户成功、老板分别看什么。

本章的核心判断标准是：商品不仅能上架，而且能被正确售卖、稳定交付、准确计费、清楚解释、异常可控、续约可预警。

详细章节：平台视角、案例与模板

04 研发平台视角、实战案例与可复用模板

1. 研发和平台实现视角

本节的目标不是把产品经理训练成工程师，而是让产品经理知道：哪些规则可以靠运营流程兜底，哪些必须进入平台模型、权限、工具和验收用例。云商品平台的边界，可以用一句话概括：平台不替业务做判断，但必须把业务判断固化为可追溯、可校验、可回滚的规则。

1.1 产品经理需要理解的平台边界

产品经理提出规则时，应尽量用“输入、输出、责任人、风险、验收口径”表达；研发实现时，应把这些规则落到数据结构、接口契约、权限策略、工具动作和自动化测试中。

1.2 平台能力的分层

以下是某类智能业务平台或内部商品平台可能采用的实现分层，不是所有云厂商的行业标准命名。产品经理需要掌握的不是术语本身，而是背后的通用原则：领域隔离、主数据配置、权限控制、工具化流程、业务展示和自动化验收。

1. 领域能力包：业务域包

用于注册某个业务域的资源、工具、权限、路由和展示。例如云商品域要和经销商域隔离，避免客户、合同、账单、折扣等敏感数据跨域流动。

1. Resource Config：资源配置与数据字典

定义表、字段、中文业务说明、主键、展示字段、可见范围和维护方。产品经理最关心的是：这个字段是什么意思、谁维护、谁消费、变更会影响什么。

1. Query Business Data：通用业务查询

用于查询商品、客户、合同、订单、计量、账单、续约风险等数据。它解决“查得到、查得准、查得有权限”的问题。

1. Dedicated Tools：专用业务工具

用于估算、商品评审、审批摘要、发布巡检、变更影响分析、经营日报、续约雷达等场景。写入类动作原则上先生成草稿、模拟计划或审批摘要，不直接修改生产规则。

1. Permission Policy：权限策略

控制客户只能看自己的数据，销售只能看授权客户，财务能看价格与收入，稳定性保障 能看容量和稳定性，老板看聚合经营指标。权限不是前端隐藏按钮，而是查询、工具和展示层共同执行。

1. 结构化展示界面 Surface：业务展示层

将工具结果变成业务驾驶舱、流程图、表格、表单、标签和风险卡片。好的展示顺序是：先结论、风险、下一步动作，再给明细和证据。

1. 评测：自动化验收

用测试确保路由正确、字段中文化、权限隔离、估算边界、演示 标识、审批摘要和浏览器 UAT 稳定。Prompt 只能提醒，评测 才能持续守边界。

1.3 生产级工程能力清单

如果商品平台要支撑真实售卖，而不是只做演示，产品经理 需要和研发确认以下能力是否进入版本计划：

• 幂等与去重：订单创建、权益发放、计量写入、账单重算不能因重试产生重复权益或重复扣费。
• 审计日志：价格、权益、地域、服务等级承诺、折扣等高风险字段的每次变更都要记录操作者、时间、前后值、审批单和回滚点。
• 灰度发布：支持按客户、地域、可购买规格、渠道或流量比例发布，先小范围验证再扩大。
• 可观测性：订单、交付、计量、账单、权益、通知等链路要有 trace、指标、日志和告警。
• 故障回放：账单争议、计量异常、服务等级承诺 事故发生后，能还原客户路径、系统决策和数据版本。
• 数据权限：客户、合同价、账单、折扣和续约风险必须租户隔离、角色隔离、最小授权。
• 自动化验收：关键业务边界要有测试，不依赖人工记忆和 prompt 约束。

1.4 研发必须守住的红线

• 工程字段不能直接暴露给客户，例如 source/演示/confidence/internal_status 必须转写成业务语言。
• 估算、演示数据、参考价格不能说成正式报价。
• 写入类动作不能绕过审批，默认生成草稿、模拟计划、审批摘要或待办。
• 客户、合同、账单、折扣、发票等敏感数据必须做租户和角色隔离。
• 不同 domain 的工具和前端 surface 必须隔离，不能因为共享组件导致数据串场。
• 所有高风险动作必须有审计：谁发起、基于什么数据、影响哪些客户、是否可回滚。
• 发布不是完成按钮，而是要经过灰度、订单、计量、账单、渠道一致性和客户反馈巡检。

1.5 产品与研发的协作交付物

• 数据字典：字段中文名、业务含义、归属方、可见性、下游消费方。
• 工具契约：工具能做什么、不能做什么、输入输出、失败状态、是否写入。
• 权限策略：角色、租户、客户、合同、账单、折扣的访问边界。
• 路由规则：什么问题进入云商品域，什么问题需要转人工或拒答。
• 结构化展示界面 展示契约：不同角色看到的卡片、表格、风险提示和下一步动作。
• 自动化验收用例：字段中文化、估算声明、权限隔离、审批摘要、巡检链路。
• 浏览器 UAT 剧本：从官网、控制台、工作台、销售报价到账单解释的端到端检查。

2. 实战案例 A：ECS GPU 训练实例

2.1 故事背景

一家金融科技客户计划训练风控模型，预算 30 万，希望在新加坡地域购买 GPU 训练能力，并配套 RDS、TOS、CLB。销售带着机会找到商品 产品经理：“客户下周要报价，能不能把 GPU 训练实例作为标准商品卖？”

产品经理 的第一反应不应是“马上上架”，而是先判断这项能力是否完成产品化：GPU 资源是否稳定、地域容量是否可承诺、交付窗口是否明确、训练场景是否有 服务等级承诺、成本是否支持折扣、售后是否能解释账单。

2.2 产品化：从资源能力到可销售产品

产品化评审会由商品 产品经理 牵头，研发、资源团队、稳定性保障、财务 BP、法务和销售参加。会议不是讨论页面文案，而是确认产品边界：

• 目标客户：需要模型训练、渲染、科学计算等高性能算力的企业客户。
• 核心场景：短周期训练任务、长期包月训练集群、按项目采购算力。
• 可承诺项：实例规格、地域、交付周期、基础 服务等级承诺、监控告警。
• 不可承诺项：未经容量确认的固定交付日期、训练效果、客户模型收敛结果。
• 成本输入：GPU 卡型、机房成本、网络和存储成本、运维成本。
• 交付依赖：账号开通、VPC、存储、数据库、负载均衡、安全组。

只有当 稳定性保障 确认容量、财务确认毛利底线、法务确认 服务等级承诺 表述后，GPU 训练能力才进入商品化设计。

2.3 商品化：商品主对象、售卖方案、可购买规格、计量项、价格规则、可售地域

商品 产品经理 将能力拆成平台可识别的商品模型：

• 商品主对象：ECS GPU 训练实例。
• 售卖方案：包月实例、按量实例、企业项目包。
• 可购买规格：按 GPU 卡型、CPU/内存、显存、地域组合形成规格。
• 计量项：实例小时、GPU 小时、带宽、存储用量。
• 价格规则：目录价、阶梯价、合同价、折扣审批价。
• 可售地域：新加坡、华东等可售地域，每个地域绑定容量状态。

研发平台需要校验：同一个 可购买规格 是否绑定了正确 计量项，可售地域 是否可售，价格是否有生效时间，合同价是否只对授权客户可见，控制台展示是否和销售报价一致。

2.4 上架：审批不是形式，而是风险汇总

上架前会生成发布申请和审批摘要。摘要中必须列出：产品定义、商品模型、价格、容量、服务等级承诺、风险、回滚方案和巡检计划。

• 财务关注：30 万预算下折扣后毛利是否达标。
• 稳定性保障 关注：新加坡 GPU 是否有库存，是否需要容量预约。
• 法务关注：合同能否写固定交付日期和 服务等级承诺 赔付。
• 上市打法 关注：销售是否有方案、常见问题说明、禁承诺项。
• 平台研发关注：订单、交付、计量、账单链路是否打通。

如果新加坡容量只有部分可用，商品不能简单标记为“全量可售”，而应在 可售地域 和交付规则中标明需预约或需人工确认。

2.5 销售：30 万预算如何变成方案

销售和解决方案架构师把客户预算拆成组合方案：ECS GPU 承担训练，RDS 存储结构化数据，TOS 存储训练样本和模型文件，CLB 支持训练服务入口或后续推理服务流量。

报价前检查三件事：

1. 价格是估算、目录价、还是正式合同报价。
2. 新加坡地域交付是否已经被 稳定性保障 确认。
3. 折扣是否触发财务审批。

平台可生成“销售报价前检查清单”，但不能自动承诺客户交付日期；如果容量未确认，页面必须提示“需完成容量预约后才能形成正式承诺”。

2.6 交付：新加坡容量不足导致延期

客户确认意向后，订单进入交付。此时 稳定性保障 发现新加坡 GPU 库存不足，预计延期三天。这个问题不是单纯运维问题，而会影响：

• 客户项目计划和满意度。
• 销售本月 成交规模 统计节奏、订单达成节奏或经营目标达成节奏。
• 合同交付承诺和法务风险。
• 财务收入确认时间。
• 客服解释和客户成功跟进。

平台应生成延期影响分析：影响订单、客户、金额、预计恢复时间、可替代地域、是否需要补偿、客户通知模板。产品经理 需要和销售、稳定性保障、法务共同决定：等待新加坡容量、切换地域、拆分交付，还是调整合同。

2.7 经营：上架后看健康，不只看成交

发布后 24 小时和首周经营复盘要看：官网和控制台展示是否一致、销售报价是否同步、订单是否创建成功、实例是否交付、计量项 是否写入、账单是否正确、毛利是否低于底线、容量告警是否触发。

老板可能只问“30 万签了吗”，但 产品经理 需要补充回答：净收入是多少、毛利是否健康、新加坡容量是否影响后续 pipeline、是否有客户延期风险、下一批 GPU 采购是否需要提前规划。

2.8 复盘：沉淀下一次上架模板

这次案例应沉淀为 GPU 类商品上架模板：容量评审、地域可售规则、报价前容量确认、折扣审批、交付延期通知、订单-计量-账单巡检、客户复盘。下一次新增 GPU 可购买规格 时，不应从零讨论，而应复用模板并只评审差异。

3. 实战案例 B：Seedance Mini 自助购买

3.1 故事背景

Seedance Mini 原本只是一个视频生成模型能力，研发可以通过内部接口调用，运营希望借大促活动开放给内容创作者和中小企业自助购买。销售问：“能不能直接做一个活动页，挂一个低价资源包？”

产品经理 需要把问题拉回完整链路：模型能力能调用，不代表客户能购买；客户能购买，不代表能计量、能账单、能退款、能解释失败扣费、能承受大促流量。

3.2 产品化：模型能力变成可自助购买商品

产品化要先定义清楚客户买到什么：

• 输入：文本、图片或其他生成条件。
• 输出：视频生成结果、清晰度、时长、格式。
• 成功标准：什么情况下算生成成功，什么情况下不扣费或可补偿。
• 限制：内容安全、并发、队列等待、地域、模型版本。
• 服务等级承诺：生成成功率、排队时延、故障通知，不承诺创意效果。
• 客户体验：预算估算、资源包余额、失败记录、账单解释。

研发要提供模型调用、任务队列、内容安全、计量事件和错误码；产品要把错误码翻译成客户能理解的状态，例如“生成失败未扣费”“内容安全拦截”“队列繁忙请稍后”。

3.3 商品化：售卖方案 设计和互斥规则

Seedance Mini 的典型售卖方式包括：

• 按量 售卖方案：按生成次数、视频秒数或算力消耗计费。
• 资源包 售卖方案：预付费购买固定额度，适合预算明确的小客户。
• 促销价：大促期间限时折扣。
• 合同折扣：大客户通过销售签约获得专属价格。

难点在互斥规则。促销价、资源包折扣和合同折扣不能无限叠加，否则可能击穿毛利。平台需要明确：客户若已有合同价，是否还能购买促销资源包；资源包过期后是否转按量；生成失败是否返还额度；退款时已消耗额度如何结算。

3.4 上架：官网、控制台、云市场 和销售口径一致

上架不是只发布活动页。不同渠道展示不同投影，但必须来自同一套主数据：

• 官网：卖点、案例、常见问题说明、活动价格、禁承诺项。
• 控制台：可购买 售卖方案、余额、用量、价格、超额确认。
• 云市场：商品简介、规格、价格、服务条款。
• 销售方案：预算估算、合同折扣、行业场景、风险边界。
• 客服后台：订单、任务、扣费、失败原因和解释话术。

如果官网写“低至 0.1 元/次”，控制台却按视频秒数扣费，客户会认为被误导。因此上线前必须做渠道一致性巡检。

3.5 稳定性保障：大促流量不是营销问题，而是稳定性问题

大促当天，流量可能瞬间上升，队列堆积。稳定性保障 需要提前给出：容量评审、队列阈值、限流策略、降级策略、告警联系人、销售通知机制和回滚方案。

当队列不健康时，平台应自动给出风险提示：预计排队时长上升、部分任务延迟、是否暂停促销入口、是否通知销售停止承诺交付时间。产品经理 不能只关注转化率，还要关注失败率、排队时延、退款率和客服工单。

3.6 销售与客户：估算不等于正式报价

内容行业客户预算 2 万，销售用估算工具测算可以买多少生成额度。工具必须标注：这是基于平均视频时长、生成成功率和参考单价的估算，不是正式报价。正式报价需要确认 售卖方案、可购买规格、价格生效期、折扣审批和合同条款。

客户自助购买时，也要在购买页看见：资源包额度、有效期、消耗规则、失败扣费规则、超额是否自动付费。默认建议：资源包用完后不自动扣费，除非管理员二次确认开通按量。

3.7 交付与巡检：订单、计量、账单闭环

Seedance Mini 的交付不一定是人工开通资源，而是客户购买后立即获得调用权限和额度。平台要验证：

1. 订单是否创建成功。
2. 权益是否发放到正确账号。
3. 任务调用是否写入计量记录。
4. 失败任务是否按规则扣费或返还。
5. 账单是否能解释资源包消耗和按量费用。
6. 客服是否能查到客户可见证据。

上线后 24 小时巡检要看官网、控制台、订单、计量、账单、告警、客户反馈和 成交规模 偏离。若发现控制台价与销售报价不一致，应立即冻结相关报价或下线入口，生成影响客户清单和修复计划。

3.8 经营复盘：不只看活动 成交规模

复盘时除了 成交规模，还要看净收入、毛利、资源包消耗率、任务成功率、平均排队时长、退款率、账单争议、促销客户留存和升级机会。如果促销带来大量低毛利用量，但没有留存和升级，就不是健康增长。

本案例应沉淀为 AI 模型自助商品模板：模型能力 就绪、资源包规则、促销互斥、任务计量、失败扣费、内容安全、队列限流、渠道 常见问题说明 和上线巡检。

4. 实战案例 C：Agent Plan 套餐权益

4.1 故事背景

企业客户希望为团队购买 Agent 能力：员工可以使用对话、代码生成、联网搜索、文档处理和视频生成。业务团队想推出 Agent Plan Medium：每个组织每月固定付费，每天赠送一定额度 Token，用完后可升级或按量购买。

这类产品看起来像会员套餐，实际比单一云资源更复杂，因为它同时涉及权益发放、用量消耗、超额、退款、退订、账单解释和高成本能力毛利风险。

4.2 产品化：先定义套餐承诺

产品经理 要先明确客户买的不是“一个模型”，而是一组企业 Agent 权益：

• 用户范围：按组织、席位、管理员还是项目空间授权。
• 能力范围：基础对话、代码能力、联网搜索、文件处理、视频生成等。
• 权益额度：每日赠送 Token、月度总量、不同能力的折算规则。
• 管理能力：管理员分配席位、查看用量、设置预算上限、确认超额。
• 不可承诺项：不承诺所有问题一定正确，不承诺外部搜索结果稳定，不承诺视频生成无限可用。

产品化阶段必须让研发、财务和法务一起评审，因为一句“每天送 50 元等值 Token”背后，是发放、消耗、过期、成本和合同解释规则。

4.3 商品化：Plan、可购买规格、权益规则 和 计量项 的关系

Agent Plan 的商品模型可以这样拆：

• 商品主对象：企业 Agent 套餐。
• 售卖方案：月付套餐、年付套餐、试用套餐、企业合同套餐。
• 可购买规格：Basic、Medium、Pro 或按席位数量分档。
• 权益规则：每日额度、月度额度、能力开关、席位数量、超额规则。
• 计量项：Token、联网搜索次数、文件处理页数、视频生成秒数、高成本模型调用。
• 价格规则：套餐价、席位价、超额单价、合同价。

平台要处理权益与计量的映射：客户看到的是“剩余额度”和“为什么扣费”，内部记录的是多个 计量项。展示层不能把复杂公式直接抛给客户，而应解释为“本次使用消耗了基础对话额度/联网搜索额度/视频生成额度”。

4.4 上架：权益规则比页面按钮更重要

上架前必须确认以下规则：

• 每日额度什么时候发放，按哪个时区计算。
• 未用完额度是否过期，是否可累计。
• 消耗顺序：赠送额度、资源包、合同额度、按量额度谁先消耗。
• 退订后剩余额度是否冻结、失效或保留到周期末。
• 退款时已消耗赠送额度如何处理。
• 超额是否自动扣费，是否需要管理员二次确认。
• 账单中如何展示赠送、消耗、超额和退款。

建议默认规则是：套餐额度用完后不自动扣费，必须由客户管理员二次确认开通超额付费或升级 Plan。这样可以降低账单争议。

4.5 销售：企业预算如何分配

销售面对一个内容行业客户，预算 2 万，希望同时买 Seedance 和 Agent Plan。销售方案不能只按产品热度分配，而要看客户场景：如果客户团队主要做内容策划和脚本生成，Agent Plan 占比更高；如果客户主要批量生成视频，Seedance 资源包占比更高。

报价前要确认：Agent Plan 的席位数、管理员、额度、超额规则、合同折扣是否影响毛利；Seedance 资源包是否和 Agent Plan 内的视频权益重复；两个产品的账单解释是否能让客户看懂。

4.6 交付：从订单到权益发放

客户购买后，交付链路不是创建一台机器，而是建立订阅和权益关系：

1. 创建订单和订阅。
2. 给组织开通 Plan。
3. 给管理员分配权限。
4. 发放每日或月度额度。
5. 启用对应 Agent 能力。
6. 建立计量记录与账单关联。
7. 在控制台展示余额、用量、超额状态和续约时间。

平台要特别注意幂等：如果订单回调重试，不能重复发放权益；如果客户退订，不能只关前端按钮，必须冻结权益、停止发放、处理账单和通知客户成功。

4.7 经营：高成本能力可能击穿毛利

Agent Plan 的风险在于平均客户看似盈利，但少数重度客户频繁调用高成本模型、联网搜索和视频生成，可能把毛利打穿。经营看板要区分：收入、Token 消耗、不同能力成本、超额转化、活跃席位、账单争议和续约风险。

如果某个客户用量异常高，不能简单限流。应先判断是健康增长、滥用、产品规则不清，还是销售承诺过度。可能的动作包括：客户成功沟通、升级 Plan、调整超额确认、增加预算提醒、修正销售话术。

4.8 复盘：把争议沉淀成规则

Agent Plan 最常见的复盘问题是：客户为什么觉得额度不够、为什么不理解扣费、为什么退订后还看到费用、为什么超额没有预警。每个争议都应回到规则和展示：权益说明是否清晰，账单解释是否可读，管理员通知是否到位，销售是否承诺了平台没有实现的权益。

本案例应沉淀为 Plan 型产品模板：权益规则表、消耗顺序、额度过期、超额确认、退款退订、账单解释、毛利穿透、续约健康和客户通知。

5. 学习成果验收

学完本章后，不要求学习者能设计完整系统，但应能用业务语言讲清平台边界，并能把一个案例从产品化讲到复盘。

5.1 概念验收

学习者应能回答：

• 技术能力、产品、商品、售卖方案、可购买规格、计量项、价格规则、权益规则 分别是什么。
• 为什么官网不是商品主数据源，为什么控制台购买页必须和计量、账单一致。
• 为什么 Plan 型产品比单品型产品复杂。
• 为什么估算不能等同于正式报价。
• 为什么 稳定性保障 是上架门禁，不是上线后救火。
• 为什么客户可见字段和内部工程字段必须分离。
• 为什么写入类动作要先生成草稿、模拟计划或审批摘要。

5.2 流程验收

给定任意一个云商品，学习者应能按顺序说明：

1. 产品化定义：目标客户、场景、可承诺项、不可承诺项、服务等级承诺、成本、交付依赖。
2. 商品化建模：商品主对象、售卖方案、可购买规格、计量项、价格规则、可售地域、权益规则。
3. 上架审批：IPD、财务毛利、稳定性保障 容量、法务合规、上市打法 具备技术条件。
4. 渠道发布：官网、控制台、云市场、销售、客服各自展示什么。
5. 销售成交：预算、方案、折扣、正式报价、合同边界。
6. 交付开通：订单、订阅、权益、资源、计量、账单。
7. 经营巡检：成交规模、净收入、毛利、容量、稳定性、客户反馈。
8. 复盘迭代：问题、根因、影响、修复、模板沉淀。

5.3 案例验收

学习者应能独立讲清三条故事线：

• ECS GPU：金融客户 30 万预算如何从 GPU 训练需求变成组合方案；新加坡容量不足如何影响交付、合同、成交规模 和客户沟通；复盘如何沉淀容量和报价模板。
• Seedance Mini：模型能力如何变成自助购买商品；资源包、促销价和合同折扣如何互斥；大促队列如何限流；上线后如何校验订单、计量、账单闭环。
• Agent Plan：企业套餐如何定义权益；每日赠送 Token 如何发放、消耗和过期；额度用完为何不应自动扣费；高成本模型如何带来毛利风险和续约风险。

5.4 产出物验收

学习者应能独立产出以下草稿，并能说明每份文档的使用场景：

• 产品化定义草稿。
• 商品模型草稿。
• 售卖方案/可购买规格/计量项/价格规则 关系图。
• 权益治理规则。
• 渠道发布矩阵。
• 稳定性保障 上架门禁清单。
• 财务商业化评审。
• 销售方案和报价前检查清单。
• 客户解释话术。
• 变更影响分析。
• 发布后巡检报告。
• 经营健康简报。
• 续约风险清单。
• 上线复盘模板。

5.5 通过标准

• 能把“能调用 API”与“能作为商品销售”区分开。
• 能指出一个字段变更会影响哪些渠道、客户、合同和账单。
• 能在面对销售紧急需求时，先确认报价边界、容量边界和审批边界。
• 能在客户投诉账单时，用客户语言解释计量、权益和扣费。
• 能在复盘时同时看业务指标、财务指标、稳定性指标和客户反馈。

6. 可复用模板清单

以下模板不必拆成多个文件，但在实际工作中应形成可复制的清单、表格或工作台表单。

6.1 产品化定义模板

• 产品/能力名称。
• 目标客户和核心场景。
• 客户痛点和替代方案。
• 可承诺能力。
• 不可承诺项。
• 服务等级承诺 初稿。
• 成本输入。
• 交付依赖。
• 风险与阻塞。
• 责任人和下一步动作。

6.2 商品模型模板

• 商品主对象：商品主对象、产品族、展示名、业务说明。
• 售卖方案：售卖方式、适用客户、计费模式、生效条件。
• 可购买规格：规格、参数、地域、上下架状态。
• 计量项：计量项、计量单位、采集来源、失败处理。
• 价格规则：目录价、阶梯价、合同价、促销价、生效时间。
• 权益规则：额度、权益、消耗顺序、过期、退订、退款。
• 可售地域：可售地域、容量状态、交付周期。
• 下游系统：官网、控制台、销售报价、订单、账单、客服。

6.3 售卖方案 设计模板

• 售卖方案 名称和目标客户。
• 按量、包月、资源包、试用、企业套餐的选择依据。
• 可购买规格 绑定关系。
• 计量项 和 价格规则 关系。
• 折扣、促销、合同价互斥规则。
• 超额和续费规则。
• 退款和退订规则。
• 客户解释文案。
• 财务和法务审批点。

6.4 权益治理模板

• 权益名称。
• 发放对象：账号、组织、席位、项目。
• 发放时间和时区。
• 发放额度和有效期。
• 消耗顺序。
• 余额展示方式。
• 用完后的处理：停止、升级、按量、二次确认。
• 退订、退款、冻结和恢复规则。
• 账单展示和客服解释。
• 毛利穿透和异常用量告警。

6.5 渠道发布矩阵模板

6.6 稳定性保障 上架门禁模板

• 容量是否足够。
• 可售地域和交付窗口。
• 队列、限流、降级策略。
• 告警阈值和联系人。
• 灰度比例。
• 回滚触发条件。
• 服务等级承诺 边界。
• 客户通知和销售通知机制。
• 发布后 24 小时巡检项。

6.7 销售报价前检查模板

• 客户名称和预算。
• 业务场景和产品组合。
• 使用地域和合规要求。
• 价格类型：估算、目录价、合同价、正式报价。
• 折扣审批状态。
• 容量确认状态。
• 服务等级承诺 和不可承诺项。
• 合同、发票和交付依赖。
• 风险提示和下一步动作。

6.8 发布后巡检模板

• 官网展示是否正确。
• 控制台购买是否正常。
• 销售报价是否同步。
• 订单是否创建成功。
• 权益或资源是否交付。
• 计量是否写入。
• 账单是否生成且可解释。
• 告警、限流和 服务等级承诺 是否异常。
• 客户反馈和客服工单。
• 成交规模、净收入、毛利与预期偏差。
• 问题、负责人、截止时间。

6.9 变更影响分析模板

• 变更类型：改价、新增 可购买规格、下线、权益调整、地域变更、退款退订。
• 触发原因。
• 影响客户和合同。
• 影响订单、计量、账单、发票。
• 影响官网、控制台、销售、云市场、客服。
• 财务收入确认和毛利影响。
• 法务和客户通知要求。
• 灰度、回滚和巡检计划。
• 审批人和审计记录。

6.10 经营健康简报模板

• 本期 成交规模、净收入、年度经常性收入/月度经常性收入、毛利率。
• 活跃付费客户和新增客户。
• 销售机会池 和重点机会。
• 续约风险金额。
• 账单争议和退款金额。
• 容量、稳定性和 服务等级承诺 风险。
• 高成本能力消耗。
• 本周阻塞和负责人。
• 下周动作。

6.11 上线复盘模板

• 上线目标。
• 实际结果。
• 关键时间线。
• 产品化、商品化、上架、销售、交付、经营各环节表现。
• 问题和根因。
• 客户影响和金额影响。
• 修复动作。
• 可复用模板和规则。
• 后续版本计划。

附录模板：产品经理可复制模板

产品经理可复制模板

1. 产品化定义模板

2. 商品模型模板

3. 销售报价前检查模板

4. 变更影响分析模板

5. 发布后巡检模板

6. 经营健康简报模板

7. 售卖方案 设计模板

8. Plan 权益治理模板

9. 渠道发布矩阵模板

10. 稳定性保障 上架门禁模板

11. 上线复盘模板

填写样例

样例 A：Seedance Mini 产品化定义

样例 B：Agent Plan 权益治理

样例 C：ECS GPU 正式报价前检查

样例 D：上线后 24 小时巡检

样例 E：客户解释话术

客户问“为什么账单比估算高”时：

您看到的估算是基于当时输入的用量假设，不是最终账单。最终账单会根据实际使用量、计费单位、资源包抵扣、折扣和超额规则生成。我们可以一起核对本账期的用量、抵扣和适用价格；如果发现计量或价格异常，会按账单争议流程处理。