プライシング
リストプライシング vs セールスプライシング：いつ、どちらを使う？
5分で読める|2026/04/15|
プライシング価格戦略BtoB SaaS営業
この記事の要約
標準価格表で販売するリストプライシングと、営業主導で見積もるセールスプライシング。導入複雑性・契約条件・請求運用から使い分けの判断基準を整理します。
価格を公開するか、見積もりで決めるか。
SaaSの pricing page には、そのまま申し込める標準プランと、問い合わせから要件整理に入る上位プランが同居していることがあります。これは単に会社規模で分けているのではなく、導入の複雑さ、契約条件、請求運用の例外が異なるからです。
本記事では、リストプライシングとセールスプライシングの使い分けを解説します。
本記事の前提
ここでは リストプライシング = 公開価格を中心に売る方式、セールスプライシング = 営業主導で要件整理と見積もりを行う方式 として整理します。実務では、この2つを同じ製品ラインの中で併用するケースが一般的です。
この記事でわかること
- 2つの方式の定義: リストプライシングとセールスプライシングとは
- 使い分けの基準: どの場面でどちらを使うか
- ハイブリッドアプローチ: 現実的な組み合わせ方
基本情報
| 項目 | 内容 |
|---|---|
| トピック | 価格設定方式の選択 |
| カテゴリ | BtoB SaaS |
| 難易度 | 中級 |
| 対象読者 | プライシング担当、営業企画 |
リストプライシング vs セールスプライシング2つの方式の定義
リストプライシングとは
リストプライシング（List Pricing）は、公開された標準価格表に基づく価格設定です。
| 特徴 | 内容 |
|---|---|
| 価格公開 | Webサイトに価格表を掲載 |
| 交渉 | なし（表示価格で購入） |
| 購買導線 | セルフサービス |
| 一貫性 | 全顧客同一価格 |
公開価格の参考例:
- Notion pricing page: 標準プランの公開価格を案内しつつ、上位プランは別導線で扱っている
- HubSpot Product & Services Catalog: edition ごとの価格構造や追加 seat / add-on の考え方を公開している
セールスプライシングとは
セールスプライシング（Sales Pricing）は、営業主導で要件整理と見積もりを進める価格設定です。
| 特徴 | 内容 |
|---|---|
| 価格提示 | 構成や条件に応じて見積もり |
| 要件整理 | 営業・導入担当が関与 |
| 購買導線 | 営業主導 |
| カスタマイズ | 顧客ごとに異なる価格 |
営業導線の参考例:
- ServiceNow Contact Sales: demo や担当者相談から進める導線を用意している
- Workday Contact Us:
Talk to Salesを入口に product 情報の案内をしている
使い分けの判断基準
リストプライシングが適する場面
以下の条件に当てはまる場合、リストプライシングが適しています。
-
製品と契約条件が標準化されている
- 多くの顧客が同じ機能境界で運用できる
- 契約条項や請求サイクルに大きな例外が出にくい
-
価格ページだけで自己判断しやすい
- 評価に必要な情報を公開ページで説明できる
- 無料トライアルや短いデモで導入判断しやすい
-
請求の例外が少ない
- seat 追加、アップグレード、ダウングレードを既定ルールで処理できる
- 支払条件や請求先分割の個別調整が少ない
セールスプライシングが適する場面
以下の条件に当てはまる場合、セールスプライシングが適しています。
-
導入前の要件整理が不可欠
- セキュリティ、権限、連携、導入体制の確認が必要
- 複数部門の承認を経て導入が決まる
-
見積条件が案件ごとに変わる
- 最低利用範囲、支援内容、ロールアウト手順が案件で変動する
- 契約期間や更新条件を個別に調整する
-
請求運用に例外が多い
- 請求サイクル、検収、発注書、請求先の扱いが標準化しにくい
- 導入フェーズに応じて課金開始タイミングを調整したい
判断フレームワーク
| 観点 | リスト向き | セールス向き |
|---|---|---|
| 導入複雑性 | 標準化されている | 要件確認が必要 |
| 購買主体 | 少人数で自己判断しやすい | 複数部門の合議になりやすい |
| 契約条件 | 定型約款中心 | 個別見積・個別条項が発生する |
| 請求運用 | 標準サイクルで回る | 例外処理が多い |
| 営業の関与度合 | 最小限 | 高い |
ハイブリッドアプローチ
公開価格と営業導線を分けて運用するハイブリッド型は、SaaSでは珍しくありません。標準化できる範囲はリストで処理し、例外が増える領域だけをセールスへ渡す設計です。
階層別の使い分け
| レイヤー | 主な販売方式 | 典型的な扱い |
|---|---|---|
| 初回検証 | リスト | 無料トライアルや公開価格で試せる |
| 標準導入 | リスト | 既定機能・既定課金でそのまま申し込む |
| 拡張導入 | ハイブリッド | 一部だけ営業が入り、見積もりを補う |
| 全社導入・複雑導入 | セールス | 見積、契約、導入計画を案件別に設計 |
移行のタイミング
切り替えの基準は、会社のフェーズよりも「例外処理の発生率」を見る方が実務的です。公開価格だけで閉じられる商談が大半ならリスト中心でよく、例外条件が増えるならハイブリッドやセールスへ寄せます。
| 状況 | 推奨方式 | 見るべきサイン |
|---|---|---|
| 価格ページだけで大半の商談が進む | リスト | 同じプランで収まり、値引きも少ない |
| 上位案件だけ例外が出る | リスト + セールス | セキュリティ審査や個別請求が一部で発生 |
| 多くの商談で要件整理が必要になる | セールス中心 | 見積、契約、導入計画を毎回調整する |
請求への影響
価格設定方式によって、請求の運用が大きく変わります。
リストプライシングの請求
| 観点 | 特徴 |
|---|---|
| 自動化 | 高い。申込から請求まで定型化しやすい |
| 更新 | セルフサービスで処理しやすい |
| 請求サイクル | 標準化しやすい |
| 例外処理 | 少ない |
セールスプライシングの請求
| 観点 | 特徴 |
|---|---|
| 自動化 | 見積・承認・設定の handoff が増える |
| 更新 | 営業やCSが関与しやすい |
| 請求サイクル | 契約条件に合わせて変わりやすい |
| 例外処理 | 多い |
運用負荷の違い
セールスプライシングは、以下の点で運用負荷が高くなります。
- 見積と承認の設計: 誰がどこまで値決めできるかを決める必要がある
- 契約と請求の接続: 契約条件を billing 設定へ正確に反映する必要がある
- 更新時の整合性維持: 例外条件を残したまま更新すると運用が複雑化しやすい
そのため、CPQ、契約管理、請求システムの handoff を先に設計しておく方が安全です。
よくある質問（FAQ）
Q1. 価格を公開しないデメリットは？
価格非公開には以下のデメリットがあります。
- 検討から脱落: 価格がわからないと検討対象から外れる
- 不信感: 「高そう」という印象を与える
- リードの質低下: 予算が合わない問い合わせが増える
一方で、複数部門の承認や導入要件の整理が先に必要な商談では、価格を先に固定するよりも営業導線から始める方が自然なこともあります。
Q2. 値引き交渉への対応は？
セールスプライシングでは値引き交渉が発生します。
対応の原則:
- 値引き権限を deal size や契約期間ごとに定義する
- 値引きの代わりに契約期間、支払条件、導入範囲で調整する
- 例外承認の履歴を残し、更新時に同じ論点が再発しないようにする
Q3. 既存顧客と新規顧客で価格が異なる場合は？
セールスプライシングでは、同じ製品でも顧客ごとに価格が異なることがあります。
既存顧客が「新規顧客の方が安い」と知った場合、不満につながります。
対策:
- 値引き理由と適用期限を残す
- 更新時に説明できる基準を営業とCSで共有する
- 例外価格が戦略案件なのか恒常ルールなのかを分けて管理する
まとめ
主要ポイント
- 標準化度合いで使い分ける: 同じ条件で売れるならリスト、要件整理が必要ならセールス
- 請求の例外処理が判断基準になる: 契約・請求・承認の例外が増えるほど営業関与が必要になる
- ハイブリッドが実務的: 標準プランは公開価格、例外案件だけ見積もりに寄せる設計が扱いやすい
次のステップ
- 標準プランだけで処理できる商談と例外商談を分ける
- 見積、契約、請求で個別調整が発生する条件を棚卸しする
- どこから営業へ引き渡すかを価格ページと運用フローで明確にする
参考リソース
公開価格・営業導線の参考
本記事は請求/Billingシリーズの一部です。
この記事の著者
猪良 幸太郎
東京理科大学卒業後、国内独立系コンサルティングファームに入社し、IT・業務コンサルタント兼マネージャーとして業務最適化やシステム導入プロジェクトを経験。その後プライシングスタジオに入社し、執行役員兼ビジネス本部長として顧客のプライシング変革支援をリードする傍ら、自社の新規事業立ち上げの推進にも従事。
