gtm-enterprise-onboarding

エンタープライズのオンボーディング

契約締結から価値の実現まで、エンタープライズ顧客をオンボーディングするための4フェーズのフレームワークです。目標は単に本番稼働させることではありません。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 週： 初回の価値レポート 「最初の 1 週間で、チームは次の成果を達成しました：[具体的な指標]。第 12 週時点で目指す状態は次のとおりです：[目標]。」

第 9 週： ユーザーの成功事例 「今週、[チーム名]の[ユーザー名]は[時間を X 時間削減／エラーを Y 件削減]しました。どのように活用しているかをご紹介します。」

第 11 週： ユースケース拡大についての話し合い 「現在は[主なユースケース]にご利用いただいています。同じようなチームでは、[関連するユースケース]にも活用されています。検討してみませんか？」

よくある間違い：

「本番稼働の完了」を測定し、「アクティブな利用の継続」を測定しないことです。本番稼働は成功ではありません。第 26 週時点で利用が定着していることが成功です。

---

3. オンボーディング前：最初の顧客との電話の前に成功を築く

よくあるパターン：

オンボーディングの失敗の多くは、キックオフ前の準備不足にさかのぼります。

見落とされがちなこと：

営業から CS への引き継ぎが不十分：

• 案件の推進要因が不明
• ステークホルダー間の関係が不明確
• 技術要件が確認されていない

社内のプロジェクトオーナーが決まっていない：

• CS が連絡しても、誰からも返事がない
• 間違った相手と会議が設定される
• 決定事項が定着しない

顧客のスケジュールが現実的でない：

• 2 週間で本番稼働したい
• 技術的なセットアップには最低 6 週間かかる
• 初日から期待値が一致していない

フレームワーク：キックオフ前チェックリスト

キックオフの電話を設定する前に、次の項目を確認します。

アカウント情報：

• 営業からの引き継ぎが完了している（案件の推進要因、ステークホルダー、技術要件）
• 過去のやり取りを確認している（デモのメモ、提案書、メール）
• 組織構造を把握している（チームの規模、報告系統）
• ユースケースを文書化している（主な用途＋今後の用途）

社内の準備：

• 社内 Slack チャンネルを作成している（#account-[customer-name]）
• CRM のアカウントプランを更新している
• プロジェクト計画のテンプレートを用意している
• 役割を割り当てている（CSM リード、テクニカルリード、エグゼクティブスポンサー）

顧客の準備状況：

• プロジェクトオーナーを名前で特定している（単に「顧客側の DevRel チーム」ではなく）
• 双方のエグゼクティブスポンサーを確認している
• スケジュールが現実的である（顧客の目標と通常のスケジュールを照合）
• 既知の障害要因を文書化している（調達、セキュリティ、法務）

スケジュールの確認：

• 顧客の本番稼働日は、技術要件を踏まえて現実的である
• 社内の対応能力に余裕がある（過剰な予定を組んでいない）
• 依存関係を特定している（SSO、統合、データ移行）

判断基準：

4 つのセクションすべてを確認してから、キックオフを設定します。不足がある場合は、顧客に連絡する前に営業またはエグゼクティブスポンサーに共有します。

よくある間違い：

社内で状況を明確にしないままオンボーディングを開始することです。混乱や期限の超過を招き、顧客の信頼を損ないます。

---

4. 4段階のオンボーディングフロー

フェーズ1：キックオフ（第1週）

目標： 目標、スケジュール、成功指標について認識を合わせます

参加者： エグゼクティブスポンサー＋プロジェクトリーダー＋技術リーダー

アジェンダ：

1. 自己紹介と役割の確認（5分）
2. 戦略目標について経営陣の認識を合わせる（5分）
3. 成功の定義：「3／6／12か月後に、どのような状態になっていれば成功と言えますか？」（10分）
4. スケジュールとマイルストーン（5分）
5. ミーティングの頻度（プロジェクトチームは毎週、経営陣のレビューは毎月）（5分）
6. 次のステップ（技術調査の打ち合わせ、成功計画のレビュー）（5分）

成果物： 成功指標、スケジュール、次回のミーティングを記載したキックオフの要約を24時間以内に送付します

フェーズ2：調査と計画（第2～3週）

目標： 技術環境を把握し、ユースケースを整理して、展開計画を立てます

並行して進める3つの作業領域：

作業領域1：技術調査

• 現在のインフラ（オンプレミス、クラウド、ハイブリッド）
• 既存のツールと連携
• セキュリティ／コンプライアンス要件
• スケジュール上の制約

作業領域2：成功計画

• ユースケースの優先順位付け（最も価値の高いものから開始）
• 成功指標の定義（導入状況の測定方法）
• トレーニングのニーズを特定（誰に何が必要か）

作業領域3：技術セットアップ

• SSO／IDの設定
• 必要な連携
• データ移行（該当する場合）
• パイロットグループの特定

成果物： ユースケース、指標、スケジュール、マイルストーンを記載したカスタマーサクセス計画書

フェーズ3：導入（第4～6週）

目標： パイロットグループに展開し、ユースケースを検証して、より広範な展開に備えます

並行して進める3つのトラック：

トラック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. 本番稼働後の継続的な指標測定がない

• アカウントを救うには遅すぎる段階で、利用上の問題が判明します

---

クイックリファレンス

キックオフ前の確認：

• 営業からの引き継ぎが完了している（案件の背景、関係者、要件）
• 顧客側のプロジェクトオーナーを実名で特定している
• スケジュールが現実的である（顧客の目標と一般的な導入期間を比較）
• 社内の役割を割り当てている（CSM、技術担当、エグゼクティブスポンサー）

キックオフのアジェンダ（30～45分）：

1. 自己紹介（5分）
2. 経営層との認識合わせ（5分）
3. 成功の定義（10分）
4. スケジュールとマイルストーン（5分）
5. ミーティングの頻度（5分）
6. 次のステップ（5分）

利用状況の追跡（第6～26週）：

• 第7週：最初の価値レポート
• 第9週：ユーザーの成功事例
• 第11週：ユースケース拡大の話し合い
• 第13週：初回の月次ビジネスレビュー
• 第26週：拡大準備状況の評価

4つのフェーズ：

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％を失敗に追い込む利用の急減について理解したうえで得た教訓です。