はじめに — オンボーディングは「最初の3ヶ月で全てが決まる」
カスタマーサクセスとは何か で、CSの5つの役割を解説しました。その筆頭がオンボーディングです。
業界の経験則として、契約後の最初の3ヶ月で躓いた顧客は、その後の継続率が2-3倍悪化する と言われます。これは一見「契約直後の頑張り」のように見えますが、実は CS全業務で最もレバレッジの高いフェーズ なのです。
逆に、最初の3ヶ月がうまくいけば、その後の運用は驚くほど楽になります。
本記事は、私が現役CS管理職として実務で使っているオンボーディング設計を、マイルストーン別に体系化したものです。
結論 — オンボーディング設計の5マイルストーン
オンボーディングは、以下の5つのマイルストーンで設計します。
| マイルストーン | 期間 | 主目的 |
|---|---|---|
| Day 0: キックオフ | 契約締結 | 目的合意・関係者の明確化 |
| Day 7: 初期設定完了 | 契約後1週間 | 製品が触れる状態 |
| Day 30: 初回成果 | 契約後1ヶ月 | Time-to-Value 達成 |
| Day 60: 活用定着 | 契約後2ヶ月 | 日常業務に組み込み |
| Day 90: 正式運用 | 契約後3ヶ月 | 通常CS運用へ移行 |
各マイルストーンでやるべきこと、避けるべきことを、以下で順番に解説します。
Day 0: キックオフ会の設計
目的
- お客様側の 「達成したいこと」 を明確化
- 自社側の 「提供できること・できないこと」 を明示
- 関係者の 役割と稼働期待値 を合意
- コミュニケーションルール の確立
キックオフ会のアジェンダ(60分)
# キックオフミーティング — [顧客名] / [日付]
## 1. 自己紹介 + 関係者整理(10分)
- 当社側参加者(役職・連絡先)
- お客様側参加者(役職・主担当・副担当)
- 経営層との接点ルート(誰経由で報告が上がるか)
## 2. お客様の事業状況・課題の確認(15分)
- 現在の業務フロー
- 製品導入のきっかけ
- 解決したい課題(優先順位付き)
- 期待する成果(定量目標)
## 3. 製品の概要説明(10分)
- 主要機能の説明(深入りはしない)
- 「できること・できないこと」の明示
- 類似業種・規模での導入事例
## 4. 今後の進め方(15分)
- 5マイルストーン(Day 0/7/30/60/90)の説明
- 各マイルストーンでの双方の役割
- 定例ミーティングの頻度設計
## 5. コミュニケーションルールの合意(5分)
- 主な連絡経路(メール/Slack/電話)
- 緊急時の連絡先
- 議事録の共有方法
## 6. 次回までのアクション(5分)
- お客様側:
- 当社側:
- 次回日時:キックオフ会のNG例
- 当社側がプレゼン中心になる — お客様の話を聞く時間が3割以下だと、ニーズを取り違える
- 参加者が決定権者・実務者の片方しかいない — 片方だけだと、後でひっくり返される
- 「とりあえず始めましょう」で終わる — マイルストーンと役割を合意しないと、期待値ズレが必ず発生
Day 7: 初期設定完了 — 「触れる状態」を作る
目的
契約後1週間以内に、お客様が 製品を実際に触れる状態 を作る。「設定が完了しない」「アカウントが作れない」で1ヶ月過ぎる、というのが最悪のシナリオ。
CS担当者がやるべきこと
- Day 1-2: アカウント発行・初期管理者権限の設定
- Day 3-4: 基本設定の支援(組織情報、ユーザー追加、初期データインポート)
- Day 5: 設定完了確認のミーティング(15分)
- Day 6-7: トラブルがあれば即対応、設定完了の正式宣言
初期設定でハマるポイント
- データインポート: お客様側のデータが想定形式と違うことが多い
- 権限設計: 複数部署にまたがるとき、「誰が何を見られるか」が複雑化
- 既存システム連携: SSO、SalesforceなどとのAPI連携で躓く
- セキュリティポリシー: お客様側のIT部門の承認が必要なケース
これらは キックオフ会で先に確認しておく ことが、最大のリスク対策。
Day 7 のチェックリスト
- アカウント発行完了
- 管理者ユーザー設定完了
- 初期データインポート完了(必要な場合)
- 主要メンバーへのアクセス権付与完了
- 既存システム連携完了(必要な場合)
- お客様側が「触れる状態」を確認済み
Day 30: 初回成果 — Time-to-Valueの達成
目的
契約後30日以内に、お客様が 「この製品を入れて良かった」と実感できる小さな成果 を生み出す。
これが業界で言う Time-to-Value(TTV)。TTVが達成できないオンボーディングは、ほぼ確実に失敗します。
「初回成果」の例
製品の種類によって違いますが、以下のような小さな成果を狙います。
- 業務時間が 可視化されたレポート1本 を出力
- 自動化された定型業務が 1件 完了
- 既存業務に 1つの改善 が組み込まれた
- 主要メンバー(3名以上) が 自発的にログイン するようになった
派手な大成果である必要はなく、「日々の業務で価値を感じる小さなもの」で十分です。
Day 8-30 のCSの動き
- Week 2(Day 8-14): ユーザー研修の実施(30-60分のWebミーティング)
- Week 3(Day 15-21): 業務での試運用、お客様のフィードバック収集
- Week 4(Day 22-30): 初回成果の確認、Day 30レビュー会
Day 30 レビュー会のアジェンダ
# Day 30 オンボーディングレビュー — [顧客名]
## 1. 当初目標の振り返り(10分)
- キックオフで合意した目標
- 現在の状態
- ギャップ
## 2. 初回成果の確認(10分)
- 達成された小さな成果
- お客様の体感
- 数字での効果(可能なら)
## 3. 課題・困りごとのヒアリング(10分)
- 設定で困っていること
- 使い方で迷っていること
- 改善要望
## 4. Day 60までの計画(10分)
- 次の30日で達成したいこと
- お客様側・当社側のアクション
## 5. 質疑応答(5分)Day 60: 活用定着 — 日常業務への組み込み
目的
契約後60日で、お客様が 日常業務の一部として製品を使う 状態を作る。「便利だが、たまに使うツール」ではなく「毎日触るツール」に進化させる。
定着の指標
定着が進んでいる兆候:
- DAU(日次アクティブユーザー)が増えている
- 機能利用率(特に主要機能)が70%超
- スティッキネス(DAU/MAU)が20%以上
- お客様側で「自走」が始まっている(質問が減る、応用利用が増える)
Day 31-60 のCSの動き
- Week 5-6: 応用機能の紹介、他社事例の共有
- Week 7: 利用率の中間レビュー、低利用領域のテコ入れ
- Week 8: Day 60レビュー会
定着が進まないとき
- 利用が一部のメンバーに偏っている → 未利用メンバー向けのミニ研修
- 特定機能だけ使っている → 隣接機能の活用提案
- 問い合わせが減らない → ナレッジベース整備、FAQの拡充
- 業務に組み込まれていない → 業務フロー側の改善提案
「定着しない」のは、製品の問題ではなく 業務設計の問題 であることが多い。製品の使い方ではなく、業務の流れを一緒に再設計するアプローチが効きます。
Day 90: 正式運用 — 通常CSフェーズへ
目的
オンボーディング完了を双方で正式に確認し、通常運用フェーズに移行 する。
Day 90 完了確認会
# Day 90 オンボーディング完了確認 — [顧客名]
## 1. 当初目標の達成度(15分)
- キックオフで合意した目標 vs 現状
- 達成できたこと
- 未達成のこと、その理由
## 2. 数字での総括(10分)
- 利用率(DAU/MAU)
- 機能利用率
- 業務改善の定量効果(可能なら)
- ヘルススコア
## 3. お客様のCSAT/NPS聴取(10分)
- 5段階満足度
- 推奨度(NPS)
- 改善要望
## 4. 正式運用への移行(10分)
- 通常運用フェーズの定例頻度(月1がスタンダード)
- 通常CS担当者の明確化(OBM分業の組織のみ)
- 半期/年次レビューの日程仮押さえ
## 5. アドボカシー化の打診(5分)
- 事例化への協力可否
- 紹介プログラムの紹介移行後のフォロー
正式運用に移行した後も、最初の3-6ヶ月は 「オンボーディング完了直後の顧客」 として注意深く監視。Day 91-180 はヘルススコアが下がりやすい時期です。
オンボーディングでよくある失敗パターン
失敗1: 最初の3週間を放置する
「契約直後はお客様も忙しいだろう」と当社側も連絡を控える → 気付くと3週間連絡なし → 設定もユーザー追加も進んでいない。
対策: キックオフ会で「最初の3週間は密に連絡を取る」ことを明示。Day 1, 3, 7, 14 を「必ず連絡するタイミング」として固定。
失敗2: キックオフでお客様の話を聞かない
CS担当者がプレゼン中心になり、お客様の業務状況・課題感のヒアリングが不十分。結果、的外れな支援が続く。
対策: キックオフのアジェンダで「お客様の話を聞く時間 > 当社の話す時間」を意識的に確保。
失敗3: マイルストーンを設定しない
「契約後はとりあえず使ってもらおう」で、明確な目標・期日が双方にない。3ヶ月過ぎても進捗が見えない。
対策: Day 7/30/60/90 のマイルストーンを契約直後に文書化、双方で合意。
失敗4: 「設定完了 = オンボーディング完了」と勘違い
製品の初期設定が終わった時点で、CS担当者が「あとはお客様次第」と引き気味になる。実際は、設定完了 → 活用定着 → 正式運用、までがオンボーディング。
対策: 設定完了はDay 7のマイルストーンに過ぎず、オンボーディングは Day 90 まで続くことを内部研修で徹底。
失敗5: オンボーディング終了の確認をしない
90日が過ぎても、双方で「オンボーディング完了」と認識せず、惰性で続く。次のフェーズ(エクスパンション、アドボカシー)に進めない。
対策: Day 90 完了確認会を明示的に設定。オンボーディング → 通常運用への切り替えを儀式化。
まとめ — オンボーディング成功の3つの原則
1. 「成果」を3ヶ月以内に作る
Time-to-Value の達成が、オンボーディング成功の最も重要な条件。製品の派手な活用ではなく、「使って良かった」と感じる小さな成果でOK。
2. マイルストーンで構造化する
Day 0/7/30/60/90 の5マイルストーンを必ず使う。これが構造化されていないオンボーディングは、必ずどこかで失速する。
3. お客様の話を聞く時間 > 当社が話す時間
キックオフ・定例・レビュー、すべてのミーティングで、当社側が話す時間が半分以下に収まるよう設計。お客様が話す中に、すべての答えがあります。
関連記事
- カスタマーサクセスとは何か — オンボーディングがCSの5つの役割の筆頭である理由
- ヘルススコア設計と運用の完全ガイド — オンボーディング期間専用ヘルススコアの設計
- SaaSのカスタマーサクセス指標完全ガイド — Time-to-Value/オンボーディング完了率の計測
- CS実務テンプレート集 — キックオフ・定例議事録のひな型
- CS業務で本当に使えるAIプロンプト10選 — ナレッジ記事ドラフト生成のAI活用
質問・「自社のオンボーディング設計のご相談」は お問い合わせフォーム からどうぞ。
— Ao