Back to Details

gtm-enterprise-onboarding

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Enterprise Onboarding

企业客户入职

Four-phase framework for onboarding enterprise customers from contract to value realization. The goal isn't just go-live — it's sustained adoption that doesn't cliff at Week 12.
一套帮助企业客户从签约到价值实现的四阶段入职框架。我们的目标不只是完成上线——而是实现可持续的用户采用，避免在第12周出现采用率骤降的情况。

When to Use

适用场景

Triggers:
  • "How do we onboard this enterprise customer?"
  • "Customer went live but adoption is weak"
  • "We keep losing customers 3 months after go-live"
  • "POC to production transition"
  • "How do I prevent Week 4 ghosting?"
  • "Customer success onboarding framework"
Context:
  • Enterprise or mid-market deals
  • Complex technical requirements
  • Multiple stakeholders involved
  • 30-90 day implementation timelines
  • Risk of churn during first year
触发场景：
  • "我们该如何为这个企业客户提供入职服务？"
  • "客户已经上线，但用户采用率很低"
  • "我们总是在客户上线3个月后失去他们"
  • "从POC到生产环境的过渡"
  • "如何防止第4周客户失联？"
  • "客户成功入职框架"
适用背景：
  • 企业或中大型客户交易
  • 复杂的技术需求
  • 涉及多个利益相关方
  • 30-90天的实施周期
  • 第一年存在客户流失风险

Core Frameworks

核心框架

1. The Week 4 Ghosting Problem (And How to Prevent It)

1. 第4周失联问题（及预防方案）

The Pattern:
Week 1: Kickoff call goes great. Everyone's excited. Week 2-3: Technical discovery, requirements gathering. Still good. Week 4: Customer stops responding. Meetings get cancelled. "Too busy."
What Happened?
You started customer onboarding before internal alignment on their side.
Who Owns This Project Internally?
  • Sales rep? (Already moved to next deal)
  • Technical champion? (Day job took over)
  • Executive sponsor? (Delegates, doesn't drive)
  • Nobody? (This is why they're ghosting)
The Framework: Internal Owner Validation
Before kickoff call, answer:
Who on customer side will:
  • Attend weekly project meetings? (Not "invited" — will actually show up)
  • Unblock issues with procurement/legal/security? (Has authority)
  • Drive adoption with end users? (Has influence)
  • Escalate when things stall? (Has executive access)
If you can't name a specific person for each, you don't have a project owner. You have a signed contract with nobody driving it.
How to Fix It:
During sales → CS handoff (before customer kickoff):
Sales rep must identify:
  • Primary project owner (name, not role)
  • Their capacity (dedicated or side project?)
  • Their authority (can they unblock?)
  • Their motivation (what's in it for them?)
If there's no clear owner:
Don't start onboarding yet. Have sales introduce you to economic buyer:
"Before we kick off implementation, we want to make sure we have the right project owner on your side. In our experience, implementations succeed when someone owns driving this forward week-to-week. Who on your team should we partner with?"
Common Mistake:
Assuming someone will own it. Ask explicitly. If they can't name someone, the deal is at risk.
典型模式：
Week 1: Kickoff call goes great. Everyone's excited. Week 2-3: Technical discovery, requirements gathering. Still good. Week 4: Customer stops responding. Meetings get cancelled. "Too busy."
问题根源：
你在客户内部达成共识之前就启动了入职流程。
客户内部谁真正负责这个项目？
  • 销售代表？（已经转向下一个交易）
  • 技术负责人？（日常工作占据了精力）
  • 执行发起人？（只做委派，不推动执行）
  • 没人负责？（这就是他们失联的原因）
解决框架：内部负责人验证
在启动会议前，确认以下问题：
客户侧谁将负责：
  • 出席每周项目会议？（不是“被邀请”——而是确实会到场）
  • 解决采购/法务/安全方面的障碍？（拥有决策权）
  • 推动终端用户的采用？（具备影响力）
  • 遇到停滞时进行升级上报？（能接触到高管）
如果你无法为每个岗位指定具体的人，那你就没有真正的项目负责人——只是签了合同，但没人推动执行。
修复方案：
在销售→客户成功交接阶段（客户启动会议前）：
销售代表必须明确：
  • 主要项目负责人（姓名，而非职位）
  • 他们的时间投入（专职负责还是兼职项目？）
  • 他们的权限（能否解决障碍？）
  • 他们的动力（能从中获得什么？）
如果没有明确的负责人：
不要启动入职流程。让销售将你介绍给经济买家：
"在我们启动实施之前，我们希望确保贵方有合适的项目负责人。根据我们的经验，当有人每周推动项目进展时，实施才能成功。我们应该与贵团队的哪位成员合作？"
常见错误：
假设会有人负责这个项目。要明确询问。如果他们无法指定具体人员，这笔交易就存在风险。

2. The Adoption Cliff (Week 12 Problem)

2. 采用率骤降问题（第12周陷阱）

The Pattern:
Go-live happens Week 6. Usage spikes. You celebrate.
Week 8: Usage plateaus. Week 10: Usage declining. Week 12: Usage down 50% from peak.
Why This Happens:
You treated go-live as the finish line. Go-live is the starting line.
What Drives Sustained Adoption:
Not: Feature completeness, technical integration, training sessions
Yes: Ongoing value demonstration, user success stories, expanding use cases
Framework: Adoption Stages Beyond Go-Live
Week 1-6 (Implementation): Get it working
  • Measure: % of technical setup complete
  • Owner: Technical lead
Week 6-12 (Initial Adoption): Get people using it
  • Measure: # active users, frequency of use
  • Owner: Enablement / DevRel
Week 12-26 (Sustained Adoption): Prove ongoing value
  • Measure: Use case expansion, team spread
  • Owner: Customer success
Week 26+ (Expansion): Grow within account
  • Measure: New teams, new use cases, upgrade triggers
  • Owner: Account executive + CS
The Handoff That Most Teams Miss:
Week 6 (go-live) → Week 12 (sustained adoption)
Most CS teams celebrate go-live and move to next customer. This is when churn seeds get planted.
What to Do Week 6-12:
Week 7: First value report "Here's what your team accomplished in the first week: [specific metric]. Here's what good looks like at Week 12: [target]."
Week 9: User success story "[User name] on [team name] saved [X hours/reduced Y errors] this week. Here's how they're using it."
Week 11: Use case expansion conversation "You're using us for [primary use case]. Teams like yours also use us for [adjacent use case]. Want to explore?"
Common Mistake:
Measuring "go-live completion" instead of "sustained active usage." Go-live is not success. Week 26 retained adoption is success.
典型模式：
第6周完成上线，用户使用量激增，你以为成功了。
第8周：使用量进入平台期。 第10周：使用量开始下降。 第12周：使用量较峰值下降50%。
问题根源：
你把上线当成了终点。上线其实是起点。
驱动持续采用的关键：
**不是：**功能完整性、技术集成、培训课程
**而是：**持续的价值展示、用户成功案例、拓展使用场景
解决框架：上线后的采用阶段划分
第1-6周（实施阶段）：让产品可用
  • 衡量指标：技术设置完成率
  • 负责人：技术主管
第6-12周（初始采用阶段）：让用户开始使用
  • 衡量指标：活跃用户数、使用频率
  • 负责人：赋能团队/DevRel
第12-26周（持续采用阶段）：证明持续价值
  • 衡量指标：使用场景拓展、团队覆盖范围
  • 负责人：客户成功团队
第26周以后（拓展阶段）：在客户内部拓展
  • 衡量指标：新团队接入、新使用场景、升级触发点
  • 负责人：客户经理 + 客户成功团队
大多数团队忽略的交接环节：
第6周（上线）→第12周（持续采用）
大多数客户成功团队庆祝上线后就转向下一个客户。这正是客户流失的种子被埋下的时候。
第6-12周的行动要点：
第7周：第一份价值报告 “这是你的团队第一周完成的成果：[具体指标]。第12周的理想状态是：[目标]。”
第9周：用户成功案例 “[用户名]所在的[团队名]本周节省了[X小时/减少了Y个错误]。以下是他们的使用方式。”
第11周：使用场景拓展沟通 “你们目前将我们的产品用于[主要使用场景]。类似的团队还将我们的产品用于[相关场景]。要不要一起探索？”
常见错误：
衡量“上线完成率”而非“持续活跃使用量”。上线不是成功的标志。第26周仍保持的采用率才是成功。

3. Pre-Onboarding: Success Is Built Before First Customer Call

3. 入职前准备：成功在第一次客户会议前就已奠定

The Pattern:
Most onboarding failures trace back to pre-kickoff gaps.
What Gets Missed:
Sales didn't brief CS properly:
  • Deal drivers unknown
  • Stakeholder dynamics unclear
  • Technical requirements assumed
No internal project owner identified:
  • CS reaches out, nobody responds
  • Meetings get scheduled with wrong people
  • Decisions don't stick
Customer timeline unrealistic:
  • They want go-live in 2 weeks
  • Technical setup takes 6 weeks minimum
  • Expectations misaligned from Day 1
Framework: Pre-Kickoff Checklist
Before scheduling kickoff call, validate:
Account Intelligence:
  • Sales handoff completed (deal drivers, stakeholders, technical requirements)
  • Past interactions reviewed (demo notes, proposal, emails)
  • Organizational structure mapped (team sizes, reporting lines)
  • Use cases documented (primary + future)
Internal Setup:
  • Internal Slack channel created (#account-[customer-name])
  • Account plan updated in CRM
  • Project plan template prepared
  • Roles assigned (CSM lead, technical lead, exec sponsor)
Customer Readiness:
  • Project owner identified by name (not just "their DevRel team")
  • Executive sponsor confirmed on both sides
  • Timeline realistic (their goals vs your typical timeline)
  • Known blockers documented (procurement, security, legal)
Timeline Validation:
  • Customer's go-live date is realistic given technical requirements
  • Internal capacity available (not overbooked)
  • Dependencies identified (SSO, integrations, data migration)
Decision Criteria:
Only schedule kickoff when all four sections validated. If gaps exist, surface to sales or executive sponsor before engaging customer.
Common Mistake:
Starting onboarding without internal clarity. This creates confusion, missed deadlines, and erosion of customer confidence.
典型模式：
大多数入职失败都可以追溯到启动会议前的漏洞。
被忽略的要点：
销售未向客户成功团队充分交底：
  • 交易驱动因素未知
  • 利益相关方动态不明确
  • 技术需求被假设
未明确内部项目负责人：
  • 客户成功团队联系时，无人回复
  • 会议安排给了错误的人
  • 决策无法落地
客户时间线不切实际：
  • 他们希望2周内上线
  • 技术设置至少需要6周
  • �从第一天起就存在预期偏差
解决框架：启动前检查清单
在安排启动会议前，验证以下内容：
客户信息收集：
  • 销售交接完成（交易驱动因素、利益相关方、技术需求）
  • 过往互动记录已查看（演示笔记、提案、邮件）
  • 组织结构已梳理（团队规模、汇报线）
  • 使用场景已记录（主要+未来）
内部准备：
  • 创建内部Slack频道（#account-[客户名称]）
  • CRM中的客户计划已更新
  • 项目计划模板已准备
  • 角色已分配（客户成功主管�、技术主管、执行发起人）
客户就绪状态：
  • 已明确项目负责人姓名（而非“他们的DevRel团队”）
  • 双方执行发起人已确认
  • 时间线切合实际（他们的目标 vs 我们的典型时间线）
  • 已知障碍已记录（采购、安全、法务）
时间线验证：
  • 客户的上线日期符合技术需求的实际情况
  • 内部有足够的产能（未过度排期）
  • 已识别依赖项（SSO、集成、数据迁移）
决策标准：
只有当四个部分都验证通过后，才安排启动会议。如果存在漏洞，在联系客户前告知销售或执行发起人。
常见错误：
在内部未达成共识的情况下启动入职流程。这会造成混乱、错过截止日期，并削弱客户信心。

4. The Four-Phase Onboarding Flow

4. 四阶段入职流程

Phase 1: Kickoff (Week 1)
Goal: Align on objectives, timeline, success metrics
Attendees: Executive sponsors + project leads + technical leads
Agenda:
  1. Introductions and roles (5 min)
  2. Executive alignment on strategic objectives (5 min)
  3. Success definition: "What does success look like in 3/6/12 months?" (10 min)
  4. Timeline and milestones (5 min)
  5. Meeting cadence (weekly project team, monthly exec review) (5 min)
  6. Next steps (technical discovery call, success plan review) (5 min)
Deliverable: Kickoff recap sent within 24 hours with success metrics, timeline, next meetings
Phase 2: Discovery & Planning (Week 2-3)
Goal: Understand technical landscape, map use cases, plan rollout
Three parallel workstreams:
Workstream 1: Technical Discovery
  • Current infrastructure (on-prem, cloud, hybrid)
  • Existing tools and integrations
  • Security/compliance requirements
  • Timeline constraints
Workstream 2: Success Planning
  • Use cases prioritized (start with highest-value)
  • Success metrics defined (how to measure adoption)
  • Training needs identified (who needs what)
Workstream 3: Technical Setup
  • SSO/identity configuration
  • Integrations required
  • Data migration (if applicable)
  • Pilot group identified
Deliverable: Customer Success Plan document with use cases, metrics, timeline, milestones
Phase 3: Implementation (Week 4-6)
Goal: Deploy to pilot group, validate use cases, prepare for broader rollout
Three parallel tracks:
Track 1: Administration & Setup
  • SSO configuration complete
  • Integrations live
  • Data migrated (if applicable)
Track 2: User Enablement
  • Training sessions for pilot group
  • Documentation shared
  • Office hours scheduled
Track 3: Pilot & Feedback
  • Pilot group using product
  • Feedback collected weekly
  • Issues triaged and resolved
Deliverable: Go-live readiness checklist completed, pilot group validated
Phase 4: Go-Live & Ongoing Success (Week 6+)
Goal: Roll out broadly, sustain adoption, expand use cases
Week 6-8 (Rollout):
  • Broader rollout to all teams
  • Training sessions scheduled
  • Support available (Slack, email, office hours)
Week 8-12 (Value Demonstration):
  • First value report (Week 7)
  • User success stories shared (Week 9)
  • Use case expansion conversation (Week 11)
Week 12-26 (Sustained Adoption):
  • Monthly business reviews
  • Adoption tracking (active users, frequency, use cases)
  • Expansion opportunities identified
Common Mistake:
Treating go-live as completion. Phase 4 is where retention is won or lost.
阶段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. The Parallel Tracks Anti-Pattern

5. 串行工作流反模式

The Pattern:
Most onboarding teams run workstreams sequentially:
  1. Technical setup (Weeks 1-2)
  2. Then training (Weeks 3-4)
  3. Then pilot (Weeks 5-6)
Total time: 6 weeks
What Works Better: Parallel Tracks
Run technical setup, training, and pilot simultaneously:
  • Week 1: Technical discovery + identify pilot group + schedule training
  • Week 2: SSO config + pilot group training + pilot starts
  • Week 3: Integrations + broader training + pilot feedback
Total time: 3 weeks
Why Parallel Works:
  1. Shortens time-to-value
  2. Keeps customer engaged (something happening every week)
  3. Identifies blockers early (pilot group surfaces issues before broad rollout)
How to Execute:
Assign clear owners to each track:
  • Track 1 (Admin): Technical lead
  • Track 2 (Enablement): Training/DevRel lead
  • Track 3 (Pilot): CSM + pilot group champion
Weekly sync across tracks to surface dependencies and blockers.
Common Mistake:
Waiting for "perfect technical setup" before starting pilot. Get pilot group using it early, even if setup isn't perfect. Their feedback makes the broad rollout better.
典型模式：
大多数入职团队串行运行工作流：
  1. 技术设置（第1-2周）
  2. 然后培训（第3-4周）
  3. 然后试点（第5-6周）
总耗时：6周
更优方案：并行工作流
同时运行技术设置、培训和试点：
  • 第1周：技术调研 + 确定试点小组 + 安排培训
  • 第2周：SSO配置 + 试点小组培训 + 试点启动
  • 第3周：集成设置 + 全员培训 + 试点反馈收集
总耗时：3周
并行工作流的优势：
  1. 缩短价值交付时间
  2. 保持客户参与度（每周都有进展）
  3. 提前识别障碍（试点小组在全面上线前发现问题）
执行方式：
为每个轨道分配明确的负责人：
  • 轨道1（管理）：技术主管
  • 轨道2（赋能）：培训/DevRel主管
  • 轨道3（试点）：客户成功主管 + 试点小组负责人
每周跨轨道同步，梳理依赖项与障碍。
常见错误：
等待“完美的技术设置”后再启动试点。尽早让试点小组使用产品，即使设置不完美。他们的反馈能让全面上线更顺利。

Decision Trees

决策树

Should I Start Customer Onboarding?

我应该启动客户入职流程吗？

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
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 This Onboarding At Risk?

这个入职流程存在风险吗？

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
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

Is Adoption Sustained Post-Go-Live?

上线后采用率是否持续？

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
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

Common Mistakes

常见错误

1. Starting customer onboarding before internal alignment
  • Wastes first 2-3 weeks, creates confusion, kills credibility
2. Not identifying real project owner upfront
  • Discovers it Week 4, has to restart or deal stalls
3. Overcommitting on timeline without technical requirements
  • Discovers blockers mid-implementation, misses deadline
4. No internal communication hub
  • Decisions don't propagate across teams, rework happens
5. Treating go-live as project complete
  • Adoption cliff at Week 12, account at risk
6. Sequential tracks instead of parallel
  • Implementation takes twice as long, customer loses momentum
7. No ongoing metrics post go-live
  • Discovers adoption issues too late to save account
1. 在客户内部达成共识前启动入职流程
  • 浪费前2-3周时间，造成混乱，损害可信度
2. 未提前明确真正的项目负责人
  • 第4周才发现问题，不得不重启或停滞
3. 未确认技术需求就承诺不切实际的时间线
  • 实施中期发现障碍，错过截止日期
4. 没有内部沟通枢纽
  • 决策无法在团队间传递，导致重复工作
5. 把上线当成项目完成
  • 第12周出现采用率骤降，客户存在流失风险
6. 串行工作流而非并行
  • 实施时间翻倍，客户失去动力
7. 上线后没有持续跟踪指标
  • 发现采用率问题太晚，无法挽回客户

Quick Reference

快速参考

Pre-Kickoff Validation:
  • Sales handoff complete (deal drivers, stakeholders, requirements)
  • Project owner identified by name on customer side
  • Timeline realistic (their goals vs typical deployment)
  • Internal roles assigned (CSM, technical, exec sponsor)
Kickoff Agenda (30-45 min):
  1. Introductions (5 min)
  2. Executive alignment (5 min)
  3. Success definition (10 min)
  4. Timeline and milestones (5 min)
  5. Meeting cadence (5 min)
  6. Next steps (5 min)
Adoption Tracking (Week 6-26):
  • Week 7: First value report
  • Week 9: User success story
  • Week 11: Use case expansion conversation
  • Week 13: First monthly business review
  • Week 26: Expansion readiness assessment
Four Phases:
  1. Kickoff (Week 1): Align
  2. Discovery (Week 2-3): Plan
  3. Implementation (Week 4-6): Deploy to pilot
  4. Go-Live & Sustained (Week 6+): Rollout, value demonstration, expansion
Red Flags:
  • Customer not responding Week 4 → No project owner
  • Pilot group not using product Week 5 → Wrong group or wrong use case
  • Active users declining Week 8-12 → Adoption cliff forming
启动前验证：
  • 销售交接完成（交易驱动因素、利益相关方、需求）
  • 客户侧已明确项目负责人姓名
  • 时间线切合实际（他们的目标 vs 典型部署时间）
  • 内部角色已分配（客户成功主管、技术主管、执行发起人）
启动会议议程（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周活跃用户下降 → 采用率骤降正在形成

Related Skills

相关技能

  • enterprise-account-planning: Pre-sale deal planning and stakeholder mapping
  • operating-cadence: Onboarding review cadence and health metrics
  • product-led-growth: Self-serve onboarding patterns
Based on enterprise onboarding across multiple platform companies — designing partner onboarding directly and collaborating closely with CS on customer onboarding. Not theory — lessons from seeing Week 4 ghosting happen repeatedly and learning that go-live ≠ success, and understanding the adoption cliff that kills 30% of deals in first year.
  • enterprise-account-planning: 售前交易规划与利益相关方梳理
  • operating-cadence: 入职回顾节奏与健康指标
  • product-led-growth: 自助式入职模式
基于多家平台公司的企业客户入职经验——直接设计合作伙伴入职流程，并与客户成功团队密切合作开展客户入职。这不是理论——是从反复出现的第4周失联问题、上线≠成功的教训，以及了解到第一年导致30%交易失败的采用率骤降问题中总结的经验。