gtm-enterprise-onboarding

企业客户入驻

从签约到价值实现的企业客户入驻四阶段框架。目标不仅仅是上线——而是持续采用，且不会在第 12 周断崖式下跌。

何时使用

触发场景：

• “我们该如何让这家企业客户入驻？”
• “客户已经上线，但采用率很低”
• “我们总是在上线 3 个月后流失客户”
• “从 POC 到生产的过渡”
• “如何防止第 4 周失联？”
• “客户成功入驻框架”

背景：

• 企业或中端市场交易
• 复杂的技术要求
• 涉及多个利益相关方
• 30-90 天的实施周期
• 第一年内存在流失风险

---

核心框架

1. 第 4 周失联问题（以及如何预防）

模式：

第 1 周：启动会非常顺利。大家都很兴奋。 第 2-3 周：技术调研、需求收集。仍然不错。 第 4 周：客户不再回复。会议被取消。“太忙了。”

发生了什么？

你在客户内部达成一致之前就开始了客户入驻。

客户内部谁负责这个项目？

• 销售代表？（已经转向下一笔交易）
• 技术支持者？（日常工作占用了时间）
• 高管发起人？（只做委派，不推动）
• 没有人？（这就是他们失联的原因）

框架：内部负责人验证

在启动会之前，回答：

客户方谁将：

• 参加每周项目会议？（不是“被邀请”——而是真的会出席）
• 推动解决采购/法务/安全问题？（有权限）
• 推动最终用户采用？（有影响力）
• 在事情停滞时升级处理？（能接触高管）

如果你无法为每一项说出一个具体的人，你就没有项目负责人。你只有一份没人推动的已签合同。

如何解决：

在销售 → CS 交接期间（客户启动会之前）：

销售代表必须确认：

• 主要项目负责人（姓名，而不是角色）
• 其投入程度（专职还是副业项目？）
• 其权限（能否推动解决问题？）
• 其动机（对他们有什么好处？）

如果没有明确的负责人：

先不要开始入驻。让销售把你介绍给经济买家：

“在我们启动实施之前，我们希望确保贵方有合适的项目负责人。根据我们的经验，当有人负责逐周推进时，实施就会成功。贵方团队中我们应该与谁合作？”

常见错误：

假设有人会负责。要明确询问。如果他们无法说出具体的人，这笔交易就有风险。

---

2. 采用悬崖（第 12 周问题）

模式：

第 6 周上线。使用量激增。你庆祝一番。

第 8 周：使用量进入平台期。 第 10 周：使用量下滑。 第 12 周：使用量较峰值下降 50%。

为什么会发生这种情况：

你把上线当成了终点线。上线是起跑线。

什么驱动了持续采用：

不是： 功能完备性、技术集成、培训课程

是： 持续的价值展示、用户成功案例、不断扩展的使用场景

框架：上线之后的采用阶段

第 1-6 周（实施）： 让它运转起来

• 衡量指标：技术设置完成百分比
• 负责人：技术负责人

第 6-12 周（初期采用）： 让人们用起来

• 衡量指标：活跃用户数、使用频率
• 负责人：赋能 / DevRel

第 12-26 周（持续采用）： 证明持续价值

• 衡量指标：使用场景扩展、团队扩散
• 负责人：客户成功

第 26 周以后（扩展）： 在客户内部增长

• 衡量指标：新团队、新使用场景、升级触发点
• 负责人：客户经理 + CS

大多数团队遗漏的交接：

第 6 周（上线）→ 第 12 周（持续采用）

大多数 CS 团队庆祝上线后就转向下一个客户。这正是流失种子被埋下的时候。

第 6-12 周该做什么：

第 7 周： 首份价值报告 “以下是你的团队在第一周取得的成果：[具体指标]。以下是第 12 周的良好状态应该是什么样：[目标]。”

第 9 周： 用户成功案例 “[用户名] 在 [团队名称] 本周节省了 [X 小时 / 减少了 Y 个错误]。以下是他们的使用方式。”

第 11 周： 使用场景扩展对话 “你在用我们处理 [主要使用场景]。像你这样的团队还使用我们处理 [相邻使用场景]。想探索一下吗？”

常见错误：

衡量“上线完成度”而不是“持续活跃使用”。上线不是成功。第 26 周仍留存的采用才是成功。

---

3. 入职前准备：成功在第一次客户通话之前就已建立

模式：

大多数入职失败都可以追溯到启动会之前的缺口。

容易被遗漏的事项：

销售没有向 CS 做好交接：

• 成交驱动因素未知
• 利益相关者动态不清晰
• 技术需求被假定

没有确定内部项目负责人：

• CS 主动联系，无人回应
• 会议安排给了错误的人
• 决策无法落实

客户时间线不现实：

• 他们希望 2 周内上线
• 技术设置至少需要 6 周
• 从第一天起期望就错位

框架：启动会前检查清单

在安排启动会通话之前，验证：

客户情报：

• 销售交接已完成（成交驱动因素、利益相关者、技术需求）
• 过往互动已审阅（演示笔记、提案、邮件）
• 组织结构已梳理（团队规模、汇报关系）
• 使用场景已记录（主要 + 未来）

内部准备：

• 已创建内部 Slack 频道（#account-[customer-name]）
• 已在 CRM 中更新客户计划
• 项目计划模板已准备
• 已分配角色（CSM 负责人、技术负责人、高管赞助人）

客户就绪情况：

• 项目负责人已明确到姓名（不只是“他们的 DevRel 团队”）
• 双方的高管赞助人已确认
• 时间线现实可行（他们的目标 vs 你的典型时间线）
• 已知阻碍已记录（采购、安全、法务）

时间线验证：

• 考虑到技术需求，客户的上市日期现实可行
• 内部产能可用（未被超额占用）
• 依赖项已识别（SSO、集成、数据迁移）

决策标准：

只有当四个部分全部验证通过后才安排启动会。如果存在缺口，在接触客户之前先向销售或高管赞助人提出。

常见错误：

在内部不清晰的情况下开始入职。这会造成混乱、错过截止日期，并侵蚀客户信心。

---

4. 四阶段上手流程

阶段 1：启动会（第 1 周）

目标： 在目标、时间线和成功指标上达成一致

参会者： 高管发起人 + 项目负责人 + 技术负责人

议程：

1. 介绍与角色分工（5 分钟）
2. 高管就战略目标达成一致（5 分钟）
3. 定义成功：“3/6/12 个月后，成功是什么样子？”（10 分钟）
4. 时间线与里程碑（5 分钟）
5. 会议节奏（每周项目团队会、每月高管评审）（5 分钟）
6. 后续步骤（技术探索电话会议、成功计划评审）（5 分钟）

交付物： 24 小时内发送启动会纪要，包含成功指标、时间线、后续会议安排

阶段 2：探索与规划（第 2-3 周）

目标： 了解技术环境、梳理用例、规划推广

三条并行工作流：

工作流 1：技术探索

• 当前基础设施（本地部署、云、混合）
• 现有工具与集成
• 安全/合规要求
• 时间线约束

工作流 2：成功规划

• 用例优先级排序（从最高价值开始）
• 定义成功指标（如何衡量采用情况）
• 确定培训需求（谁需要什么）

工作流 3：技术配置

• SSO/身份配置
• 所需集成
• 数据迁移（如适用）
• 确定试点小组

交付物： 客户成功计划文档，包含用例、指标、时间线、里程碑

阶段 3：实施（第 4-6 周）

目标： 部署到试点小组、验证用例、为更大范围推广做准备

三条并行轨道：

轨道 1：管理与配置

• 完成 SSO 配置
• 集成上线
• 数据迁移完成（如适用）

轨道 2：用户赋能

• 为试点小组开展培训
• 共享文档
• 安排答疑时间

轨道 3：试点与反馈

• 试点小组使用产品
• 每周收集反馈
• 问题分诊与解决

交付物： 完成上线准备清单、试点小组验证通过

阶段 4：上线与持续成功（第 6 周起）

目标： 广泛推广、维持采用、扩展用例

第 6-8 周（推广）：

• 向所有团队广泛推广
• 安排培训
• 提供支持（Slack、邮件、答疑时间）

第 8-12 周（价值展示）：

• 首份价值报告（第 7 周）
• 分享用户成功案例（第 9 周）
• 用例扩展讨论（第 11 周）

第 12-26 周（持续采用）：

• 每月业务评审
• 采用情况跟踪（活跃用户、使用频率、用例）
• 识别扩展机会

常见错误：

把上线当作终点。阶段 4 才是决定留存成败的关键。

---

5. 并行轨道反模式

模式：

大多数上手团队按顺序执行各工作流：

1. 技术配置（第 1-2 周）
2. 然后培训（第 3-4 周）
3. 然后试点（第 5-6 周）

总时长：6 周

更好的做法：并行轨道

同时进行技术配置、培训和试点：

• 第 1 周：技术探索 + 确定试点小组 + 安排培训
• 第 2 周：SSO 配置 + 试点小组培训 + 试点启动
• 第 3 周：集成 + 更广泛培训 + 试点反馈

总时长：3 周

并行为何有效：

1. 缩短价值实现时间
2. 保持客户参与（每周都有进展）
3. 尽早发现阻碍（试点小组在广泛推广前暴露问题）

如何执行：

为每条轨道指定明确的负责人：

• 轨道 1（管理）：技术负责人
• 轨道 2（赋能）：培训/DevRel 负责人
• 轨道 3（试点）：CSM + 试点小组倡导者

每周跨轨道同步，以发现依赖关系和阻碍。

常见错误：

在启动试点前等待“完美的技术配置”。尽早让试点小组使用，即使配置还不完美。他们的反馈会让广泛推广做得更好。

---

决策树

我是否应该启动客户上手？

Has sales identified a project owner by name?
├─ No → Get project owner identified before kickoff
└─ Yes → Continue...
    │
    Is their timeline realistic given typical deployment?
    ├─ No → Reset expectations before kickoff
    └─ Yes → Continue...
        │
        Do you have internal capacity?
        ├─ No → Delay kickoff or get more resources
        └─ Yes → Proceed to kickoff

这次上手是否有风险？

Is customer responding to meeting invites?
├─ No → Week 4 ghosting, escalate to exec sponsor
└─ Yes → Continue...
    │
    Are they completing their action items?
    ├─ No → No project owner, identify who drives this
    └─ Yes → Continue...
        │
        Is pilot group using the product?
        ├─ No → Pilot group wrong or product not solving pain
        └─ Yes → On track

上线后采用是否持续？

Are active users growing Week 6 → Week 12?
├─ Yes → Healthy adoption
└─ No → Continue...
    │
    Are active users declining?
    ├─ Yes → Adoption cliff, intervene immediately
    └─ No (plateau) → At risk, start value demonstration

---

常见错误

1. 在内部对齐之前就启动客户入驻

• 浪费前 2-3 周，造成混乱，损害可信度

2. 没有提前确定真正的项目负责人

• 到第 4 周才发现，不得不重启或交易停滞

3. 在没有技术需求的情况下对时间线过度承诺

• 在实施中途发现阻碍，错过截止日期

4. 没有内部沟通中心

• 决策无法在各团队之间传播，导致返工

5. 把上线当作项目完成

• 第 12 周出现采用率断崖，账户面临风险

6. 采用串行推进而非并行推进

• 实施时间翻倍，客户失去动力

7. 上线后没有持续指标

• 发现采用问题时已太晚，无法挽救账户

---

快速参考

启动前验证：

• 销售交接完成（交易驱动因素、利益相关者、需求）
• 客户侧项目负责人已按姓名确定
• 时间线现实可行（他们的目标 vs 典型部署）
• 内部角色已分配（CSM、技术、执行发起人）

启动会议议程（30-45 分钟）：

1. 介绍（5 分钟）
2. 管理层对齐（5 分钟）
3. 成功定义（10 分钟）
4. 时间线和里程碑（5 分钟）
5. 会议节奏（5 分钟）
6. 后续步骤（5 分钟）

采用跟踪（第 6-26 周）：

• 第 7 周：首次价值报告
• 第 9 周：用户成功案例
• 第 11 周：用例扩展对话
• 第 13 周：首次月度业务回顾
• 第 26 周：扩展准备度评估

四个阶段：

1. 启动（第 1 周）：对齐
2. 探索（第 2-3 周）：规划
3. 实施（第 4-6 周）：部署到试点
4. 上线与持续（第 6 周起）：推广、价值展示、扩展

危险信号：

• 客户在第 4 周不回应 → 没有项目负责人
• 试点小组在第 5 周不使用产品 → 错误的小组或错误的用例
• 活跃用户在第 8-12 周下降 → 采用率断崖正在形成

---

相关技能

• enterprise-account-planning：售前交易规划和利益相关者映射
• operating-cadence：入驻回顾节奏和健康指标
• product-led-growth：自助式入驻模式

---

基于多家平台公司的企业入驻经验——直接设计合作伙伴入驻，并与 CS 在客户入驻方面密切协作。这不是理论——而是来自反复看到第 4 周失联现象，并认识到上线 ≠ 成功，以及理解采用率断崖如何在第一年杀死 30% 交易的教训。