SaaSオンボーディングとは？受注の続きの商談として、手順・期日・担当を契約ごとに決める
SaaSオンボーディングは、受注した顧客が「最初の成果」を得るまでを、手順・期日・担当を決めて進める受注の続きの商談です。この記事の手順表と引き継ぎ項目で、遅れを早く見つける導入の型を作れます。
SaaSオンボーディングとは：受注から「最初の成果」までを進める、受注の続きの商談
SaaSオンボーディングとは、契約した顧客が使い始めてから「最初の成果」を得るまでを、手順を決めて支援することです。導入支援とも呼ばれ、カスタマーサクセスの最初の段にあたります。
ゴールは本稼働ではありません。本稼働は「使い始めた」こと、最初の成果は「買った目的が1回果たされた」ことです。 例えば経費精算の製品なら、全員がログインした日ではなく、最初の月の締めが新しい仕組みで期日どおりに終わった日です。
最初の成果までの日数 ＝ 先方が最初の成果を確かめた日 − 契約の開始日
契約ごとに記録し、この日数を縮める手を打つこれを受注の続きの商談として扱うのは、先方の意思決定がまだ終わっていないからです。 サブスクリプションでは、先方は更新のたびに「使い続けるか」を決め直します。 最初の成果が出ないまま更新の時期を迎えた契約は、失注の手前にある案件です。
だから商談と同じく、次にやること・期日・担当を契約ごとに持ちます。 営業と導入の担当を分けていると、この境目で情報と責任が落ちやすくなります。 分業の境目の設計はThe Modelの課題と対策で扱っています。
手順の設計：期日・担当・完了の基準を手順ごとに決め、期日は成果の日から逆算する
手順表は、最初の成果の期日を先に決め、そこから逆算して手順ごとに期日・担当1人・完了の基準を置きます。完了の基準は「実施した」ではなく、先方が確かめた事実で書きます。 研修を開いても、使う人が自分で操作できなければ、次の手順は進みません。
| 手順 | 期日（例） | 担当 | 完了の基準 |
|---|---|---|---|
| キックオフ | 開始から1週目 | 自社の導入責任者（営業も同席） | 最初の成果とその期日、先方の体制を、先方と文書で合意した |
| 初期設定 | 2週目 | 自社の導入責任者 | 設定の内容を先方の管理者が確認し、承認した |
| データ移行 | 3週目 | 先方の担当者（自社が支援） | 移したデータを先方が元のデータと突き合わせ、差が無いと確かめた |
| 研修 | 4週目 | 自社の導入責任者 | 使う人の全員が受講し、自分で基本の操作を1回終えた |
| 最初の成果の確認 | 6〜8週目 | 先方の推進者（自社が支援） | 推進者が最初の成果を決裁者へ報告した |
担当は「CSチーム」ではなく1人の名前で書き、先方の作業にも先方側の担当者の名前を書きます。 名前の無い手順は、遅れても誰も困らないからです。
期日は、先方の年度末や決算、人事異動の時期に重ねないように置きます。 4月の異動で推進者が替わると、手順の途中で先方の体制から組み直しになります。 手順は5つ前後に絞り、細かい作業は手順の中に書きます。
商談の終盤に、発注までの段取りを先方と表にして進めていたなら、その続きとして手順表を作ります。 先方の推進者は、同じ表の続きなら社内へ説明し直さずに済みます。 買う側から見た導入の段取りは、SFA導入の手順を例に扱っています。
営業からの引き継ぎ：「なぜ買ったか・誰が決めたか・何を約束したか」を渡す
営業から引き継ぐのは顧客の基本情報ではなく、なぜ買ったか・誰が決めたか・何を約束したかの3つと、先方の事情です。これが無いと導入の担当は最初の成果を定義できず、キックオフで先方に同じ質問を繰り返すことになります。
- なぜ買ったか：解決したい課題を先方の言葉で。稟議書に書いた導入の効果は、推進者が社内で約束した数字なので、そのまま最初の成果の候補になる。
- 誰が決めたか：決裁者・推進者・使う部門の代表と、反対していた人。反対の理由も書く。
- 何を約束したか：口頭の約束も含めて、機能・期日・支援の回数・価格の条件。
- 先方の事情：年度予算の時期、繁忙期、異動の時期、情報システム部門の審査の有無。
例経費精算の製品を、社員300名の会社が導入する
営業の引き継ぎメモが、次のように書かれていたとします。
- なぜ買ったか：月末の締めに経理が5営業日かかっている。稟議書には「3営業日に短縮」と書いた。
- 誰が決めたか：決裁者は管理本部長、推進者は経理課長。営業部長は「入力の手間が増える」と反対していた。
- 何を約束したか：過去1年分の申請データを移す。研修は部門ごとに行う。
- 先方の事情：契約の開始は11月。3月は決算で経理が手を離せない。
最初の成果は「12月分の締めを3営業日で終える」と置けます。3月の決算の前に、12月分と1月分の2回の締めを新しい仕組みで終えておけるからです。 研修は反対していた営業部から始め、入力の手間が減る操作を最初に見せます。
数値は説明のための架空のものです。
営業は、このメモをキックオフで先方の前に読み上げます。 約束の食い違いは、初日に見つかれば直せますが、研修の日に見つかると信頼の問題になります。
遅れの見つけ方とよくある失敗：期日を過ぎた手順を、その週のうちに扱う
遅れは最初の成果の期日で気づいても手遅れなので、途中の手順が期日を過ぎた時点で見つけ、原因に合わせて手を打ちます。期日を過ぎた手順が、いちばん確かな兆しです。 先方の打ち合わせが続けて延期される、推進者が異動する、先方の作業の返事が止まる、も同じ扱いにします。
期日を過ぎた手順は、担当がその週のうちに先方と新しい期日を決めます。 それで最初の成果の期日が動くなら、営業と上長にも伝えます。打ち手は原因で変えます。
- 先方の優先度が下がった：推進者を通して、稟議で約束した効果と遅れを決裁者に伝える。
- 先方の作業が重い：自社が引き取れる作業を引き取り、手順を小さく分ける。
- 自社側が遅れている：その日のうちに社内の上長へ上げる。
決裁者が打ち合わせに出ないなら、推進者が社内へ回しやすい1枚の進捗を月に1回渡します。 中身は、手順ごとの期日と完了、最初の成果の見通しです。遅れを決裁者へ伝える経路を、遅れる前に作っておけます。
よくある失敗と直し方
| 失敗 | なぜ起きるか | 直し方 |
|---|---|---|
| 本稼働をゴールにする | 自社の作業の終わりは見えやすく、先方の成果は先方にしか見えない | ゴールを最初の成果に置き、先方が確かめた日を完了にする |
| 引き継ぎが顧客情報の転記で終わる | 営業は受注で評価され、受注後のために書く理由が無い | 引き継ぎの項目が埋まっていることを受注の条件にし、営業がキックオフに同席する |
| 遅れが月次の報告まで見えない | 手順ごとの期日が無く、「順調です」の報告しか上がらない | 手順ごとに期日と担当を置き、期日を過ぎたら当日に分かるようにする |
明日から始めること：最初の成果を1文で書き、手順表と引き継ぎの項目を作る
最初から全顧客に広げず、次に受注する1社で手順表と引き継ぎの項目を試し、2〜3社で直します。次の5つから始めます。
- 自社の製品について「最初の成果」を、先方が確かめられる1文で書いた
- 手順を5つ前後に絞り、手順ごとに期日・担当（1人の名前）・完了の基準を書いた
- 引き継ぎの項目（買った理由・関係者・約束・先方の事情）を1枚にし、受注前に営業が埋めると決めた
- キックオフに営業が同席し、約束したことを先方の前で確かめると決めた
- 期日を過ぎた手順を週次で並べ、新しい期日と打ち手を決める時間を取った
最初の成果が出た日から、次の更新に向けた商談が始まります。 更新の時期から逆算する進め方はSaaSの更新管理で扱っています。 受注から契約と導入の手順につなぐ画面は、機能の紹介で見られます。