価格表を顧客価値ベースに書き換えても、半年後には現場の値引きと個別対応で元の形に戻っている。原因は価格表の書き方ではありません。売っている価値の単位と請求書の課金単位がずれていること、そして値引きの例外を誰がどう承認するかが決まっていないこと、この2つの機構が価格表より先に固定されていないからです。
この記事では、バリューベースプライシングを導入する5ステップを扱います。ただし手順の説明そのものより、どの順番で固定すれば崩れないかという一点に絞ります。
私は、バリューベース導入の成否を分けるのは、WTP調査の精度ではなく、値引きの例外承認ルールと、失注・値引き理由の記録が、価格表より先にあるかどうかだと考えています。だから、5ステップの前半にあたる価値仮説の棚卸しやWTP確認を丁寧にする前に、後半にあたる価格表への実装と運用の仕組みから着手すべきだというのが、私がこの記事を書く順番です。
この立場を書いている自分の位置も断っておきます。ネクサフローはこのプライシング連載だけで100本を超える記事を公開しており、価格を継続的に研究している立場にあります。同時に、自社が売っているコンサルティングやSignal Foundryも、案件ごとに提供する価値の単位が揺れる商材です。工数削減として語る案件もあれば、意思決定の速さや、リスク回避として語る案件もある。価格表を作る前に価値の単位を固定する作業の難しさは、他人事として書いているわけではありません。
境界も先に引いておきます。この記事が扱うのは、営業が個別に見積もりを出すB2B商材です。価格があらかじめ固定されたセルフサーブ型のSaaSや、消費者向けの一律価格には、この順序はそのまま当てはまりません。会社の規模は前提になりません。むしろ顧客との距離が近い小さな会社のほうが、失注理由や値引きの言い訳を直接拾いやすく、この記事の前提を早く満たせることもあります。
顧客が買っている価値の単位(削減できた工数、増えた案件数、出た成果)と、請求書に載る課金単位(ユーザー数、ライセンス数、利用量)が一致しているかどうかを指します。工数削減を売り文句にしながらユーザー数で課金していれば、これはずれています。定義をここで先に置くのは、「価値仮説はあるのに価格表へ落ちない」という失敗を、反証可能な主張にするためです。ずれているかどうかは、価格表と提案資料を並べれば誰でも確認できます。
提供原価、継続的なサポートコスト、回収計画が崩れる値引きの境界です。バリューベースであっても、この下限を無視してよいわけではありません。コストプライシングの神髄で扱われている価格フロアの考え方を、そのままここで借ります。下限の上に価値の上限を積む、という接続です。
バリューベースの導入で失敗しやすいのは、調査より先に「誰が何を決めるか」が曖昧なケースです。次の4点を、価格表を書き始める前にそろえます。
すべての顧客に同じ価値を売る前提では、価値単位そのものが定まりません。対象セグメントを決めるときは、業種や会社規模よりも、価値の出方で区切るほうが実務では扱いやすくなります。
ここでもう一段区別しておきたいのは、価値を日常的に受け取る人と、価格を最終的に承認する人が同じとは限らないことです。現場の利用者が工数削減や使いやすさを便益として実感していても、予算を承認する管理部門や経営は同じ論点で納得するとは限りません。対象セグメントを決める段階で「誰が価値を受け取るか」と「誰が価格を承認するか」を分けて確認しておかないと、Step4で用意する説明材料が受け取り手にしか刺さらず、承認者には別の言葉で語り直す羽目になります。
顧客価値は、アンケートだけでなく商談やサポートの会話にも表れます。受注理由、失注理由、更新理由、利用ログ、競合比較で必ず話題になる論点。これらが記録されていないと、WTPもEVCも机上の空論になります。
提供原価と継続サポートコスト、個別対応が必要になる範囲、値引きしたときに粗利や回収計画が崩れる境界。この3つを、価値仮説を積む前に把握しておきます。
価格表を作っても、現場が例外で崩せる状態では定着しません。私がこの記事の中でもっとも重く見ているのがここです。誰が、どの条件で、どこまで例外を認めるかを、価格表より先に決めておきます。
| 決めておきたい項目 | 確認したいこと |
|---|---|
| 値引き承認 | 誰が承認者か、どの理由なら例外を許容するか |
| 追加要件 | どこからが追加費用の対象か |
| 契約変更 | 既存顧客の更新時に何を据え置き、何を見直すか |
| 失注時の記録 | 価格、機能、導入負荷のどれが理由だったか |
ここからの5ステップは、前半(Step1・2)を大きくするより、後半(Step3〜5)の運用機構を先に固める意識で読んでください。前半は仮説を作る作業、後半は仮説を崩さず回す作業です。
最初にやることは、価格案を作ることではなく、顧客が感じている価値の仮説を整理することです。「便利」「高機能」ではなく、顧客の業務や意思決定にどんな変化が起きるかまで落とします。営業、CS、プロダクト、導入担当が集まり、受注/失注メモや商談履歴を見ながら、実際の会話に出てくる価値と不安を、コスト削減・売上増・時間短縮・リスク回避・安心感のどれかに分類してください。
EVC分析ガイドは、この棚卸しを金額換算できる形へ寄せるときの補助線になります。
価値仮説を出したら、その価値に対して実際にどの程度支払う意思があるのかを確認します。手法名より、誰に、どの価値仮説を、どの文脈で確かめるかが重要です。既存顧客インタビューで導入前に比較した代替案を聞く、失注案件の「高い」が価格の話か導入条件の話かを切り分ける、小さな提案差分でどの要素が反応を変えるかを見る。このあたりまでが実務で使いやすい確認方法です。
WTP(支払い意思額)とは?や価格調査手法の種類と選び方を見ながら、調査を大きくしすぎる前に仮説と観測項目をそろえておくと進めやすくなります。
ここが、この記事の中でもっとも重要なステップです。価値仮説と価格帯が見えても、価格表が顧客に伝わらないなら、原因のほとんどは価値単位と課金単位が一致していないことにあります。
工数削減を語りながらユーザー数で課金する。成果を語りながら利用量で課金する。こうしたずれがあると、顧客は「価値の説明」と「請求書」が別の言語で書かれていると感じます。設計するときは、次の一致を確認してください。
| 売っている価値の単位 | 近い課金単位の候補 |
|---|---|
| 削減できた工数 | 案件数、処理件数、利用量 |
| 増えた売上・受注 | 成果連動、案件数 |
| 意思決定の速さ | ユーザー数よりは利用頻度・利用量 |
| 安心感・リスク回避 | 契約単位、拠点数 |
課金単位のほかにも、プラン分岐、含める範囲、例外条件、更新ルールを、同じ言葉で商談資料・見積もり・申込書・請求ロジックまでつなげます。そこがつながっていないと、次のような形で価格表が崩れます。
バリューベース価格は、営業が「高いです」で押し返された瞬間に崩れます。価格表と同じくらい、価値を説明する材料の整備が重要です。ROI試算表、課題と価値と価格根拠を一枚で説明する提案テンプレート、失注・値引きの理由を構造化して残すログ、契約更新時に利用状況と成果を振り返るレビューシート。この4つがあれば、担当者の話し方に依存せず価値を説明できます。
試算表に入れるのは、顧客の現状プロセス、現在発生している工数や外注費、導入後に減る作業や増える売上機会、導入と継続運用に必要な条件です。金額の見せ方より先に、その前提が顧客と合っているかを確認してください。計算式がきれいでも、前提条件がずれていれば価格根拠にはなりません。
ここも、Step3と並んで厚く見るべき場所です。導入後は、価格表そのものよりも、どこで摩擦が起きたかを追うほうが改善につながります。定期見直しの頻度を固定するより、次のシグナルが出たタイミングでレビューできる状態を作ってください。
| シグナル | 見たい問い |
|---|---|
| 値引き理由の集中 | 特定セグメントだけ価格根拠が弱くないか |
| 受注/失注の分布 | 価格より導入負荷や契約条件が障害になっていないか |
| アップセル/更新の反応 | 上位プランの価値が本当に伝わっているか |
| 導入後の活用度 | 価値が出る前に離脱していないか |
| 個別例外の増加 | 価格表ではなく個別対応で売ってしまっていないか |
営業会議で価格の成否だけでなく前提のズレを振り返る。CSが更新理由と活用不足の原因を同じフォーマットで残す。プロダクト側は価値の源泉になっている機能と使われていない機能を分ける。経営は売上だけでなく粗利、回収しづらい案件、例外承認の量を見る。この4つが同じ言葉で回り始めると、価格の見直しが属人的な判断ではなくなります。
ここまでの4つの前提と5ステップに沿っていても、現場では別の形でつまずきます。ただし、私が見る限り、つまずき方は多くの場合、価値単位と課金単位のズレか、例外ルールの不在か、このどちらかに帰着します。
価値仮説はあるのに、価格表へ落ちない。 原因は、価値の単位と課金単位がずれていることです。工数削減で売っているのにユーザー数だけで課金している場合、顧客にとって価格の納得感は弱くなります。Step3で定義した一致を、もう一度価格表と提案資料の間で確認してください。
競合が安いと言われて議論が止まる。 これも多くの場合、単位のズレです。顧客が比べているのは価格表の金額ではなく、導入負荷や切替コスト、サポート、失敗時のリスクまで含めた総体である一方、こちらは月額や年額という単位でしか答えていないことがあります。価格だけの比較に入る前に、顧客が本当に比べている単位を確かめてください。
営業が価格ではなく値引きで調整してしまう。 これは営業が悪いのではなく、値引きの例外承認ルールが決まっていないことがほとんどです。誰が、どの理由で、どこまで例外を認めるかが曖昧なら、営業は個別に判断するしかありません。顧客の課題、価値、導入条件、価格根拠を一枚で話せる資料を用意し、失注時は金額だけでなく理由コードを残してください。
既存顧客へどう適用すべきか決められない。 これは例外ルールのうち「契約変更」の欄が空いていることが原因です。新規顧客向けの価格表と既存契約の扱いを分け、更新時の説明材料、据え置く範囲、追加価値の示し方を、価格表を触る前に決めておきます。
5ステップをもう一度並べ直します。今度は時系列ではなく、「先に固定しないと崩れるか、あとから直せるか」という軸です。
先に固定するもの: 対象セグメントと価値の単位(Step1)、価格フロア、例外承認ルール。ここが決まる前に価格表の見た目を整えても、値引きと個別対応で必ず溶けます。
あとから直せるもの: 価格帯の精度(Step2)、プラン分岐や課金単位の細部(Step3)、営業資料の体裁(Step4)、見直しの頻度(Step5)。これらは運用しながら精度を上げられます。
私自身、次にこの枠組みをどこから直すかと言われれば、価格フロアと例外承認ルールの明文化を最初に固定し、そのあとで価値仮説の棚卸しの精度を上げる、という順番を取ります。バリューベースプライシング入門で扱った「下限はコスト、上限は顧客価値」という2本の線のうち、下限側の運用を先に固めないと、上限側の価値仮説がどれだけ精緻でも値引きで溶けてしまうと考えるからです。
価格フロアの考え方そのものはコストプライシングの神髄に依っています。つまずく場面は突き詰めれば単位のズレか例外ルールの不在に収まりますが、その手前でセグメント定義自体が曖昧なままだと、前提1で触れた「価値の受け取り手」と「価格の承認者」のズレのような形でも同じ結果に至ります。行き着く先は同じでも、どこで見誤ったかを言い分けられると、直す場所を早く特定できます。
次に自分で確かめたいのは、例外承認ルールを先に固定した組織と、価値仮説の精度から入った組織とで、価格表が定着するまでの期間にどれくらい差が出るかです。まだ観測できていないので、この記事の順序も暫定の整理として扱ってください。
次に読む