成果
双方能否用一句话说明业务成果？
使用客户语言描述成果，并关联到首次价值指标。启动准备与决策检查清单
Customer implementation kickoff checklist for accepted scope and owned actions
使用检查清单解决造成启动会反复讨论的缺口：成果不清、客户资料缺失、角色不确定、隐藏假设及无人负责的行动。
这是一份与客户计划相连的就绪工作清单，而不是静态会议议程。
最多 5 名用户可免费使用，无需信用卡。
无需编程即可调整字段、工作流和仪表板。 探索 1,000 多个应用模板和业务场景
- 邀请客户前先核实交接
- 区分启动会前要求与会议决策
- 立即将决策转化为有日期的工作
避免无准备启动的七项就绪检查
启动会应建立共同责任，而不是现场发现销售承诺。
范围
纳入的工作是否已获验收？排除项是否清晰可见？
实施团队无需猜测即可验收交接。人员
是否已指定发起人、日常负责人、技术负责人、审批人及实施负责人？
每项关键决策都有明确的参与者。资料
所需数据、文档、访问权限及决策是否已列明负责人和日期？
客户与内部团队的责任可以清晰区分。依赖关系
计划是否显示每项资料推动哪个里程碑？
资料延迟造成的交付影响清晰可见。风险
已知约束、假设及待确认问题是否已记录？
重大不确定事项有明确负责人及下一决策。首批行动
会议结束时，是否会形成注明日期的行动及下一控制点？
每项行动只有一位责任人和一个截止日期。利用启动会将背景信息转化为决策
分别记录会前获得的资料、会上作出的决定及后续行动。
销售与实施团队 → 客户参会者
已验收成果、范围、时间表、角色、已知风险及所需准备。
主持人 → 决策人
已确认的治理方式、工作流、资料、决策及升级路径。
实施经理 → 所有相关责任人
决策日志、行动、截止日期、依赖关系及下次评审。
只提出答案会影响交付的问题
检查清单更长并不代表更安全。
角色问题
应保留
谁能作出决定、谁提供资料、谁批准上线、谁负责交付？
应避免
只有冗长的参会名单，却没有决策权限。
时间表问题
应保留
目标日期、硬性约束、客户业务冻结期及依赖关系。
应避免
在未明确达成所需工作的情况下随意选择日期。
技术问题
应保留
只收集与本次服务约定相关的集成、数据、安全、访问及环境资料。
应避免
向每位客户发送通用技术问卷。
成功标准问题
应保留
首个可观察的业务成果，以及确认该成果的方式。
应避免
只有“成功上线”，却没有客户成果。
准备、主持并完成闭环
只有所有未决事项都转化为有人负责的工作，检查清单才算完成。
解决可以避免的缺口
- 核查交接验收及缺失的背景信息。
- 针对客户必须完成的准备工作发送聚焦的请求。
确认决策与责任
- 只讨论需要双方共同达成一致的事项。
- 在会上实时记录决策、风险、行动、负责人及截止日期。
发布工作计划
- 将行动与依赖关系转化为记录。
- 将尚未解决的范围或承诺问题退回给相应负责人。
检查运营节奏是否有效
- 核查客户资料等待时长及阻塞恢复情况。
- 移除不会推动行动的检查项。
启动会前的常见问题
客户实施启动检查清单应包含什么？
应包含已验收成果与范围、利益相关者与决策权限、时间限制、客户和内部所需资料、工作流、风险、沟通节奏、升级路径、首批行动及首次价值定义。
每个检查项都必须填写吗？
不需要。只要求填写该服务约定类型与风险所必需的信息。利用条件字段和路由，可以在需要时收集专业信息，同时保持简短的客户体验。
尚未解决的启动会事项应如何处理？
创建注明截止日期和依赖关系、责任明确的行动、客户资料、阻塞事项或决策记录。不要让未决工作只留在会议记录中。
在下一次真实启动会中使用该清单，而不是把它作为存档文档
打开已填充数据的交接与启动会视图，用一位真实客户替换示例背景，并测试每项未决事项能否转化为责任明确的工作。