ボリュームディスカウント設計｜数量帯は境目から崩れる

数量割引のテーブルは、割引率をどれだけ丁寧に刻んでも壊れることがあります。壊れる場所は率の深さではなく、たいてい境目の置き方です。数量が境目を超えた瞬間に単価だけを切り替え、請求・提供範囲・例外承認という運用を境目でそろえて切り替えていないと、テーブルは表向き残ったまま、運用の内側から空洞化していくはずです。

この記事は、値引きの許容範囲を「率ではなくフロア価格からの距離」で設計すべきだと書いた値引き戦略の基本、そして値引き理由コードと承認ガードレールを扱った値引き依存からの脱却方法の延長として書いています。あの2本が扱ったのは、案件ごとに交渉で発生する一回きりの値引きでした。数量帯には、交渉ではなく「量が増えるほど単価が自動で下がる」という別の壊れ方があり、率の議論を数量帯まで広げておく必要があると考えて書いています。

私は、数量帯の境目は割引率の刻みからではなく「運用が切り替わる点」、つまり請求・導入支援・例外承認が変わる点に置くべきだと考えています。数量が増えるだけで単価が自動的に下がる帯は作らないほうがよい、というのが本記事の立場です。これは、受注ログと例外承認ログを追える継続取引の組織に限った主張です。単発のスポット販売や、変動原価がほぼゼロで運用負荷も数量に比例しない商材では、境目の設計より率そのものの勝負になる場面があり、そこまでは言い切れません。

ボリュームディスカウントは、数量帯に応じて単価や契約条件を切り替える設計です。向きやすいのは、発注量に応じて原価や作業量が変わる、利用席や拠点数のように単位が明確、同じ取引先でも月ごとに数量が上下する、といった継続取引の商材です。

前提: 単価の境目と運用の境目を分けて考える

数量帯の"境目"には、性質が違う2種類があります。この区別を先に固定しておきます。

単価の境目: ある数量を超えると、適用される単価が変わる点です。価格表にそのまま載る、いちばん目につく境目です。

運用の境目: ある数量を超えると、請求の出し方、導入支援の範囲、例外承認の要不要など、運用そのものが切り替わる点です。価格表には載らず、現場の慣習として存在していることが多くなります。

本記事の中心の主張は、この2つの境目がずれたときにテーブルが空洞化する、というものです。単価の境目だけを見て数量帯を刻み、運用の境目を放置すると、単価は変わったのに運用は変わらない帯と、運用は変わったのに単価表では同じ帯として扱われている数量の、両方が生まれるはずです。前者では原価と単価の対応がずれ、後者では現場が独自に例外条件を作り始めます。以下、数量帯の"境目"という言葉は、単価の境目と運用の境目の両方を指すものとして使います。

最初に決めたい3つの前提

数量帯を置く前に、少なくとも次の3点を決めておくと後戻りが減ります。

「何を1単位とみなすか」という論点は、従量課金と定額の選び方で扱った価値単位の議論と同じ判断軸です。単位の決め方はそちらに譲り、本記事は境目の設計に絞ります。

課金ロジックを先に選ぶ

数量帯の前提が決まったら、単価計算の考え方を選びます。よく使われるのは all-units と incremental という2つの実在する課金ロジックです。

all-units: 境目を超えたら、その注文全体に新しい単価を当てる考え方です。見積は作りやすい一方、境目の前後で総額の見え方が大きく変わりやすくなります。

incremental: 境目を超えた分だけ単価を切り替える考え方です。総額の変化はなだらかになりますが、見積ロジックと請求表示は複雑になります。

価格の崖

all-unitsで起きやすいのが、数量を1つ増やしただけで合計額がかえって下がる、あるいは境目の直後だけ跳ね上がって見える現象です。本記事ではこれを「価格の崖」と呼びます。体感の問題ではなく、計算構造から機械的に発生する現象です。

たとえば、1〜19単位は単価1,000円、20単位以上は単価900円という設計をall-unitsで仮に置くと、次のようになります。

19単位から20単位へ、数量を1つ増やして発注した顧客の合計額が、all-unitsではかえって1,000円下がります。段数が増えるほど、この崖は大きく開きます。incrementalであれば、同じ20単位でも合計は19,900円に留まり、数量を増やした分だけなだらかに増えます。

境目の前後で見積が不自然に見えないかは、この崖を実際に計算して確認するのが早いはずです。19単位と20単位、49単位と50単位のように、切り替わる直前と直後を試算します。

崖を潰す方法は、次のどれかです。

• incrementalに寄せる
• 境目の直前後だけ個別見積の帯に移す
• 境目をまたいだときの見積例を価格表に添える
• 切り替え時に含まれる範囲も同時に見直す

境目は受注ログから置く

数量帯は、理想の段数から決めるより、実際の受注ログや利用ログから置いたほうが長続きします。見るべきなのは「きれいな等間隔」ではなく、注文が集まりやすい塊です。

なぜ等間隔ではなく塊になるかというと、発注側の意思決定は在庫、予算、稟議の単位に引っ張られるためだと考えられます。顧客の発注ロットや予算消化のタイミングは、価格設計側の都合とは無関係に、きりのよい数字や自社の在庫サイクルに合わせて固まりやすいのだと思います。境目をこの塊からずらして置くと、塊のちょうど真ん中を境目が横切ることになり、似たような発注が単価の違う2つの帯に分かれてしまいます。

境目を置く手順

1. 直近の見積や受注を数量順に並べる
2. 同じくらいの数量が繰り返し出る帯を探す
3. 受注処理や導入支援が切り替わる点と重ねる
4. 境目の前後で総額の違和感がないかを試算する

境目を決めるときの見取り図

段数は説明できる範囲に抑える

数量帯を細かく刻むほど最適化しやすく見えますが、営業説明と請求運用が追いつかなければ長続きしません。迷うときは、現場が口頭で説明できる段数から始め、例外が増えた帯だけ追加で分けるという順番のほうが、最初から精緻な段数を決めるより結果的に早く収束するはずです。

単価より先に採算ラインを置く

数量帯を作るときに先に決めたいのは、どこまで単価を下げても採算が残るかです。ここが曖昧だと、大口見積のたびに「今回は特別」となり、標準テーブルが空洞化します。

採算ラインに入れたい要素

• 1単位ごとの変動原価
• 導入支援や請求変更の手作業
• 個別設定や運用相談の追加負荷
• 例外処理が起きたときの吸収余白

採算ライン = 変動原価 + 運用負荷 + 例外吸収分 + 残したい余白

この式は、値引き戦略の基本で定義した「フロア価格」（変動費＋個別対応コスト＋最低限必要な粗利）を、数量帯という軸に広げたものだと考えています。あの記事では、値引きの許容範囲を率ではなくフロア価格からの距離で測るべきだと書きました。数量帯についても同じで、採算ラインという下限からどれだけ距離があるかで単価を決めるべきで、率や段数の見た目のきれいさを優先すべきではないと考えています。

私は、数量が増えるほど単価が自動で下がる帯は作らないほうがよいと考えています。理由は、原価が下がる帯と手作業が増える帯が、同じ数量帯の中に同時に存在することが多いからです。数量が増えれば1単位あたりの変動原価は下がりやすい一方で、大口ほど導入支援や個別調整の手作業も増えやすく、この2つの動きは必ずしも相殺しません。単価だけを機械的に下げると、原価の下がり方を追い越して採算ラインを割る帯が生まれます。

単価以外も一緒に切り替える

数量帯が変わるときは、単価だけでなく次の項目も一緒に見ます。

標準テーブルの外に出すもの

数量帯の表に何もかも詰め込もうとすると、単価テーブルは急に読みにくくなります。ここでは、数量帯の表から意図的に外したほうがよい3種類を整理します。

コミット条件は別レイヤーで扱う

数量帯とコミット条件（最低数量の約束、複数年契約など）を同じ表に混ぜると、単価テーブルは急に読みにくくなります。継続前提の約束を付けるなら、数量帯とは別レイヤーで管理したほうが整理しやすくなります。

点検したいのは次の項目です。

• 最低数量をどの期間で見るか
• 未達時にどう扱うか
• 超過分を同じ単価で扱うか
• 更新時にどのログを見直すか

数量帯の表には標準条件だけを置き、個別のコミット条件は見積書や別紙で管理すると、標準テーブルが崩れにくくなります。

個別見積へ移す目安

次のような帯に入ったら、標準テーブルの外へ出すという判断のほうが、結果的に運用が軽くなるはずです。

• 数量よりも導入支援の重さが支配的
• 請求の締め方や検収条件が個別化する
• 標準の提供範囲では収まらない
• 例外承認が毎回必要になる

数量帯と上位プランを混ぜない

数量が増えただけでなく、運用の重さや権限管理まで変わるなら、それは数量帯ではなく上位プランとして分けたほうが説明しやすくなります。たとえば席数が増えるだけなら数量帯で吸収できますが、席数の増加にともなって管理者権限、監査ログ、専用サポート窓口まで必要になるなら、それはもう「同じ商品の大口版」ではなく別の商品です。単価の話と提供範囲の話を同じ表に混ぜないことが、標準テーブルを長持ちさせる分岐点になると考えています。

例外承認ログを残す

ボリュームディスカウントは、テーブルそのものよりも例外運用のほうから崩れやすい設計です。誰にどの単価を出したかだけでなく、なぜその条件にしたかを残しておく必要があります。

最低限残したい項目

この5項目は、値引き依存からの脱却方法で扱った値引き理由コードと承認ガードレールを、数量帯という文脈に当てはめたものです。あの記事でも書いた通り、理由コードが曖昧なままだと、競合対抗も予算不足も導入範囲のミスマッチも同じ「特別対応」として扱われ、標準価格が形骸化していきます。

このログがないと、更新時に前回条件だけが独り歩きし、標準テーブルへ戻せなくなります。

5項目のうち、実際には「理由」と「再確認日」の2つが特に抜け落ちやすいだろうと私は考えています。期間・条件・承認者は、承認フローを回す時点で機械的に埋まりやすい欄です。一方、理由は「なぜ標準外にしたか」を言葉にする一手間が必要で、急ぎの案件ほど省略されがちです。再確認日は、承認した瞬間には誰も困らないため、次に見直す予定が入らないまま放置されやすくなります。この2つが抜けたログは、更新のたびに「前回もこの条件だったはず」という記憶だけで運用されることになり、値引き依存からの脱却方法で書いた基準価格化と同じ機構で、例外が既得権に変わっていくはずです。

導入後に見たい運用シグナル

数量帯を出した後は、単に受注できたかではなく、境目が機能しているかを見ます。

シグナル1: 境目の直前で注文が止まる

境目の手前で数量が不自然にそろうなら、単価の切り替え方が強すぎる可能性があります。

シグナル2: 特別単価の申請が同じ帯に集中する

同じ数量帯で例外承認が続くなら、標準テーブルの刻み方か提供範囲がずれている可能性があります。

シグナル3: 請求差し戻しが増える

単価よりも、明細名、数量単位、適用開始日のずれが原因になりやすい領域です。価格表と請求項目の名前がそろっているかを見直します。

既存取引先に新しいテーブルを入れるとき

新しい数量帯を出すときにいちばん崩れやすいのは、実は新規の商談ではなく既存取引先への適用です。更新タイミング、契約変更、例外承認の棚卸しを同時に進めようとすると、どの変更がどの理由によるものか説明できなくなります。私は、この3つは分けて進めたほうがよいと考えています。まず既存の例外条件をログとして棚卸しし、次に契約更新のタイミングに合わせて新テーブルへの移行を提案し、契約条件そのものの変更（期間や解約条項など）は必要な場合だけ別途扱う、という順序です。過去の特別条件が整理されないまま新テーブルを重ねると、例外がさらに例外を生み、シグナル2で見た「特別単価の申請が同じ帯に集中する」状態を自ら作り出すことになります。

結び: テーブルが崩れる順番で点検する

ここまでの話を、単位・境目・採算ライン・例外承認という登場順ではなく、実際にテーブルが崩れていく順番で並べ直すと、次のようになります。

まず、単位が曖昧だと、見積ごとに数量の数え方がぶれ、そもそも境目を置く土台がなくなります。次に、単位が決まっていても境目が受注の塊からずれていると、単価の境目と運用の境目が食い違い、どちらかが放置されます。境目が正しく置けていても、採算ラインを下限として明示していなければ、大口見積のたびに「今回は特別」が積み重なり、標準テーブルは静かに空洞化します。そして採算ラインまで守れていても、例外承認のログ、特に理由と再確認日を残していなければ、前回の例外が既得権として独り歩きし、次の更新でテーブルへ戻せなくなります。

つまり崩れは、単位→境目→採算ライン→例外承認という順に、下流に行くほど発見しづらくなるはずです。単位のずれは次の見積で誰でも気づきますが、例外承認ログの欠落は、更新のときに初めて、しかも「前回もこうだった」という既成事実として発覚します。だとすれば、テーブルを点検する優先順位は、この順番を逆から辿るのが理にかなっていると私は考えています。まず例外承認ログが残っているかを確認し、次に採算ラインが下限として言語化されているかを見て、境目と単位はその後で点検するという順序です。

私自身、次にこのテーブルを見直すときは、割引率の刻みを直す前に、まず例外承認ログの「理由」欄が埋まっているかどうかから確認しようと思っています。