ども、@kimihom です。
先日の JP_Stripes で掲題のタイトルで登壇したので、その報告と補足について書く。
契約企業ごとに変わる支払い金額の差をどうカバーするか
上記資料の"3大プライシング方法"のうち、ライセンス or 従量課金を選択すると、顧客によって払っていただく料金の規模が大きく変わってくる。1ライセンスだけ契約する企業と、100ライセンスを契約する企業が出てくる。
さてこの場合、企業という単位では1社に過ぎないけど、退会されては困るのは100ライセンスを契約していただいている企業となる。そうなると、100ライセンスを持つ企業の声が大きくなってきて、機能要望はそうした企業の意見を受け入れやすくなる。ここが一つのジレンマで、100ライセンスを持つ企業の要望てのは、大抵の場合1ライセンスの企業にとっては不要な機能であることが多い。その中で私たちはどうやってみんなが満足するサービスを提供すればいいのだろうか?
一つの解決策はプランを複数用意することだろう。プランとライセンスを組み合わせる方法だ。5ライセンスまではAプランで契約できて、100ライセンスはCプランを契約する。プランごとに提供する機能を変えれば解決である。ただこの場合はプロダクトの料金体系がやや複雑になる。プライシングではこうした判断が求められることが多く出てくる。反対にプランだけできっかり分けてしまうと、5人でそのプラン使うのと、50人でそのプランを使うのとで同一の金額となってしまう問題が起きる。それは大抵の場合、本来回収できるはずの金額を回収できないリスクが出てくる。
話していくうちに感じたのは、やはり3大プライシング方法(プラン、ライセンス、従量課金)は組み合わせるべきなんじゃないかということだ。そうすることで、全ユーザーが納得いく料金体系ができるのではないかと考えている。
大量のライセンス契約時の特別対応
また、大量の契約をしていただける企業が出てきた場合のボリュームディスカウントに関する議論も出てきた。実を言うと私の運営するサービスもつい最近ボリュームディスカウントの提供を開始した背景がある。このボリュームディスカウントの話を、全ての企業に知らせるのか個別に連絡するのかという判断が必要になってくる。個別に連絡する場合には顧客に特別感を与えることができる反面、今後一気にライセンスを上げたくても料金がネックで上げづらい環境にいる企業に対して事前にお知らせすることができない点がある。
また、このレアケースだけのための特別なプライシング体系が出てくるので、そのための実装が必要だ。Stripe に乗っけずに自前で実装しているケースだと大変だけど、Stripe に乗せていれば新しいプランを作って手動で対象企業のプランを変えればいいだけなので、問題ないだろう。
大きな企業であればあるほどクレジットカード決済を嫌う傾向にある。銀行振込によるサポートを実現すべきかそうでないかの判断が必要になってくる。こうした特別対応が増えていったときに、サービス運営に支障が出るようになるかならないか。これも SaaS 共通で出てくる課題となろう。
複雑さと公平さのジレンマ
ライセンス数による SaaS プライシングを設定していると、「利用途中のライセンス追加や削除をどう実装するか」って問題が出てくる。例えば、既に3ライセンス(1,000円 x 3)を契約していて、月途中で1ライセンスを追加するケースだ。既にユーザーは3ライセンス分の料金を支払っており、残り1ライセンスをどのように徴収するかという議論である。
2つ方法があって、月途中であっても1,000円を徴収する方法と、日割り料金(Proration)だけを徴収する方法だ。"複雑さを無くしたい"のを優先するならば、月途中でも1,000円を徴収した方がユーザーとしてはわかりやすいだろう。ただしタイミングによって不平等なケースが出てくる。なのでいつでも平等に課金したいなら日割り料金を決済する必要が出てくる。
この議論で思ったのは、ライセンス費用がどのくらいなのかという点だ。1ライセンスあたりの金額が本当に微々たるものなのであれば、複雑さを排除して月途中でも同額で決済して問題ないだろう。このライセンスあたりの金額がいくら以上になったら日割りも検討すべき、とかは顧客層によっても変わってくるかもしれない。
GROWTH に関する本をゲット
イベント内の企画で、こちらの本をいただいた。よくよく見ると、"Stripe Press" ていう Stripe が発行した本のようである。
2018/7/17 できたてホヤホヤで、日本語訳はまだ出版されていない本だ。ちょうど英語勉強も兼ねて英語の本を読み漁っていたので、300ページ以上あるけども、コツコツ読んでいこうと思う。
終わりに
今回は SaaS におけるプライシング設計とそこで生まれてくる課題について議論できた場となった。こういうのを情報共有できる場って実はあんまりなくて、各企業が各々で悩んでいるような状況のように思うので、こういう場は貴重だろう。
JP_Stripes の参加者としては、割と Stripe Connect のマーケットプレイス型の課金体系に興味がある方が多かったように思う。次回の JP_Stripes はこの Stripe Connect がテーマなようなので、興味ある方はぜひ参加してみてほしい。