SaaSにおける使用量課金のススメ #SaaSLovers Day 4
こんにちは、アルプ代表の伊藤と申します。5/6の #SaaSLoversの投稿を担当いたします。
アルプは、ScalebaseというSaaS・サブスクリプションビジネスにおける契約管理・請求管理を一元化するクラウド販売管理ソフトを開発・提供しています。我々が提供する価値は、顧客の契約と請求管理の効率化が第一にありますが、それをベースに商品設計やプライシングにおけるチューニングとフィードバックサイクルを回すことができます。そういうわけで日々プライシングについても自社のことも含め、調べ学び続けている日々です。
プライシングも様々で、月額課金から、アドオン・オプションの柔軟な追加、そこから階層型（ティア）など多岐にわたるのですが、今回はその中でも、使用量課金/従量課金とその根幹となる"Value Metrics"について、書いていこうと思います。
# サマリー
プライシングは顧客への提供価値に対していかに真摯に向き合うかという話はどこでも言われていることだと思っています。その上で、SaaSこそサービスの提供価値の根幹のドライバーであるValue Metricsを定めること、その上でそこを基軸とした使用量課金のプライシングを設計できるよう、思考をどこまで深められるか、またそのチューニングをし続けることが経営、セールス、カスタマーサクセスや開発全般において広く大事だという話を書きます。（次はアルプでの試行錯誤もシェアできるといいな）
#使用量課金とは何なのか？
いわゆる従量課金を指していますが、ユーザーのサービス使用量（単位は何でも）に応じて請求が発生する料金体系もしくは、既定の数量を契約しその範囲における利用を対象として請求が発生する（超過した場合はその超過分をプランのアップグレードor追加する）料金体系として一旦定義しています。
いわゆるサブスクリプション/SaaSにおいては、定額料金、ユーザー数につきいくらという料金体系も一般的ですが、Snowflake、Slack、Datadog、Twilio、AWSなどはまさに使用量課金です。
また、後述しますが、完全ピュアな使用量課金のみでなく、サブスクリプション的な定額課金のプラン + 使用量課金というモデルも含んで考えています（基本的に利用できる機能のパッケージはプランに基づいており、最終的な請求金額は「プランの費用」+「ある機能の利用状態（使用量）」によって変化するモデル）。
※なお、サブスクリプションという定義≠月額の定期課金です。含まれるケースが多分に多いですが、あくまで顧客のニーズ・需要に応じて請求金額を定めていくモデルをサブスクリプションとして定義しています。
#使用量課金のポイント/強み
大きく3つあると思いますが、顧客と同じ方向に向きやすいというポイントが非常に大きいと思っています。ただ、当然使ってもらうだけ顧客が成功を実感できる設計でないといけないという大前提もついてきます。
1. 顧客の成功（サービスの利用による顧客への提供価値の拡大）が企業の利益（サービス使用量の成長に伴う収益拡大）と一致するため成長性が非常に高い
2. サービスの利用期間（習熟度）にも連動するので、複利で効いてくる
3. Value Metrics（顧客への提供価値拡大のドライバーとなる指標であり、サービス使用量の計測単位）が明確に定まることで、そこにフォーカスした開発をしやすい（ある意味のPMFとも言える話ですが）
#どう使用量課金を設計していくのか？
##事業・プロダクトとのフィットを考える
使用量課金がハマるかどうかは大きくは、「利用が顧客の成功に直結するかどうか？」「定着性が高く、時間の経過とともに使用量が増えていくようなタイプか？」「ターゲット顧客がソフトウェアの利用（使用量課金などを中心に）なれているかどうか？」などの論点で考えられます。
一方で、利用状況が変動が激しい/一時的なものや、使用量課金の限界費用を考えて利用を逆に控えてしまうケースなどは向いていない可能性が高いです。
そういう意味では、Vertical SaaSはインダストリーに応じて顧客の許容度も変わると思いますが、今後SaaSが一層浸透していくことは間違いない中、使用量課金の採用はどのSaaS企業もありえると思っています。
##どういう指標（Metric）に基づいた使用量課金だと良いのか？
顧客への提供価値拡大のドライバーとなる指標であり、サービス使用量の計測単位をValue Metricsと呼んでいます。Value Metricsは、プロダクトそれぞれでバラバラであるべきで、汎用性高く一意には定まるものではありません。一般的にはユーザー数・アカウント数が多いところもありますが、大事なことはそのMetricsと顧客の利用/顧客が感じる価値が連動しているかどうか、です。もちろんSlackはユーザー数で、それで正しいですが、グローバルのプロダクトだと下記などが例としてあります。
- Snowflake: Compute resources, Volume of data
- Datadog: # of hosts, Amount of ingested or scanned GB
- Zapier: # of tasks, # of zaps
- Hubsport: # of contact
- Slack: # of users
## Hubspotの例
使用量課金自体は、どのSaaSも初期からやっているわけではありません。成功しているSaaSも途中から転換したり、またそれに伴って大きく事業成長の角度を上げていったケースもあります。調べるとよくHubspotの事例が出てくるので少しまとめてみました。
もともと固定のHubSpotは元々、使用量に応じたプライシングではなく、固定費パッケージのみを提供していました。アップグレード率は低く、純収益のリテンションは75%だったようです。IPOの前に、HubSpotはコンタクトベース（# of contact）のプライシングを導入し、プラットフォームを介してより多くのリードを生成すると、顧客はより多くの料金を支払うようになりました。これに伴い、純収益維持率は100%に増加しました。
なぜ、ユーザー単位でないかというところも面白いです。
HubSpot は seat ごとではなく、contactごとに価格を設定している。なぜなら CRM に大量の連絡先をインポート・管理する企業は (1) HubSpot に多くの価値を見い出せる、(2) おそらく少々値段が高くても予算を出せる、ということを HubSpot は理解しているからだ。
このケースではseat単位のプライシングを使うとバリューの取りこぼしが起きてしまう。例えば熱意と活力を持ってプロダクトの開発を行っている小さなチームがあったとする。このチームは HubSpot を使って数千人の顧客にリーチして収益を上げているが、seat ごとの計算だとソフトウェアを開発しているチーム（2~3人）分しか請求できない。
## 使用量課金のみ、で設計する必要もない
使用料課金の議論は、完全なる使用料課金のみへの移行を意味するものではありません。
使用量課金 + サブスクリプションパッケージというタイプも大きくあります。Zapierなどが大きい例です。機能単位ではプランを大きく5タイプに分け（所謂サブスクリプション型）、その中でもTaskの数でプランの金額を分けています（使用量課金型）。Scalebaseもこういう形でのプライシングを今志向してさらに進化させたいと思っています。
#使用量課金における更なる工夫、超過対応のケース
少しテクニカルな話も入りますが、使用量課金のケースでよく出るのが、使用量の超過に対してどういう対応、プライシングの設計がありえるのか？という話。ここではいくつかの考えを参考までにまとめてみます。個人的にはここはグローバルがかなり先駆けて洗練させている分野であり、学びが深いです。Scalabaseもここを柔軟かつ網羅的に対応できると相当強いと思いました。
1. 使用量のボリュームに応じた段階的な料金モデルに沿ってディスカウントが自動的になされるケース
- Twilio
2. コミットした使用量（契約）の未使用分を繰り越していくケース
- Slack、Snowflake
3. 使用量を月間でコミットすることで、ディスカウントを適用できるケース(コミットを超える分は通常料金が適用)
- Datadog
4. 通常は使用分だけの使用量後払いだが、先んじてコミットした使用量について先払い・一部先払いなどを選択することでそれに応じたディスカウントを適用できるケース
- AWS
# 顧客と向き合わずに、プライシング、特に使用量課金の設計は不能
理論や情報としてはなるほど、というところもあったと思いますが、どう実践していくか？Value Metricsの定義やそれに伴うプライシングの策定/チューニングは、顧客観察からしか生まれないと思っています。アルプもまさに今それを進めていこうとしています。つまり、最良の顧客の行動をリバースエンジニアリングしていく、それらの行動を他の顧客に適用していくということだと思います。
顧客の利用実態/感じる価値が何なのか、どこが利用のドライバーになっているのか、そして未来の顧客の成功が何で、その時にプロダクトがどういう利用状態になっているのか、なっているべきなのか。これらのインサイトを、カスタマーサクセスチームが顧客をオンボーディングするための標準プロトコルにできると理想ですね。
#最後に - 顧客と自社をアラインさせること
OpenViewの直近の記事に使用量課金についての考え方、スタンスについて非常に面白い内容が書いてました、最後に少しだけ転載します。非常に深い戒めでした。
この（SaaS/使用量課金という）ハードワークは契約終了時に"始まり"、契約終了時に終了しません。顧客は毎日あなたの製品を使用するかどうかについて意思決定をしています。つまり、毎日、完全に支払うのをやめることを決定できるということです。
あなたは、あなたの顧客が価値を見ていることを確認するために最善の利益をもたらすために、あなたの会社全体を設計していく必要があるのです。
これには次のようなものが含まれます。
- 「予約」や「コミットメント」を聖杯として扱わないでください。顧客が過剰にコミットしたり、利用されていると感じることは全く望ましくありません。
- 顧客に長期的なコミットメントを求める前に、パイロットまたは概念実証を行って価値を証明することをいとわないでください
- 単なる新機能開発以上に、顧客の製品採用/導入にフォーカスしたプロダクト・UX開発のリソースを割いてください
- マーケティング活動を製品に結び付けて、コミュニティを作成し、ユーザーがより成功するためのツールを提供できるようにしてください
- 顧客が製品を採用/導入するにあたってノイズにならないように価格設定はシンプルにしてください
- ユーザーが行き詰まったときには、寛大なサポートを提供してください
New Relicは、これを2月4日のInvestor Letter で、使用量課金の価格設定を採用していることを、非常にうまく説明しています。
「New Relicでは、コンサンプションモデル（使用量課金）がソフトウェア業界の進むべき道と考えています。それは、ベンダーと顧客の基本的な関係性そのものを変えるものだからです。ベンダーは、顧客が喜んで使ってくれる優れたプロダクトを作らなければ、お金をもらえないことを理解しています。コンサンプションモデル（使用量課金）は単なる収益モデルではなく、会社のすべての機能が顧客の成功に貢献できるようフォーカスしなければ、コミットメントや能力を果たすことができないということへの明確な理解でありスタンスなのです。」
#最後に - その2
あくまで、さわりでありますが、この記事が改めて自社製品のValue Metricsとは何なのか、どういうプライシングがあり得るのかを考えるきっかけに少しでもなれば幸いです。
また、今後、プライシングについての参考文献一覧、フェーズ単位でのプライシングチャレンジについて、などこれまでのヒアリングなどをまとめてきたものもどこかでシェアできたらと思っています（リクエストがあれば是非こちらまでお願いします）
それでは、明日は、 Smartly.io 坂本くんの「どうプロダクトをポジショニング・ブランディングしていくかというお話（仮）」です。お楽しみに！
ご参考
なお、プライシング全般の思考やトレンドについてはDNX Ventures倉林さんのこのnoteが一番まとまってると思っています！
要諦
- "EVC / Economic Value to Customer"（「Reference Price」+ 自社製品の他と比べた際の差別化ポイント「Diferenciation Value」= EVC。いわゆる「顧客が払える最大の価格」）を徹底して深掘りしていくこと
- Pricingの運用を徹底していくこと（Price Integrity）
- Pricingを絶えずチューニング/アップデートしていくこと（値上げだけでなく設計そのものの）
使用量課金（Usage-Based Pricing）についてはOpenViewが、記事でも参照してますが、素晴らしいまとめをしています。
その他たくさん参考資料はあるのですがまた別の機会に！