← エピソード一覧に戻る Episode 152 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 習慣化は毎日ログインさせることではない
タカシ
皆さんこんにちは、タカシです。今日は SaaS プロダクトの習慣化設計を扱います。ここで最初に言っておきたいのは、良い SaaS を作ることと、毎日ログインさせることは同じではない、という点です。
ミカ
ミカです。え、そこ違うんですか。SaaS って、使う頻度が高いほど良いとなんとなく思っていました。毎日開いてもらえたら勝ち、みたいなイメージがあったんですが。
タカシ
そこがよくある誤解なんです。B2B SaaS の中には日次利用が自然なものもあれば、週次や月次で十分価値を出すものもある。習慣化とは、顧客の仕事の周期に合わせて自然に戻ってくる設計をすることなんですね。
ミカ
なるほど。無理に daily active user を伸ばす話じゃなくて、その仕事が発生したときに真っ先に開かれる状態を作る話なんですね。今日はその作り方を具体例つきで聞きたいです。
Chapter 2 基本 ― 使われる周期を先に見極める
タカシ
Amplitude の retention workbook では、まず product の usage interval を決めろと整理しています。今いるユーザーの約 80 パーセントが critical event を二度目に行うまでの時間を見て、自然な利用周期を掴む考え方です。
ミカ
つまり、請求や経費みたいに月次の仕事が中心の SaaS を、日次で評価すると、本当は健全なのに悪く見えてしまうわけですね。指標の取り方を間違えると、施策までずれそうです。
タカシ
その通りです。さらに OpenView は、SaaS の activation は一から三日、B2B では二から三週間で起きることが多いと説明しています。大事なのは初回成功の直後に、二回目の価値到達をどう置くかなんです。
ミカ
最初の感動だけで終わらせないってことですね。初回成功の次に、次のレポート確認、次の承認、次のレビュー依頼みたいな二回目の理由がないと、気持ちよく終わってそのまま忘れそうです。
タカシ
ええ。習慣化設計は onboarding の後ろにある工程です。最初の一回を作るだけではなく、同じユーザーが自然にもう一度価値に触れるまでの導線を、最初から product の中に入れておく必要があります。
Chapter 3 設計 ― 個人の便利さをチームの反復行動に変える
タカシ
チーム SaaS では、個人の habit だけ見ていると弱いです。Slack は paid customer で典型的な勤務日に平均九時間接続、九十分が active use、週あたり五十億件超の action があると公表しています。
ミカ
九時間つないで九十分は能動的に触っているって、相当仕事の中心ですね。でも Slack が強いのって、ただ chat がしやすいからだけではなさそうです。何が shared habit を作っているんでしょう。
タカシ
ポイントは、会話、ファイル、他ツールの更新、依頼が一か所に集まることです。Slack app 利用者の九十五パーセントが、Slack 内で使うと他ツールの価値も高まると答えています。自分のためだけでなく、誰かの動きが次の利用を呼ぶんです。
ミカ
なるほど。チーム SaaS の習慣化って、自分で思い出して開くより、共有、コメント、承認依頼みたいな往復が生まれて、仕事の流れの中で開かざるを得ない状態を作ることなんですね。
タカシ
その通りです。だから team product では、個人の設定完了をゴールにしない。誰かを招待した、コメントに返した、依頼が処理された、といった他人が関与する一往復までを habit event に含める設計が効きます。
Chapter 4 実務 ― 通知は量ではなく、次の一歩の精度で効く
タカシ
ここで効くのが、行動に連動したメッセージです。Yotpo は review widget 設置と一件目の review 生成を activation に置き、Appcues の in-app flow と progress 連動メールを組み合わせました。
ミカ
その結果がかなり大きいんですよね。一週 retention が五十パーセント増、二週 retention は六十パーセント超の改善で、週二日訪問する active user も三十パーセント増えた。かなり分かりやすい成果です。
タカシ
ええ。効いたのは一斉送信ではなく、今どこで止まっているかに応じて次の一歩を出したことです。Intercom も、trial 後の day forty まで in-app message と email を組み合わせ、行動に応じて案内を変えています。
ミカ
通知って多いほどいいわけじゃないんですね。しかも Intercom は B2B メッセージの open が火曜から木曜の十時から十四時に強い傾向も出している。内容だけでなく、業務時間帯との相性も大事そうです。
タカシ
そうですね。in-app はその場の次の操作を進める用途、email は戻ってきてもらう用途、通知は緊急性の高い変化を知らせる用途、と役割を分けるべきです。チャネルを増やすより、文脈を合わせるほうが habit には効きます。
Chapter 5 クロージング ― 低頻度 SaaS ほど習慣を再定義する
タカシ
最後に強調したいのは、低頻度 SaaS ほど habit の定義を変えるべきだという点です。経費精算や月次レポートの product は、毎日使われなくてもいい。締め前に迷わず戻ってこられることが価値になります。
ミカ
今日の話をまとめると、まず critical event と usage interval を見つける。次に初回成功の直後へ二回目の価値を置く。さらに team product なら共有の一往復まで設計し、通知は行動連動で打つ、ですね。
タカシ
その通りです。習慣化は中毒化ではなく、仕事の流れへの埋め込みです。皆さんの SaaS でも、ユーザーが次に戻る理由は本当に設計されているか、ぜひ見直してみてください。今日は習慣化設計を取り上げました。ではまた次回。