何をどれくらいの価格で売ればいいの？ ~SaaS のプライシング戦略 (実践編) ~

こんにちは、SaaS パートナーソリューションアーキテクトの櫻谷です！

この記事では、SaaS のプライシングを検討中のお客様が、自社に最適な戦略を選択できるようなステップバイステップのガイダンスを提供します。プライシングの基本的ないろはに関しては前回の考え方編の方で解説しているので、先にそちらに目を通していただくことをおすすめします。

プライシングは、新規サービスの立ち上げだけでなく、既存サービスの改善においても非常に重要なファクターです。後述するサンプルシナリオは、既存パッケージからの移行をユースケースとしていますが、今回紹介するものはどの段階のお客様でも活用可能なプロセスです。すでに SaaS を運用されているお客様は、必要な部分をピックアップし、自社に適用可能なところから見直しをしてみてください。

さて、今回は実践編ということで、大きく 4 つのステップに分けて実際のプライシングの流れをウォークスルーしてみたいと思います。イメージしやすいようにサンプルとなるサービスを例にして解説していきますが、読者の皆様も自社のサービスを頭に思い浮かべながら、どのような設計が最適か考えてみてください。

サンプルシナリオ

例として、チャットアプリケーションを考えてみます。架空の会社 AnyCompany は、エンタープライズ企業向けにチャット機能を中心としたコラボレーションツールを提供しています。このアプリケーションには、チャンネルの作成、メンバーの招待、メッセージの送受信、ファイルの添付、通話、外部のカレンダーアプリケーションとの連携、タスク管理機能などが含まれています。現在の提供形態は買い切り型のパッケージソフトウェアです。顧客は自身のネットワーク環境にアプリケーションサーバーとデータベースサーバーをデプロイし、デスクトップアプリケーションからソフトウェアを利用しています。AnyCompany は、現在このパッケージの SaaS 化を検討しており、プライシングの設計を行い始めました。

大まかな流れ

前回の考え方編で基本的なコンセプトを確認しましたが、今回は大きく以下の流れでプライシングを実施してみます。必ずしもこの順番でやらなければならないという決まりはありませんが、なるべく手戻りが少ないように先にベースとなる事業の方向性を固めるのが定石です。

バリュープロポジションの明確化
ペルソナ、ターゲットセグメント、ポジショニングの定義
パッケージングの設計
価格の設定

また、これを一度やったら終わりというわけでもなく、定期的に見直すことは必要ですし、一度の設計の中で前のステップに立ち戻って考え直すことも時には必要になるので、各ステップ間の移動は自由に行っていただいて構いません。特に、すでにプライシングを自身で設計・運用されているお客様は、再検討すべき項目だけピックアップして今の設計を見直してみるというのも良いかと思います。

ステップ 1 : バリュープロポジションの明確化

皆さんのサービスが顧客にもたらす最も本質的な価値、それがバリュープロポジションであるというお話を前回の記事でしました。「顧客はどのような課題を解決するために自分たちのサービスを使ってくれているのか？」、「何に対してお金を払ってくれているのか？」、「なぜ競合他社の製品ではなく自分たちの製品なのか？」、まずはこのような観点で社内の認識を合わせておかなければ、ビジネスモデルの根幹が揺らぐ可能性があります。

このバリュープロポジションはなるべく簡潔に、かつ具体的に表現できる形でまとめましょう。サンプルシナリオでは、チャットの他に多くの機能が含まれていますが、すべての機能が同じだけの価値を顧客に提供できているわけではありません。また、顧客によって価値を感じる場所も異なるでしょう。ここでは、根源的な課題に立ち戻って、最も製品の魅力を表現し得る、製品の存在意義に着目してください。

そもそもこのサービスはどのようなきっかけから始まったものなのでしょうか？このコラボレーションツールは、創業者自身の体験に基づいて企画されています。会社が大きくなり社員や部門が増えるにつれて、情報共有の密度が薄くなったりコミュニケーションの速度が劣化するという課題がありました。もっと情報をオープンにし、多数の部門をまたがったコラボレーションが促進され、メールよりもスピーディーなコミュニケーションを行うことができるツールがあれば解決できるのでは？そんな仮説から生まれたのがこのソフトウェアです。つまりこの製品の本質的な価値は、「情報共有・可視化」、「チーム連携の促進」、「コミュニケーションの加速」ということになります。

図2：サンプルアプリケーションのバリュープロポジション

ここでよくある間違いは、「このサービスの価値はチャット機能である」というように機能に囚われがちになることです。この考え方ではそれ以上先に思考を進めることができません。たまたま上記の価値を満たすことができる方法の一つがチャットツールだったというだけで、最適な方法は他にもあるかもしれませんし、状況の変化に応じて他の方法に置き換えることもできます。例えば文字でのコミュニケーションが苦手な人、あるいはタイピングに時間がかかる人にとっては、たくさんの文字を読み書きする必要があるチャットでのコミュニケーションは逆に面倒に感じるでしょう。前述の機能に囚われた思考では、彼らにとっての最適な方法を模索した新しいサービスを生み出すビジネスチャンスを逃してしまいます。

バリュープロポジションが決まったらそれを言語化し、メンバー全員に共有します。分かりやすくするために機能へのマッピングも補足として付け加えておきましょう。例えば以下のようになります。

「このサービスの本質的な価値は、1. 情報共有・可視化、2. チーム連携の促進、3. コミュニケーションの加速であり、チャット機能を中心にさまざまな機能を使ってそれを実現している」

これは営業資料・トークとしても使えますし、サービスを端的に表現するスローガンとしても便利です。また、課題が明示されることによって、新しい機能開発の解像度も上がります。「情報の共有漏れを防ぐためにはどんな機能があったら便利だろう？」、このように課題ドリブンでソリューションを構築していくことによって、プロダクトアウトの開発サイクルに陥るのを回避することもできます。

では、このバリュープロポジションがうまく見つけられない、あるいは顧客のニーズと乖離していた場合はどうすればよいでしょうか？効果的なビジネスの成長には、データドリブンのアプローチが不可欠です。実際の顧客の利用動向をデータから把握し、分析しましょう。分析すべき項目は、

どの機能が最も利用されているか？
どの機能がほとんど利用されていないか？
顧客の属性と利用されている機能の間に関係性はあるか？

といった基本的な観点から、

最もレベニューを上げている顧客が最も利用している機能は何か？
解約した顧客が利用していた/いなかった機能は何か？

といった一歩進んだインサイトが得られるものまで多岐にわたります。

こうして得られたインサイトを元に、ユーザーのニーズを捉えられるよう製品の方向性を微調整していきます。自分達が考えていたバリュープロポジションと大きく異なっていた場合は、事業そのものを大きくピボットさせる必要もあるかもしれません。ターゲットとする顧客セグメントを変更して、販売戦略の最適化を図るのが有効な場合もあるでしょう。何をするにしても、とにかく“データ”が必要です。

何か偏りのあるような傾向が見られる場合、そこにビジネスを成長させるポイントが隠れている可能性が高いです。ビジネスの成長には、いかに効率的にレベニューを上げるかといった観点での継続的改善が必須であり、レベニューを生まない、または誰からも利用されない機能のメンテナンスにかける無駄なコストはなるべく抑えたいところです。最適な開発リソースの配分を行うという意味でも、このような利用傾向の分析基盤は必ず整備しておきましょう。

ステップ 2 : ペルソナ、ターゲットセグメントの定義

次に、この製品を買ってくれる顧客、つまり製品が解決する課題を持っている顧客の属性や市場セグメントを定義します。パッケージから SaaS への移行の場合は、既存のターゲットセグメントに加えて新しい市場の開拓という側面も考慮する必要があります。

一般的に想定しておくべき項目を以下にまとめました。これ以外にも、製品が狙う市場がニッチなものであればあるほど、ターゲットとするペルソナの性質をさらに細分化して考える必要はあるでしょう。

ビジネスモデル: ex. BtoB / BtoC / その他
事業領域: ex. 製造 / 金融 / ヘルスケア / 小売 / エンタメ / 教育 / 政府・行政
事業規模 (売上/従業員数) : ex. エンタープライズ / SMB / スタートアップ / 個人事業主 / 一般消費者
地域: ex. 日本 or 海外 / 首都圏 or 地方
利用者の職種: ex. 営業 / マーケティング / サポート / エンジニア / 情シス / 経営者
社風: ex. 保守的 or リベラル / オープン or クローズド / 稟議が長くかかる or 個人に裁量
製品の導入状況: ex. 導入していない / 自社のパッケージを利用中 / 競合製品を利用中
重視する要件: ex. 機能の豊富さ / 使いやすさ / コスト / セキュリティ / 可用性 / サポートの手厚さ
カスタマイズの有無: ex. 標準機能を利用 / 自社の要件に合わせてカスタマイズが必須
購買プロセス: ex. 直接ベンダーから購入 / 代理店・販売パートナーから購入 / マーケットプレイスから購入
契約形態: ex. 買い切り / サブスクリプション / 包括契約 (5 年など) / 従量課金

既存パッケージの SaaS 化においては、現在パッケージを利用している顧客へのアプローチも決めておく必要があります。積極的に SaaS への移行を促すのか、5 年間は既存環境をサポートするのでその間に移行してもらうのか、SaaS を売るのは新規顧客に対してのみなのか、こういった方針も最初の内に固めておかないといつまで経っても SaaS のレベニューが上がらず、営業はパッケージ売りを優先してしまうということも起き得ます。

また、任意の 2 軸を設定して競合他社とのポジショニングマップを作っておくのも、自社の差別化要素を明確にする上で有用です。例えば、横軸に対象とするユーザーの属性を、縦軸に機能が充実している領域をマッピングすると以下のようになります。

図 3 : ポジショニングマップ

まだどの企業もリーチできていないセグメントを取りに行くのもよし、あえてプレーヤーが飽和しているセグメントに切り込んでいくのもよし、とにかく目標が明確になっていれば、社内のリソースも効率的に投入することができます。1 つではなく様々な切り口から複数のポジショニングマップを作ってみるのも効果的ですし、ぜひ国内だけでなく海外のベンダーもマッピングしてみてください。昨今のグローバルな市場において、戦うべき敵は国内だけではありません。いま日本法人がない企業でも、いつ日本に進出してくるかわからないので、海外の動向も常に注視しておきましょう。

さて、次のステップに移る前に、AnyCompany の戦略を確認しておきます。今回サンプルとしているビジネスケースは、パッケージからの移行です。エンタープライズ顧客の大規模な利用を想定して多機能なソフトウェアを提供しようとしており、その分価格も高額です。

AnyCompany はこの SaaS 移行を機に、最低限必要なコアな機能のみを抽出して安価に提供するプランを設計できないかと考えました。そうすることで、中小企業などこれまでリーチできなかった幅広いセグメントを取り込むことができるからです。また、これはある種の実験的な試みですが、学生に対して無料で提供することで企業の認知度を高める長期的な投資にも踏み切ることを検討し始めました。これらの戦略の詳細については、ステップ 3 以降で確認していきましょう。

ステップ 3 : パッケージングの設計

リーチすべき顧客層が分かったら、その顧客のニーズを満たせるようなオファリングを整備していきます。ステップ 2 で顧客の属性を想定した時、一つに絞れずに色々と迷われた方も多いのではないでしょうか？例えば社風を考えたときに、エンタープライズ企業の中でもオープンでフラットな風通しの良い組織もあれば、クローズドで官僚主義的な組織もあり、1 つに決め切るのはいささか乱暴です。また、エンタープライズの顧客とスタートアップの顧客を両方ターゲットとする場合、両者では購買のプロセスからソフトウェアに求める要件まで異なる部分が大きいため、ひとまとめにして営業戦略を練るのは無理があります。

ソフトウェアの提供する価値も同様に、ユーザーが求める機能や非機能要件に応じて最適化して提供するものを変えるべきです。これは通常、いくつかの契約プランのパターンを用意して、顧客に選択の余地を与えることで実現できます。ターゲットとする顧客の属性は細かいところまで比較すると千差万別なわけですが、各顧客にジャストフィットするプランを逐一考えていてはビジネスはスケールしませんし、契約までのリードタイムが長くなってしまいます。また、10 個も 20 個もプランがあっては、顧客が自分に最適なプランを見つけられずに購入を諦めてしまうようなことも起きます (これを選択のパラドックスと言います)。

なので、特に理由がなければ 3 つから 4 つほどのプランに収束させ、それで拾いきれないニーズはプライベートなカスタマイズ契約を結ぶように調整するのがおすすめです。皆様が普段お使いのサービスでも、ベーシックプラン、ビジネスプラン、エンタープライズプランといった大まかな区分けで提供されているものは多いのではないでしょうか。ちなみに AWS の有償サポートプランも、デベロッパー、ビジネス、エンタープライズ On-Ramp、エンタープライズの 4 つのみです。エンタープライズ On-Ramp は既存のプランが見直され 2021 年に新しく追加されたプランですが、業種も事業規模も非常に多岐に渡る AWS の顧客が、なるべく自身のニーズに合った最適なプランを選択できるようにしようという、事業者としてのサービス体験の継続的改善の姿勢を垣間見ることができます。

プランの区分けのコツですが、ユーザーのニーズとソフトウェアの機能で差別化できるポイントのバランスを踏まえて選択しましょう。AnyCompany のチャットアプリケーションでは、既存のエンタープライズ顧客に加えて、中小企業やスタートアップにもターゲットセグメントを広げることにしました。また、学生には無料で一定の機能を提供する試みも始めることにしました。以降は、エンタープライズプラン、ビジネスプラン、学生プランの 3 つの契約プランを提供する前提で進めていきます。

次に考えなければならないのは、このプランに何を提供価値として含めるかです。付加価値として他のプランと差別化できる要素が含まれている必要があります。ではこの付加価値はどのようなものが考えられるでしょうか？よくある例をいくつか見てみましょう。

ユーザー数

サービスを利用できるユーザーの数で差別化します。このパターンが有効かどうかは、ソリューションの性質によって変わります。例えばテナント 1 つにつき管理者 1 人だけが利用できればいいようなソフトウェアの場合は、あまり意味がありません。しかし今回のようなチャットアプリケーション、またはグループウェアやプロジェクト管理ツールのようなものでは、従業員全員がユーザーとなり得るので売上面でも非常に効果が見込めます。今回はこれを採用することにします。

機能

利用できる機能の数で差別化します。コアとなる機能は全てのプランで有効化しつつ、より多くのビジネス価値を生み出すための高度な機能については、上位のプランでのみ利用できる形式にします。このパターンでは、単純なアプリケーションの機能の有効化/無効化に加え、機能の“性能面”での違いをつけることも可能です。例えばメール配信の SaaS であれば、1 日に送信できるメール数の上限を 1,000 通、5,000 通、 10,000 通といったようにプランごとに変えることができます。写真や動画を保存するサービスであれば、ストレージサイズといった観点で上限を変えるのが有効でしょう。

この“性能面”での差別化は、必ずサービスのバリュープロポジションに紐づく形で行う必要があることに注意してください。より上位のプランでは、顧客はより多くのビジネス価値を得られることを期待します。つまり、その高いコストに見合うだけの価値です。チャットアプリケーションにおいて、送信できるメッセージの数やファイルサイズの上限、過去のメッセージの保存期間などをニーズに応じてコントロールできることは顧客にとって大きな価値となるでしょう。また、こういった観点は顧客の事業規模やコーポレートポリシーによって要件は様々異なるため、選択可能な契約プランという形でその差分を吸収できるのはビジネスの幅を広げる上で非常に有用です。

カスタマーサポート

サポートの手段や応答時間で差別化します。メール、チャット、電話といった複数のチャネルの利用可否、問い合わせ後返信までにかかる時間などは、意外と忘れがちですが顧客のビジネスに与える影響という意味では無視できません。ソフトウェアの機能だけでなく、こういったサービスの利用体験にも目を向けて付加価値を検討してみてください。

さて、差別化できるポイントについてはある程度整理できました。次は、課金形態です。これらのポイントに対して、どのように料金を請求していくのか、SaaS で代表的なものを確認していきます。

従量課金

課金単位 (ユニット) と単価を設定し、ユニット × 単価で請求額を割り出す方法です。すでに AWS のサービスをお使いの方は馴染みがあるかと思います。例えば Amazon EC2 オンデマンド料金のページを見ると、インスタンスの起動時間あたりの支払いで、インスタンスタイプごとに単価が設定されていることがわかります。このケースでは、課金単位は起動時間 (時間/秒) になります。この方式では、顧客が必要な分のリソースを正確な量で購入することができ、無駄のない柔軟な調達が可能になるというメリットがあります。

例えば、利用できるユーザー数を従量課金制にした場合、1 ユーザーあたり 100 円といった料金体系になります。もし 37 人といった中途半端な人数で利用したい顧客がいた場合、きっちり 37 人分を購入することで無駄なコストはかかりませんし、人数が変動した際にも対応は容易です。

この方式はユーザーにとってメリットが大きい一方で、事業者にとっては請求額の算出のための計算が必要、売上が上振れしないという点であまり旨味は得られません。

上限付きサブスクリプション

対して、上限付きサブスクリプショの方式を用いると、料金体系はシンプルになり売上も増加する可能性があります。これは、プランごとに利用できるユニットに上限を設けるやり方で、先ほどのユーザー数の例でいうと、ベーシックプランは 10 人まで利用可能、ビジネスプランは 50 人まで利用可能、エンタープライズプランは 100 人まで利用可能といった形になります。

こうすることで面倒な計算は要らなくなり、15 人といった少しベーシックプランには収まりきらない人数で使いたい顧客を、上位のビジネスプランまでアップグレードさせることができます。従量課金制と比べると顧客ファーストな方法ではありませんが、トレードオフを理解した上で事業計画に応じて慎重に採用を検討してください。

従量課金＋上限付きサブスクリプション

必ずしも以上の 2 つのどちらかを選ばなければならないというわけではありません。両者を組み合わることは可能です。プラン内の基本契約では 10 人まで利用可能、以降は 1 ユーザーごとに 150 円で追加のシートを購入可能といった形で折衷案を見出すこともできます。顧客にとっての利便性と事業として健全に利益を上げていくためのバランスを取って、最適な落とし所を見つけてください。

契約プランの設計と差別化の手法、課金形態についてだいぶ理解が深まってきましたね！色々な方法をまとめて紹介したので、選択肢が多くて設計に迷ってしまう方もいるかもしれません。そんな時は、まずシンプルな形から始めてみてください。プライシングは一度で終わる作業ではありません。ビジネスの成長や顧客の反応に応じて継続的に見直す必要があります。シンプルな形から始めて、顧客のニーズを満たせるような形式に徐々にブラッシュアップしていくような流れで進めていくのがおすすめです。

AnyCompany のチャットアプリケーションでは、以下のようなパッケージングをすることに決まりました。

学生プラン
- 無料で利用可能
- チャット機能、ファイルの添付など基本機能のみ利用可能
- メッセージの保存期間は 90 日間
ビジネスプラン
- 有償
- 50 ユーザーまで利用可能
- 基本機能に加え、カレンダーとの連携機能、タスク管理機能が利用可能
- メッセージの保存期間は 180 日間
エンタープライズプラン
- 有償
- 500 ユーザーまで利用可能 (以降、1 ユーザーごとに xxx 円で追加可能)
- ビジネスプランで利用できる機能に加え、通話機能、社外のユーザーの招待機能が利用可能 (社外ユーザーは無料で利用可能)
- メッセージの保存期間は 365 日間
オプション
- エンタープライズプラン、ビジネスプラン限定で追加のプライベート接続オプションを提供
- 過去のメッセージを永久的に保存できる追加のアーカイブ機能を提供

注目していただきたいポイントは 3 つあります。

1 つ目は、エンタープライズプランで社外のユーザーが無料で利用可能になっている点です。なぜ料金を取らないのでしょうか？それは、ネットワーク効果を利用したリファラルでの顧客獲得を期待しているためです。チャットアプリケーションのようなツールは、人数が増えれば増えるほどそのツールを導入したことの効果が発揮されます。また、ビジネスにおいては必然的に他社とのやりとりが発生し、そこで別々のツールを使い分けていては非効率です。チャットツールを導入した後は自然とここにやりとりを一元化しようというモチベーションが働く可能性が大きく、このような外部の組織の人の招待機能は役に立つでしょう。

また、SaaS においてリファラル、つまり口コミによる顧客獲得の効果は絶大です。顧客が自身でさらなる顧客を連れてきてくれるため、実質的に顧客獲得コスト (CAC) はゼロになり利益率が向上しますし、高速にビジネスがスケールします。外部から招待された顧客がまだチャットツールを導入したことがない、または既存のチャットツールに不満を抱えている場合、自分の組織でもこのツールを導入してみようという考えが働きます。いわば、自然と製品のトライアルを実施したような形になり、製品の利便性をアピールできるチャンスにつながるわけです。

もしも社外のユーザーの招待機能が有料の従量課金制で提供されていた場合、顧客は積極的にこの機能を使おうとは思わないでしょう。ここではあえて無料で提供することによって、将来的な顧客獲得のための投資を行なっているというわけです。

2 つ目はオプション機能の提供です。どのプランにも含まれないが、顧客が必要に応じて追加購入できる形で提供をしています。必要ない機能がたくさん含まれていては、顧客もプランの料金を割高に感じる可能性があるため、本当に少数の人しか使わないであろう機能はアドオンにしてしまうのがおすすめです。「ご一緒にポテトはいかがですか？」というような形で販売するイメージです。ちなみに例に挙げたプライベート接続オプションについては、AWS PrivateLink を用いて実現することができます。

これを究極まで押し進めた形が AWS の Bulding Blocks という考え方です。AWS は 200 以上のサービスを提供していますが、アカウントを作成した時点で発生する料金はありません。必要なサービスを必要なだけ使い、そして使った分だけ請求されるという課金形態になっているので、顧客は任意のサービスを好きなように組み合わせて、無駄なコストを支払うことなく自身が得たい価値を得ることができるようになっています。好きな積み木 (Blocks) を組み合わせて構築できる (Bulding) という考え方で、これを Bulding Blocks と呼んでいます。

ステップ 4 : 価格の設定

最後に、価格の設定です。課金形態とパッケージが決まっているので後は決めの問題ですが、考え方編でも解説した通り、顧客の視点、事業者の視点、第三者の視点を漏れなく検討して決めていきましょう。

まずは PSM 分析といった手法で顧客の価格に対する意識を調査したり、ステップ 2 で作成したポジショニングマップに従って競合製品の価格帯の分析を行います。これで算出できた一定の価格幅をベースに、サービスの運用コスト (販管費、開発費、運用保守にかかるインフラコスト) を重ね合わせて利益率の調整や損益分岐点の見極めを行います。すぐに黒字を目指すのではなく、1 年後、2 年後といったスパンで、将来的に獲得できる顧客の数やチャーンレート、アップセル率、コスト削減の見積りを精緻に行い、黒字化のタイミングをシュミレートしてください。短期間での黒字化、利益率を重視しすぎると大抵の場合顧客にとっては高すぎる料金となる可能性が高いため、この辺りは中長期的な視点で設計してください。

図 6 : PSM 分析

また、無料の学生プランでは当然ながら利益は上がりません。ここはある種のコストセンターです。ただし、早い段階から学生にツールに慣れてもらい、社会人になってから入社した会社で導入が進むことは期待されます。また、社会貢献という意味では会社のイメージにはプラスに働くでしょう。このように学生プランは将来的な投資で基本的にはコストになるものであって、その分ビジネスプランとエンタープライズプラン、そしてオプションの販売で利益を上げていく必要があります。契約後も、ビジネスプランの顧客に対しては積極的にエンタープライズプランへのアップセルを促すことで、利益率を高めていくという活動も重要になってきます。

つまりここで言いたいのは、プランごとにビジネスの健全性に与える影響は異なることを認識しましょうということです。「先月と比べてユーザー数が 3 倍になった！」と喜んでいても、そのほとんどが学生プランのユーザーだった場合、それはむしろ現時点での売上的には大きなマイナスを意味します。どのプランの顧客が何パーセント程度なら事業として健全なのか、そういった観点でもビジネス状況を逐一分析するようにしておきましょう。

サンプルとなるチャットアプリケーションでは、以下のような料金体系と目標値を設定しました。

学生プラン：無料
ビジネスプラン：月額 9,800 円 (利益率 40 %)
エンタープライズプラン：月額 19,800 円 (利益率 70 %)
- 追加の 1 ユーザーごとに +100 円
- ※ 2,000 ユーザー以上でお使いをご希望のお客様は別途お問い合わせください
オプション
- プライベート接続オプション：月額 5,000 円
- メッセージのアーカイブ機能：1 GB ごとに月額 100 円

料金の妥当性はサンプルなので無視していただいて構いません。重要なのは、エンタープライズプランではビジネスプランに比べて 3〜4 倍の利益が得られるという点です。この点を営業含め組織全体で認識し、積極的にアップセルを仕掛けるように動きましょう。また、2,000 ユーザー以上の注意書きについても注目してください。これは、プライベートプライシングを示唆しています。

世の中には上位のプランの料金を明示せずに、「お問い合わせください」という一言でぼやかしているサービスが多数存在します。それらは、顧客の事業規模や要望に応じて別途交渉の機会を設けて料金を見積もる方式が採用されています。これのメリットは、事業者の利益を確保しつつ、顧客の契約率を上げられることです。例えば非常に大規模なグローバル企業にとって、1 ユーザーごとに追加料金がかかる料金体系は、運用も予算採りも面倒かもしれません。また、月額料金ではなく 3 年間の長期的な契約をコミットする代わりに、大幅なディスカウントを要求してくるかもしれません。

このようなエッジケースを拾うためのプライベートな交渉のスキームは用意しておいてもよいでしょう。ただし、すべての見込み顧客に対して交渉するようなことは避けてください。余分な営業コストもかかりますし、ビジネスとしてスケールしません。プライベートプライシングはあくまで最終手段、大口顧客を落とすための切り札として考えてください。

まとめ

AnyCompany のチャット SaaS のプライシングが完成しました！ステップごとにサンプルとなるビジネスケースを考えながらウォークスルーすることによって、契約プランの設計と差別化の手法、課金形態などについてだいぶ理解が深まったのではないでしょうか。さまざまなビジネスモデルがあり得る SaaS の市場においては、最適なプライシングの形態もまた千差万別で、銀の弾丸のような一般解を提示することはなかなか難しいです。そのため、この記事ではなるべく多くの範囲をカバーできるようにさまざまな方法を紹介しました。何が最適なものなのかは、皆様自身で決めていただく必要があります。AWS からも必要に応じてディスカッションのサポートをさせていただくこともありますが、皆様のビジネスのことを一番よく理解しているのは皆様自身です。本連載で紹介した考え方を参考に、顧客にとっても自社にとっても最適なプライシングを試行錯誤してみてください。

最後に、最低限検討しておくべき項目を網羅した簡単なチェックリストを設けました。現在のプライシングの見直しにもご活用ください。

サービスの本質的な価値はなんですか？顧客のどんな課題を解決するものですか？
顧客が特に魅力を感じているサービスの機能は何ですか？
顧客はどの機能にならもっとお金を払ってもいいと感じていますか？
ターゲットとする顧客の属性や市場セグメントはなんですか？
ターゲットとする顧客のペルソナは複数ありますか？それぞれどのような点が違いますか？
現在のサービスは各ペルソナのニーズに応じた価値を提供できていますか？
顧客がニーズに応じてサービスから得られる価値を選択できるようになっていますか？
契約プランが多すぎたり、顧客が選択できないほど複雑になっていたりはしませんか？
上限や従量課金の仕組みは顧客にとって有用なものになっていますか？
上限を大きく超えて利用したい顧客向けのプランまたは交渉の仕組みはありますか？
顧客が価値を感じない部分に課金単位が設定されていたりはしませんか？
各契約プランの利益率は想定されていますか？また、上位のプランほど数値は高くなっていますか？
各契約プランの契約数の目標割合は設定されていますか？
中長期的な顧客獲得数、チャーンレート、LTV といった KPI は設定されていますか？
極端に短い黒字化の目標は設定されていませんか？
利益を追求しすぎて、顧客にとって高すぎる価格になっていませんか？
競合製品の価格を意識しすぎて、サービスが提供する価値に見合わない価格になっていませんか？
積極的にアップセルを仕掛ける戦略はありますか？

Amazon Web Services ブログ