← エピソード一覧に戻る Episode 151 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 登録できても成功したとは限らない
タカシ
皆さんこんにちは、タカシです。今日は SaaS プロダクトの初回成功体験を扱います。登録数も初回設定数も悪くないのに、なぜか続かない。そんな SaaS に共通するのが、最初の成功の設計不足なんです。
ミカ
ミカです。ありますよね。会社としては onboarding が終わったつもりでも、使う側は、で、何が良かったの、で止まる感じ。設定完了と成功体験って、似ているようで全然違うんですか。
タカシ
かなり違います。 activation は運営側が置く計測イベントですが、初回成功体験は顧客が仕事が前に進んだと感じる瞬間です。ここを外すと、KPI は動いているのに記憶に残らないプロダクトになります。
ミカ
今日はその違いに加えて、テンプレートやサンプルデータがなぜ効くのか、チーム SaaS では一人の成功で終わらせてはいけない理由、それから次の習慣化へどうつなぐかまで聞いていきます。
Chapter 2 基本 ― 運営側の activation と顧客側の成功を分ける
タカシ
まず数字から見ましょう。Amplitude は、初週の activation が強いプロダクトの 69 パーセントが、3 カ月後の retention でも上位だったと示しています。最初の一週間で価値が見えるかどうかは、かなり重い分岐点です。
ミカ
しかも day seven に 7 パーセント戻ってきていれば上位四分位、 enterprise だと上位 10 パーセントが 12.4 パーセントで、中央値は 2.1 パーセントなんですよね。最初の週って、思った以上にシビアです。
タカシ
ええ。ただし、ここで勘違いしやすい。たとえば分析 SaaS でデータ接続完了を activation に置くのは自然ですが、顧客が成功したと感じるのは、見たい数字が出た、共有して会話が始まった、意思決定に使えた、のほうです。
ミカ
なるほど。運営側は、ここを通ったら使い始めたと判断しやすい。でも顧客からすると、設定が終わったことより、ちゃんと役に立った手応えのほうが大事なんですね。ここを混ぜると設計がずれそうです。
タカシ
その通りです。初回成功体験は、顧客が最初に片づけたい job を何か一つ前進させること。機能紹介を全部やることではありません。だから success event は、顧客の進歩が見える出来事として別に定義したほうが良いんです。
Chapter 3 設計 ― 空白を減らし、成功を先に見せる
タカシ
初回成功を早める定番が、空白をそのまま渡さないことです。Intercom は first use で、全部の機能を教えるより、 templates や defaults で最小フローに絞れと言っています。説明を増やすより、成功までの手数を減らす発想ですね。
ミカ
ああ、空のダッシュボードや空のボードを見せられると、ユーザーは何も起きていないって感じますもんね。始め方が分からないというより、始める価値がまだ見えていない状態になりやすい気がします。
タカシ
その典型が Mixpanel の demo dataset です。公式ページでも、まずフルの demo を見て、気に入った dashboard は自分の project に移せると案内しています。重いデータ連携の前に、見える価値を先に体験させるわけです。
ミカ
それ、 analytics や CRM みたいに初期入力が重い SaaS ではかなり大事ですね。 sample data や雛形がないと、良さが分かる前に宿題だけ渡される感じになる。最初の成功が遅いと、もう戻ってこなさそうです。
タカシ
さらにチーム SaaS では、一人の成功で終えないことも大切です。Slack の template は onboarding buddy や team lead の追加まで組み込んでいますし、 customer onboarding でも関係者参加後の自動案内を勧めています。共同作業の最初の一往復までが成功なんです。
Chapter 4 具体例 ― 小さな摩擦除去で成功体験は変わる
タカシ
Appcues の自社事例は分かりやすいです。 welcome modal の最後に複数あった選択肢を一つに絞り、完了後すぐ flow 作成画面へ送るようにしただけで、 activation は 2.5 倍、次の行動までの継続率は 132 パーセント改善しました。
ミカ
派手な機能追加じゃなくて、最後の一歩を迷わせなかっただけなんですね。何をすれば最初の成功なのかが、一目で分かる状態にした。それだけで数字がここまで動くのは、ちょっと怖いくらいです。
タカシ
MYOB も似ています。会計ソフト経験の有無と用途を最初に聞き、会計、請求、給与で checklist を出し分けたところ、 global setup rate が 21 パーセント改善し、一部 checklist は 40 パーセント超の完了率になりました。
ミカ
全員に同じ初回成功を押しつけなかったのが効いたんですね。銀行連携が先の人もいれば、請求書送付が先の人もいる。 job に合わせて最初の勝ち筋を変えると、ユーザーの手応えが早くなるわけだ。
タカシ
Slack 系のチーム導入も同じです。チャネルに参加した瞬間、 project overview や timeline、案内メッセージが届き、同僚が入っても同じ導線で動ける。成功を個人の設定完了ではなく、チームが回り始めた状態で作っているわけですね。
Chapter 5 クロージング ― 成功体験の次を 7 日以内に置く
タカシ
実務では、まずこの人が最初に成功したと言えるのは何が起きた時かを、一文で定義してください。そのうえで blank state を雛形に置き換え、 success 到達後の 7 日間に何で再訪させるかまで決める。ここまでで初回成功体験の設計です。
ミカ
activation event は測定のため、初回成功体験は記憶に残すため、そしてその次の 7 日は習慣化のため、という並びですね。最初の価値を見せたあとに、次の一回をどう起こすかまで考えるのが SaaS らしい設計だと分かりました。
タカシ
ええ。設定完了を成功だと思い込むと、プロダクトはだんだん自己満足になります。顧客が最初に何を達成したら笑顔になるか。そこから逆算するのが本筋です。今日は SaaS プロダクトの初回成功体験を取り上げました。ではまた次回お会いしましょう。