← エピソード一覧に戻る Episode 139 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 契約後の数週間で未来が決まる
タカシ
皆さんこんにちは、タカシです。今日は SaaS 立ち上げで意外と見落とされるオンボーディング設計を扱います。受注したのに定着しない会社は、だいたい営業の勝ち方より契約後の進め方が曖昧なんです。
ミカ
ミカです。オンボーディングって、ログイン方法を教えたり、最初の設定を一緒にやったりする部分ですよね。でもそれが経営テーマになるほど大きいんですか、という疑問をまず持つ人も多そうです。
タカシ
大きいです。SaaS は売って終わりではなく、使い始めて初めて売上が継続に変わる事業です。だからオンボーディングは、説明の場ではなく、最初の成果を出させる導線設計として見る必要があります。
ミカ
なるほど。営業で期待を上げても、契約後に迷わせたら『思ったより大変だな』で止まってしまうわけですね。受注率より、その後にどう価値へ着地させるかが勝負になると。
タカシ
その通りです。今日は、オンボーディング設計の基本、役割別導線の作り方、high-touch と low-touch の使い分け、そして HubSpot や Superhuman の具体例まで見ていきましょう。
Chapter 2 基本 ― オンボーディングは成功条件の設計である
タカシ
まず定義です。SaaS のオンボーディング設計は、契約から初回価値到達までに、誰が何をどの順番で完了すれば前進と言えるかを決める仕事です。画面説明より先に、成功条件を決める必要があります。
ミカ
成功条件というと、たとえば『データ移行が終わった』とか『管理者が初期設定を終えた』みたいなことですか。それとも、もっと顧客の業務成果に寄せて決めるものなんでしょうか。
タカシ
後者です。設定完了は手段であって、目的ではありません。経営層には進捗と投資対効果、管理者には移行と権限、現場には使って助かった実感が必要です。役割ごとに最初の価値を言い分ける設計が欠かせません。
ミカ
たしかに、決裁者と現場担当者で見たい景色が全然違いますね。同じチュートリアルを全員に見せても刺さらないし、むしろ『自分には関係ない説明ばかり』で面倒になりそうです。
タカシ
そこで重要になるのが、営業から導入への handoff です。Gainsight は、契約直後に success criteria を取り、何が完了で何が未完了かを追える Success Plan を持つべきだと勧めています。ここが抜けると、期待値が崩れます。
Chapter 3 実例 ― 目標から逆算して導入の順番を切る
タカシ
HubSpot の Service Hub Onboarding は分かりやすい設計です。通常は二カ月前後で進め、同時に追う優先ゴールを三つまでに絞ります。しかも専任コンサルタントがロードマップを持ち、進行管理まで担います。
ミカ
三つまでに絞るのがいいですね。やろうと思えばサポート、営業、データ整備、レポート作成と何でも入れたくなりますけど、最初から全部やると、結局どれも中途半端になりそうです。
タカシ
その通りです。HubSpot も最初はユーザー追加、トラッキングコード、共有メール、ナレッジベース、データ import など、価値に近い順番で基礎を積みます。つまりオンボーディングとは、教える内容ではなく実装順の設計なんです。
ミカ
なるほど、顧客から見ると『今どこまで進んだか』が分かるし、社内から見ても何を先に終わらせるべきかが明確になりますね。これがないと毎回担当者の勘で進んでしまいそうです。
タカシ
そうです。立ち上げ期ほど、創業者が最初の数社でこの順番を自分の目で確かめるべきです。どの設定が価値に直結し、どの説明が不要かは、資料ではなく実地のキックオフでしか見えないことが多いからです。
Chapter 4 設計の勘所 ― 人手とプロダクトをどう配分するか
タカシ
次の論点は、high-touch と low-touch の切り分けです。ProductLed は self-serve 中心、伴走中心、その混合型を分けて考えています。複雑な顧客を全部セルフサーブに押し込むと、早いようで実は遅くなります。
ミカ
でも人手を厚くすると、立ち上げ期の小さなチームには重そうです。どこまでやれば投資に見合うのか、経営者としてはそこが一番気になるポイントかもしれませんね。
タカシ
Superhuman はその答えを示しています。人が伴走した顧客は六五パーセント超がメール移行を完了し、activation と referral は self-serve のほぼ二倍でした。さらに担当一人で年六十五万ドル規模の ARR を支え得る試算まで出しています。
ミカ
それだけ差が出るなら、少なくとも業務変更が大きい顧客には人手を入れる意味がありますね。オンボーディング担当はコストセンターではなく、立ち上げ期の学習装置であり売上装置でもあるわけだ。
タカシ
一方で、全員を同じように手厚くする必要はありません。Pendo の事例では Splash が役割別ガイドを出し分け、新規ユーザーのイベント作成を大きく増やし、ガイド経由の webinar 参加も一〇から一五パーセント伸ばしました。分岐設計が効くんです。
ミカ
Intercom のチェックリストみたいに、プランや persona ごとに手順を分けて、会社全体の進捗も見えるようにしておけば、管理者だけ先に終わって現場が置いていかれる、みたいなズレも減らせそうです。
Chapter 5 まとめ ― 受注後の迷子をなくすために
タカシ
最後に失敗パターンを四つに絞ります。営業内容が handoff されない、全員に同じ導線を見せる、touch model の切り分けがない、そしてプロジェクト完了を成功と勘違いする。この四つは立ち上げ期で特に多いです。
ミカ
明日からやるなら、まず契約直後に一枚でいいから成功基準を書き出すのがよさそうですね。誰が責任を持ち、どのロールが何を終えたら前進なのかを、社内外で同じ言葉にするところから始めると。
タカシ
まさにそこです。そのうえで、初回価値イベント、役割別導線、high-touch 条件、停滞理由の記録まで揃えると、オンボーディングは属人的な親切から再現可能な経営プロセスに変わります。立ち上げ期の差はここで開きます。
ミカ
受注できたかだけで安心せず、契約後の数週間をどう設計するかまで含めて営業だしプロダクトなんですね。今回はかなり実務に直結する回でした。次に SaaS を見る目が変わりそうです。
タカシ
今回は、SaaS 立ち上げにおけるオンボーディング設計を扱いました。皆さんの事業でも、受注後の最初の価値体験がどう設計されているか、ぜひ一度見直してみてください。それではまた次回、お会いしましょう。