SaaSの有料プランは、機能を並べるだけでなく、誰に、どの価値を、どの単位で提供するかを基準に設計します。基本は、料金の基準となる「課金単位」を決めたうえで、利用規模や必要な機能に合わせて複数のプランを構成する方法です。
設計時は、顧客が料金の違いを理解できること、利用量が増えたときに自然に上位プランへ移行できること、提供側が継続して利益を確保できることの3点を確認します。
SaaSの有料プラン設計で最初に決めること
最初に決めるべきなのは、機能ではなく「顧客が価値を感じる対象」と「料金を計算する単位」です。ここが曖昧なままプランを作ると、料金表が複雑になり、顧客にも社内にも説明しにくくなります。
1. どの顧客を対象にするか
同じSaaSでも、個人、小規模企業、中堅企業、大企業では、必要な機能や予算、契約時の確認事項が異なります。まずは、主な顧客層を分けて考えます。
- 個人や小規模チーム：導入の手軽さや低い初期負担を重視する
- 成長中の企業：利用人数の増加や管理機能を重視する
- 大企業：権限管理、セキュリティ、契約やサポートの柔軟性を重視する
すべての顧客を1つの料金表で対応しようとすると、条件が増えすぎます。最初は最も重要な顧客層を1つに絞り、その顧客が比較しやすい構成から始めると設計しやすくなります。
2. 顧客が価値を感じるものを特定する
顧客が「利用するほど成果が大きくなる」と感じる指標は、料金の基準に向いています。たとえば、次のようなものがあります。
- 利用ユーザー数
- 処理した件数や取引件数
- 保存データ量
- 利用プロジェクト数
- 送信メッセージ数
- 利用する機能やモジュール
- 導入する拠点数
課金単位は、提供コストだけでなく、顧客が成果と結び付けて理解できるかで判断します。たとえば、顧客が成果を「チーム全体で使うこと」と考えているのに、個人単位で細かく課金すると、料金への納得感が下がる可能性があります。
SaaSの料金体系はどの方式にするか
料金体系には複数の方式があります。自社のサービスに合う方式を選び、必要以上に課金要素を増やさないことが重要です。
| 料金体系 | 計算方法 | 向いているサービス | 注意点 |
|---|---|---|---|
| 定額制 | プランごとに一定額を支払う | 利用量の差が小さいサービス | 利用量が多い顧客と少ない顧客の差を反映しにくい |
| ユーザー課金 | ユーザー数に応じて支払う | 利用者数と価値が連動するサービス | 利用者を増やすことが顧客の負担になりやすい |
| 段階制 | 一定の利用量ごとに料金が変わる | 料金を分かりやすく示したいサービス | 上限を少し超えただけで料金が大きく変わることがある |
| 従量課金 | 利用量に応じて料金を計算する | 処理量や通信量が価値に直結するサービス | 月額を予測しにくい場合がある |
| 機能別課金 | 利用する機能やモジュールごとに支払う | 機能ごとに顧客層が分かれるサービス | 料金表が複雑になりやすい |
| 基本料金と従量課金 | 固定料金に利用量に応じた料金を加える | 基盤利用と利用量の両方にコストがあるサービス | 固定費と変動費の両方を明確に説明する必要がある |
定額制が向くケース
顧客ごとの利用量に大きな差がなく、料金を簡単に説明したい場合は定額制が向いています。予算を立てやすく、営業や問い合わせ対応も比較的簡単です。
一方で、利用量が極端に多い顧客がいる場合は、定額料金だけでは提供コストを吸収できない可能性があります。一定量を超えた場合の上位プランや追加料金も検討します。
ユーザー課金が向くケース
利用者が増えるほど価値が大きくなり、ユーザー数も把握しやすいサービスでは、ユーザー課金を使いやすいでしょう。
ただし、料金を抑えるためにアカウントを共有するなど、利用を制限する行動が起きることがあります。実際の利用形態が「登録ユーザー数」と一致するかを確認する必要があります。
従量課金が向くケース
処理件数、通信量、保存量などが顧客の成果や提供コストと連動する場合は、従量課金が適しています。利用が少ない顧客の負担を抑えながら、大量利用にも対応できます。
ただし、顧客が月額を予測できないと、導入をためらうことがあります。利用量の見込みを表示したり、上限設定や利用通知を用意したりすると、料金への不安を抑えやすくなります。
プラン構成は3段階を基本に考える
プラン構成に迷う場合は、無料または低価格の入口、標準プラン、上位プランの3段階から検討します。3段階にすると、顧客が利用規模や必要な機能で比較しやすくなります。
| プランの役割 | 主な対象 | 設計の考え方 |
|---|---|---|
| 入口プラン | 個人、小規模チーム、試用段階の顧客 | 主要な価値を体験できる範囲に抑える |
| 標準プラン | 継続利用する一般的な顧客 | 最も多く選ばれる想定で、必要な機能をまとめる |
| 上位プラン | 大規模利用、管理者、複数部署 | 利用上限、管理、連携、サポートなどの要件に対応する |
入口プランの設計
入口プランは、単に機能を減らした最安プランではありません。顧客がサービスの中心的な価値を理解できる一方で、利用規模や管理要件が増えたときに上位プランへ移る余地を残します。
入口プランで制限する候補には、ユーザー数、プロジェクト数、保存期間、連携数、履歴の保持期間などがあります。ただし、中心機能を制限しすぎると、サービスの価値を体験できません。
標準プランの設計
標準プランは、対象顧客の多くが無理なく使える内容にします。最も売りたいプランを標準にする場合は、入口プランとの差と、上位プランへ移行する条件を明確に示します。
標準プランの機能を増やしすぎると、上位プランを選ぶ理由がなくなります。標準プランには日常利用に必要な機能を、上位プランには組織管理や高度な運用に必要な機能を配置すると、違いを説明しやすくなります。
上位プランの設計
上位プランは、単に上限を増やしたものではなく、規模の大きい顧客が必要とする運用機能を含めます。候補には、次のようなものがあります。
- 高度な権限設定
- 複数チームや複数拠点の管理
- 監査用の操作履歴
- 外部システムとの連携
- データのエクスポート
- 導入支援や優先サポート
- 契約や請求方法の個別対応
これらを提供できる体制がない場合は、機能やサポートを料金表に含めないようにします。販売上の見せ方だけで上位プランを作ると、契約後の提供負担が大きくなります。
プラン間の差は「機能」と「利用量」を分けて設計する
プランの違いは、機能の有無と利用量の上限を分けて整理すると分かりやすくなります。どちらも一度に変更すると、顧客が料金差の理由を判断しにくくなるためです。
機能で分ける場合
利用目的や組織の成熟度によって必要性が変わる機能は、プラン差にしやすい項目です。たとえば、管理機能、外部連携、分析機能、監査機能などが該当します。
ただし、基本的な価値を生む機能まで上位プランだけにすると、下位プランの満足度が下がる可能性があります。中心機能と管理・拡張機能を分けて考えます。
利用量で分ける場合
ユーザー数、保存容量、処理件数などは、顧客の成長に応じて上位プランへ移行する理由になります。利用量が増えるほど顧客の成果も増えるサービスでは、自然な料金設計になりやすい方法です。
利用量の上限は、顧客が自分で確認できるようにします。上限に近づいたときの通知や、超過時の扱いも料金ページや契約条件に記載します。
料金はコストと顧客価値の両面から決める
料金は、提供コストだけで決めるのではなく、顧客が得る価値と比較して検討します。コストを下回る料金では継続提供が難しくなり、価値に対して高すぎる料金では導入されにくくなります。
最低限確認するコスト
- クラウドや外部APIなどの利用費
- 開発・保守にかかる人件費
- カスタマーサポートの費用
- 営業や決済にかかる費用
- 導入支援や個別対応の費用
特に従量課金を採用する場合は、利用量が増えたときに費用も増えるかを確認します。利用量の多い顧客ほど損失が大きくなる構造なら、上限、追加料金、上位プランなどで調整します。
料金を決める計算例
仮に、1社あたりの月間変動費が利用量によって変わり、固定的な運営費も契約数に応じて負担するとします。この場合、料金は次のような考え方で確認できます。
必要な月額料金 ＝ 1社あたりの変動費 ＋ 1社あたりの固定費負担 ＋ 継続運営に必要な利益
これは料金を自動的に決める式ではなく、最低限必要な水準を検討するための計算例です。実際には、顧客が感じる価値、競合との違い、販売コスト、契約期間なども合わせて判断します。
無料プランと無料トライアルは役割を分ける
無料プランは継続的に使える範囲を提供する仕組みで、無料トライアルは有料機能を一定期間試してもらう仕組みです。目的が異なるため、同じものとして設計しないことが大切です。
| 項目 | 無料プラン | 無料トライアル |
|---|---|---|
| 利用期間 | 期限を設けないことが多い | 一定期間に限定する |
| 体験範囲 | 機能や利用量を限定する | 有料プランの機能を広く試してもらう |
| 目的 | 利用者を増やし、継続利用につなげる | 有料契約前の判断材料を提供する |
| 注意点 | 無料利用のコストが継続する | 終了後の料金やデータの扱いを明確にする |
無料プランを設ける場合は、無料利用者へのサポート範囲、利用上限、データ保持、広告表示の有無、有料化する条件を先に決めます。無料プランを必ず設ける必要はなく、導入時に説明や設定支援が必要なサービスでは、無料トライアルやデモのほうが合う場合もあります。
年払いと月払いの条件を設計する
月払いは始めやすく、年払いは契約を継続しやすいという違いがあります。両方を用意する場合は、料金差だけでなく、途中解約、返金、利用量の変更、請求書の発行条件も明確にします。
年払いを月払いより安くする場合は、単純に月額を下げるのではなく、契約期間と支払時期を含めた総額を表示します。たとえば、月額と年額の両方を示すと、顧客が比較しやすくなります。
利用量が月ごとに大きく変わるサービスでは、年契約の最低利用量や超過料金が問題になることがあります。契約前に、利用量の変更方法と請求のタイミングを確認できるようにします。
料金表は顧客が比較できる形にする
料金表では、プラン名と金額だけでなく、対象者、主な機能、利用上限、追加料金の有無を同じ項目で並べます。顧客が「自分はどのプランか」を判断できることが重要です。
最低限、次の内容を明記します。
- 料金の単位（月額、年額、ユーザー単位など）
- 税込みか税別か
- 含まれるユーザー数や利用量
- 超過時の料金と扱い
- 利用できる主な機能
- 無料期間や無料プランの条件
- 初期費用や導入支援費の有無
- 支払い方法と契約期間
- 解約やプラン変更の条件
「無制限」「すべての機能」といった表現を使う場合は、対象範囲を明示します。実際には保存期間、サポート、API利用、同時接続数などに制限があるなら、料金表や利用規約で分けて記載します。
有料プランを公開前に検証する方法
公開前には、料金そのものだけでなく、顧客がプランを選び、利用を続け、必要に応じて上位プランへ移れるかを検証します。
- 想定する顧客ごとに、最初に選ぶプランを決める。
- 各プランで、顧客が得られる成果と利用上限を書き出す。
- プラン間の違いを、機能・利用量・サポートに分けて比較する。
- 利用量が増えた場合に、どの条件で上位プランへ移るかを確認する。
- 利用量が多い顧客でも、提供コストを下回らないか計算する。
- 無料利用者へのサポートやデータ保管の負担を確認する。
- 料金表を見た人が、追加説明なしで自分のプランを選べるか確認する。
- 問い合わせ、申込率、解約、プラン変更などの結果を見て条件を見直す。
実際の利用データが少ない段階では、最初から複雑な料金体系にせず、少ないプラン数で始める方法があります。顧客の利用量や問い合わせ内容が蓄積した後に、上限や機能の分け方を調整します。
設計時に避けたい料金体系
避けたいのは、顧客が料金を予測できず、プラン間の違いも説明できない構成です。次のような状態になっていないかを確認します。
- 課金単位が多すぎて、月額を計算できない
- 安いプランではサービスの中心価値を体験できない
- 上位プランの違いが、単なる機能の追加だけになっている
- 利用量が増えると、提供側のコストだけが大きく増える
- 無料プランの利用者にも有料顧客と同じ対応を約束している
- 追加料金や超過時の扱いが料金表に書かれていない
- 営業担当者によって説明や割引条件が変わる
割引を設定する場合も、対象、期間、適用条件、終了後の料金を明確にします。割引後の料金だけが強調されると、契約後の通常料金との認識に差が生じる可能性があります。
SaaSの有料プラン設計で最初に行うこと
まず、対象顧客が感じる価値と、その価値に近い課金単位を1つ決めます。そのうえで、入口・標準・上位の各プランについて、対象者、主な機能、利用上限、料金、上位プランへ移る条件を表にまとめます。
有料プランは、最初から完成形を作るものではありません。顧客が料金を理解でき、提供コストを維持でき、利用拡大に合わせて自然に選び直せる構成になっているかを確認しながら、実際の利用状況に合わせて見直します。
