第 3 章 · 预计阅读 19 分钟
签约与开通
合同已经签了，账号为什么仍可能不能用？
合同确认商业承诺，账号、席位和权限则把承诺转成可使用的软件服务。
先放回整门生意
先知道这一章为什么存在
先把“签约与开通”理解成一段有触发、有负责人、有记录、也有完成标准的业务，而不是一组部门名词。
上一章“需求沟通与方案”应先形成：方案要解决客户的关键问题，也必须尊重产品边界和交付成本。
本章把“合同确认商业承诺，账号、席位和权限则把承诺转成可使用的软件服务。”从一句目标变成可执行、可交接、可核验的工作。
结果将交给下一章“使用、计费与回款”：订阅要同时追踪客户是否获得价值，以及合同、发票、应收和回款是否一致。
- 收入怎么受影响
- 栈桥协同通过账号订阅费、超额存储与算力费、实施迁移费和高级支持服务费收费。本章形成的“60 个席位开通并通过客户验收”要和“本步核对线索：订阅合同在处理前后的状态变化”、“本步核对线索：服务开通在处理前后的状态变化”、“本步核对线索：基于角色的访问控制在处理前后的状态变化”和“本步核对线索：服务授权在处理前后的状态变化”一起核对，才能继续判断验收、结算或后续经营；现金时点按以下规则判断：订阅通常按年预收；实施费在启动和上线验收时分段收取，用量费次月按账单结算。
- 风险在哪里出现
- 全程要警惕“宕机、数据泄露、成本随用量失控和客户流失”。本章至少要用“本步核对线索：订阅合同在处理前后的状态变化”、“本步核对线索：服务开通在处理前后的状态变化”、“本步核对线索：基于角色的访问控制在处理前后的状态变化”和“本步核对线索：服务授权在处理前后的状态变化”留下可追溯证据。
读完这一章，你应该能自己解释
- 能用自己的话解释“合同已经签了，账号为什么仍可能不能用？”，并说出它为什么会影响客户价值或经营结果。
- 能按依赖顺序还原4个业务步骤，并指出每一步的负责人、记录和交接物。
- 能区分业务流、钱流、信息流和责任流，不把“做过动作”误当成“完成交付”。
- 遇到相似情境时，能用“产出是否形成、证据能否核对、风险是否受控”作出判断。
先建立业务直觉
合同已经签了，账号为什么仍可能不能用？
双方签署 60 席年度订阅，金额 ¥72,000。系统创建客户组织并导入成员，但 8 名设计师因角色映射错误无法进入项目，合同状态和实际可用状态出现差异。
把它放进栈桥协同的经营现场：本章只聚焦“签约与开通”这一环，追踪它怎样承接已有输入，并把“合同确认商业承诺，账号、席位和权限则把承诺转成可使用的软件服务”变成可以执行和复核的工作。
本章从“签署年度合同”开始，依次经过“签署年度合同”、“创建客户组织”、“配置席位权限”和“客户验收可用”，最后得到“60 个席位开通并通过客户验收”。判断是否完成，要把动作、产出、业务记录和下一位接手者放在一起核对。
至少同时满足三件事：产出“60 个席位开通并通过客户验收”；关键记录“本步核对线索：订阅合同在处理前后的状态变化”、“本步核对线索：服务开通在处理前后的状态变化”、“本步核对线索：基于角色的访问控制在处理前后的状态变化”和“本步核对线索：服务授权在处理前后的状态变化”可以相互核对；相关负责人清楚下一步由谁接手。
完整案例推演
跟着栈桥协同，把“签约与开通”完整跑一遍
现在把镜头放到栈桥协同的“签约与开通”：合同已经签了，账号为什么仍可能不能用？ 先读下面的经营底账，后续每一步都会复用这些数字与约束。
贯穿全课的虚构案例
栈桥协同
一家给中小设计机构提供项目协同 SaaS 的软件公司，客户购买账号后持续上传图纸、审批版本和工时；团队正在判断客户增长是否真的能覆盖云成本和客户成功投入。
- 付费客户
- 74 家企业、1,120 个付费账号企业合同数决定续费关系，账号数决定当期订阅金额，两者不能混成一个增长指标。
- 标准价格
- ¥69 / 账号 / 月客户按年预付可获得折扣，但合同期内仍要持续提供可用服务。
- 产品使用
- 月活账号 836 个，月活率 74.6%已经付费不等于真正使用；低活跃客户会在续费时集中暴露价值问题。
- 服务状态
- 本月可用性 99.97%，未关闭工单 23 个可用性说明系统整体状态，工单则暴露具体客户仍未解决的使用障碍。
客户为什么付钱
账号订阅费、超额存储与算力费、实施迁移费、高级支持服务费
钱在什么时候进来
订阅通常按年预收；实施费在启动和上线验收时分段收取，用量费次月按账单结算。
利润最容易被什么吃掉
云计算与存储、研发和测试人员、客户成功与技术支持、获客佣金和渠道分成
这笔业务怎样一步一步形成可交付结果
- 01签署年度合同可供“创建客户组织”使用的已确认的合同边界
- 02创建客户组织可供“配置席位权限”使用的经核对的账户状态
- 03配置席位权限可供“客户验收可用”使用的已验证的访问与权限状态
- 04客户验收可用60 个席位开通并通过客户验收
签署年度合同
在栈桥协同，团队先面对一条共同事实：“付费客户”为74 家企业、1,120 个付费账号。企业合同数决定续费关系，账号数决定当期订阅金额，两者不能混成一个增长指标。
确认 60 个席位与 ¥72,000 年费承诺
这一步真正要判断：线索判断与需求发现；成员与权限清单确认；开通、配置和数据迁移
如果本步没有形成“可供“创建客户组织”使用的已确认的合同边界”，下一步“创建客户组织”就没有可靠输入。
- 谁在参与
- 客户经理、客户管理员、实施顾问
- 关键记录
- 本步核对线索：订阅合同在处理前后的状态变化
- 形成产出
- 可供“创建客户组织”使用的已确认的合同边界
- 交给下一步
- 把“可供“创建客户组织”使用的已确认的合同边界”交给客户管理员和客户经理，继续处理“创建客户组织”。
如果没做好：风险观察：¥72,000 已形成应收依据——签约和开通支持开票，但不表示银行账户已经收到款项。
创建客户组织
上一步已经形成“可供“创建客户组织”使用的已确认的合同边界”。与此同时，案例里的“标准价格”为¥69 / 账号 / 月，客户按年预付可获得折扣，但合同期内仍要持续提供可用服务。
在系统中建立企业空间并导入成员
这一步真正要判断：成员与权限清单确认；线索判断与需求发现
如果本步没有形成“可供“配置席位权限”使用的经核对的账户状态”，下一步“配置席位权限”就没有可靠输入。
- 谁在参与
- 客户管理员、客户经理
- 关键记录
- 本步核对线索：服务开通在处理前后的状态变化
- 形成产出
- 可供“配置席位权限”使用的经核对的账户状态
- 交给下一步
- 把“可供“配置席位权限”使用的经核对的账户状态”交给客户管理员、实施顾问和计费专员，继续处理“配置席位权限”。
如果没做好：风险观察：软件服务真正可用——组织、账号、项目和权限均已配置，客户可以开始迁移真实工作。
配置席位权限
上一步已经形成“可供“配置席位权限”使用的经核对的账户状态”。与此同时，案例里的“产品使用”为月活账号 836 个，月活率 74.6%，已经付费不等于真正使用；低活跃客户会在续费时集中暴露价值问题。
核对 entitlement、身份与 RBAC 角色
这一步真正要判断：成员与权限清单确认；开通、配置和数据迁移；核对合同金额并开具账单与发票
如果本步没有形成“可供“客户验收可用”使用的已验证的访问与权限状态”，下一步“客户验收可用”就没有可靠输入。
- 谁在参与
- 客户管理员、实施顾问、计费专员
- 关键记录
- 本步核对线索：基于角色的访问控制在处理前后的状态变化
- 形成产出
- 可供“客户验收可用”使用的已验证的访问与权限状态
- 交给下一步
- 把“可供“客户验收可用”使用的已验证的访问与权限状态”交给客户管理员、客户经理和实施顾问，继续处理“客户验收可用”。
如果没做好：风险观察：合同与开通验收关联——60 席年度订阅有效，PROV-101 证明约定的基础服务已开通。
客户验收可用
上一步已经形成“可供“客户验收可用”使用的已验证的访问与权限状态”。与此同时，案例里的“服务状态”为本月可用性 99.97%，未关闭工单 23 个，可用性说明系统整体状态，工单则暴露具体客户仍未解决的使用障碍。
60 名成员均能进入对应项目，PROV-101 完成
这一步真正要判断：成员与权限清单确认；线索判断与需求发现；开通、配置和数据迁移
这是本章最后一项可核验产出，用来判断团队是否真的完成了“签约与开通”。
- 谁在参与
- 客户管理员、客户经理、实施顾问
- 关键记录
- 本步核对线索：服务授权在处理前后的状态变化
- 形成产出
- 60 个席位开通并通过客户验收
- 交给下一步
- 把结果带入“60 个席位开通并通过客户验收”，并回答：客户已经开始使用，发票开出后为什么还要继续跟进？
如果没做好：风险观察：实施与客户管理员共同验收——供应商负责配置和修复，客户管理员确认成员与业务权限是否正确。
案例结束时，不是因为所有人都完成了自己的动作就算成功，而是因为“60 个席位开通并通过客户验收”已经形成、证据可以追溯，并且客户管理员、客户经理和实施顾问能够解释结果怎样产生、风险怎样被控制。实施顾问与客户管理员核对成员清单和角色，修复 8 个权限映射；60 名成员均可访问对应项目，开通记录 PROV-101 完成。
章末经营结果
60 个席位开通并通过客户验收
实施顾问与客户管理员核对成员清单和角色，修复 8 个权限映射；60 名成员均可访问对应项目，开通记录 PROV-101 完成。
- 合同金额
- ¥72,000 / 年
- 授权席位
- 60 个
- 权限异常
- 8 → 0
换一个视角再看
同一笔业务，同时跑着四条线
业务流说明事情怎样发生，钱流解释收入、成本与现金，信息流留下共同事实，责任流决定谁执行、谁确认、谁承担后果。点击切换，观察同一章节怎样变化。
围绕“合同已经签了，账号为什么仍可能不能用？”，业务必须按依赖关系推进，不能把一串并行任务误当成已经交付。
- 01
签署年度合同 → 可供“创建客户组织”使用的已确认的合同边界
- 02
创建客户组织 → 可供“配置席位权限”使用的经核对的账户状态
- 03
配置席位权限 → 可供“客户验收可用”使用的已验证的访问与权限状态
- 04
客户验收可用 → 60 个席位开通并通过客户验收
出现这个信号要警惕：风险观察：¥72,000 已形成应收依据——签约和开通支持开票，但不表示银行账户已经收到款项。
岗位、记录与业务语言
一家公司靠什么把多人协作变成同一个结果
岗位不是孤立的名称，记录也不是多余的表格。前者分配判断与责任，后者让不同人能够核对同一件事是否真的发生。
谁负责什么，结果交给谁
| 角色 | 本章负责 | 最关心 | 交给谁 |
|---|---|---|---|
| 业务职能销售与商机管理 | 提供本章所需的约束、输入或审批 | 识别值得投入的企业机会，推进从需求发现到合同与续费的商业关系；重点关注：目标客户与商机资格判断 | 下一章节或业务结果的接收方 |
| 业务职能实施与交付 | 提供本章所需的约束、输入或审批 | 把合同约定转成正确的组织、账号、权限和数据配置，并推动客户完成验收；重点关注：实施计划、配置与数据迁移 | 下一章节或业务结果的接收方 |
| 外部参与者客户管理员 | 签署年度合同、创建客户组织、配置席位权限、客户验收可用 | 维护本企业成员、项目和权限配置，并验收账号是否符合真实工作需要；重点关注：成员与权限清单确认 | 客户经理、实施顾问、计费专员 |
| 业务职能计费与财务 | 提供本章所需的约束、输入或审批 | 根据合同开票、管理应收和回款，并保证金额、客户和订阅记录一致；重点关注：合同计费、开票和应收管理 | 下一章节或业务结果的接收方 |
| 代表岗位客户经理 | 签署年度合同、创建客户组织、客户验收可用 | 识别合适客户、推进商业沟通，并对自己写进承诺的内容负责；重点关注：线索判断与需求发现 | 客户管理员、实施顾问、计费专员 |
| 代表岗位实施顾问 | 签署年度合同、配置席位权限、客户验收可用 | 完成组织、账号和权限配置，帮助客户把合同范围变成可使用状态；重点关注：开通、配置和数据迁移 | 客户管理员、客户经理 |
| 代表岗位计费专员 | 配置席位权限 | 依据合同创建账单和发票，跟踪应收、回款与订阅记录是否一致；重点关注：核对合同金额并开具账单与发票 | 客户管理员、客户经理、实施顾问 |
哪些记录能证明业务真的发生了
| 业务记录 | 在哪产生 | 谁形成 | 证明什么 | 下一步怎么用 |
|---|---|---|---|---|
| 本步核对线索：订阅合同在处理前后的状态变化 | 签署年度合同 | 客户经理、客户管理员和实施顾问 | 可供“创建客户组织”使用的已确认的合同边界 | 创建客户组织 |
| 本步核对线索：服务开通在处理前后的状态变化 | 创建客户组织 | 客户管理员和客户经理 | 可供“配置席位权限”使用的经核对的账户状态 | 配置席位权限 |
| 本步核对线索：基于角色的访问控制在处理前后的状态变化 | 配置席位权限 | 客户管理员、实施顾问和计费专员 | 可供“客户验收可用”使用的已验证的访问与权限状态 | 客户验收可用 |
| 本步核对线索：服务授权在处理前后的状态变化 | 客户验收可用 | 客户管理员、客户经理和实施顾问 | 60 个席位开通并通过客户验收 | 60 个席位开通并通过客户验收 |
本章术语：先用白话理解，再回到正式定义
- Subscription Contract订阅合同
- 白话：约定客户在一定周期内获得软件访问和服务，并按席位或方案付费的商业承诺。
- 正式定义：约定客户在一定周期内获得软件访问和服务，并按席位或方案付费的商业承诺。
- 放进业务里：客户以 ¥72,000 购买 60 席一年的软件服务。
- Provisioning服务开通
- 白话：按照合同授权创建组织、账号、席位和初始配置，使客户真正获得服务。
- 正式定义：按照合同授权创建组织、账号、席位和初始配置，使客户真正获得服务。
- 放进业务里：PROV-101 把 60 席合同转成 60 个可登录并有正确权限的成员账号。
- RBAC基于角色的访问控制
- 白话：按成员承担的角色决定其可查看和可操作内容的权限管理方式。
- 正式定义：按成员承担的角色决定其可查看和可操作内容的权限管理方式。
- 放进业务里：设计师可编辑项目文件，外部审阅者只能查看和评论。
- Entitlement服务授权
- 白话：合同赋予某个客户组织或账号使用哪些产品、数量和期限的可执行权利记录。
- 正式定义：合同赋予某个客户组织或账号使用哪些产品、数量和期限的可执行权利记录。
- 放进业务里：设计公司拥有 60 个年度席位 entitlement。
新手最容易误解的地方
先共享管理员账号让大家使用
为什么不对：共享账号会让操作无法追责，也可能暴露不该看到的项目。
应该继续追问：如果改成“核对席位、成员和角色后修复映射”，需要谁确认、留下什么证据？
组织已创建，直接把交付标为完成
为什么不对：交付完成要看客户能否按约使用，而不是后台是否出现一条组织记录。
应该继续追问：如果改成“核对席位、成员和角色后修复映射”，需要谁确认、留下什么证据？
“签署年度合同”只要动作做完，就可以直接进入下一步。
为什么不对：风险观察：¥72,000 已形成应收依据——签约和开通支持开票，但不表示银行账户已经收到款项。
应该继续追问：是否已经形成“可供“创建客户组织”使用的已确认的合同边界”，并留下“本步核对线索：订阅合同在处理前后的状态变化”供下一步核对？
“创建客户组织”只要动作做完，就可以直接进入下一步。
为什么不对：风险观察：软件服务真正可用——组织、账号、项目和权限均已配置，客户可以开始迁移真实工作。
应该继续追问：是否已经形成“可供“配置席位权限”使用的经核对的账户状态”，并留下“本步核对线索：服务开通在处理前后的状态变化”供下一步核对？
先复盘，再做判断
现在，试着不用页面原话把这一章讲出来
- 为什么本章必须先做“签署年度合同”，如果跳过会影响哪一步？
- 在“创建客户组织”中，谁执行、谁提供约束，应该留下什么记录？
- 本章怎样影响账号订阅费、超额存储与算力费、实施迁移费和高级支持服务费？结合“订阅通常按年预收；实施费在启动和上线验收时分段收取，用量费次月按账单结算。”判断它何时才会形成收入或现金。
- 如果只看到“60 个席位开通并通过客户验收”的口头结论，你还会要求核对哪些业务记录？
8 名成员没有正确权限，应该怎样处理？
合同和 60 个席位授权都有效；组织已创建，问题集中在用户角色与项目权限的映射。