アドオン価格を設計するときの判断軸

アドオンは、基本プランだけでは拾い切れない用途を追加販売で受け止める考え方です。必要な利用先だけが選べるため、入口を重くしすぎずに価値の幅を広げやすくなります。

ただし、何でもアドオンへ逃がすと、最初のプランが空洞化し、商談説明や請求運用が複雑になります。本記事では、各社の公開価格や一時的な流れではなく、何を基本プラン、上位プラン、アドオンへ分けるかという設計判断に絞って整理します。

---

この記事でわかること

1. アドオンの役割: どんな用途を追加販売へ切り出すと機能しやすいか
2. 境界の置き方: 基本プランと上位プランのどこに線を引くか
3. 価格帯の考え方: 価格単位、採算下限、無償範囲をどう決めるか
4. 運用の整え方: 表示、見積、請求、導入後ログをどうそろえるか

基本情報

---

アドオンとは何か

アドオンとは、基本プランの外側に置き、必要な利用先だけが追加購入できる要素です。機能、容量、権限、導入支援、外部連携、個別処理など、主契約の外側で切り出せるものが候補になります。

重要なのは、アドオンが「足りない基本プランの穴埋め」なのか、「一部の利用先にだけ必要な追加価値」なのかを見分けることです。前者なら基本プラン側の設計を見直したほうがよく、後者なら追加販売として置く意味があります。

まず見たい3つの置き場

アドオンが向きやすい場面

• 役割や業務フローによって必要な機能が分かれる
• 一部の利用先だけ保存量、処理量、連携範囲が大きい
• 基本プランは軽く保ちたいが、追加用途の受け皿は必要
• 追加購入の意味を一文で説明できる

---

まず決めたい境界

アドオン設計で最初に詰めるべきなのは価格表ではなく、どこまでが基本で、どこからが追加なのかという線引きです。ここが曖昧だと、営業現場では値引きの代わりに無償付与が増え、導入後は請求差し戻しや問い合わせが積み上がります。

1. 基本プランだけで開始できるか

基本プランは、それだけで使い始められる状態であるほうが安全です。導入初日から高い確率で必要になる要素まで外へ出すと、基本プランは名目だけ残り、実質的にはアドオン込みが標準になります。

次のような要素は、追加販売より基本プラン側に置いたほうが自然です。

• 初期設定の完了に必要
• 日常利用で毎回触れる
• 導入判断の主目的そのもの
• 外すと説明が難しくなる

2. 追加価値を独立して語れるか

アドオンは、単に「便利」では弱く、何のために足すのかが独立して語れる必要があります。たとえば次のように、用途が一言で通る状態が理想です。

• 監査や承認の流れを整えるため
• 外部システムとつなぐため
• 上限を引き上げるため
• 個別支援を受けるため

この説明が長くなるなら、機能のまとまり方が不自然な可能性があります。

3. cost to serve を切り分けられるか

アドオンが機能しやすいのは、追加販売した分だけ手間や原価の境界を引けるときです。点検したいのは次の項目です。

• 追加作業が発生するか
• 手動設定が増えるか
• 問い合わせ窓口の負荷が増えるか
• インフラや外部連携の費用が跳ねやすいか

境界が引けないまま売ると、料金表はきれいでも裏側の作業だけが増えます。

4. 付与と停止を要素単位で扱えるか

アドオンは、売る瞬間よりも付与、停止、請求反映の運用で差が出ます。要素単位で切り替えられないと、契約変更や請求調整が人手に寄りやすくなります。

確認したいのは次の点です。

• 申込後に自動で有効化できるか
• 解約や停止の起点が明確か
• 請求項目として独立して出せるか
• 権限や上限も一緒に切り替わるか

5. 営業例外を増やさないか

アドオンは、本来は標準の追加販売です。ところが、案件ごとに無償付与、抱き合わせ、手作業の条件出しが増えると、価格設計ではなく個別交渉の道具になります。

「どの条件なら付けるのか」「誰が承認するのか」「何を残すのか」を先に決めておくと、現場運用がぶれにくくなります。

---

アドオン価格を置くときの進め方

1. 追加販売へ回す仕事をひとつに絞る

最初に決めたいのは、何を売るかではなく、どんな仕事を追加販売で受け止めるかです。アドオンの中に複数の役割を詰め込むと、価格の意味が曖昧になります。

例として、次のように役割を一つへ寄せると説明しやすくなります。

2. 価格単位を先に決める

価格は金額から考えるより、何を単位に請求するのかから決めたほうがぶれにくくなります。主な単位は次のとおりです。

単位が決まると、価格表、見積、請求の文言もそろえやすくなります。

3. 採算下限を確認する

アドオンの金額は、相場から逆算するより、まず採算下限を押さえたほうが安全です。下限を見るときは、次の4点を並べます。

• 追加作業の手間
• 外部費用や変動費
• 導入後に増える問い合わせ
• 請求変更や運用差し戻しの事務負荷

ここで赤字になりやすいなら、価格だけでなく無償範囲、付与条件、販売対象も見直す必要があります。

4. 基本プランと上位プランの関係をそろえる

アドオン単体で見るのではなく、前後の置き場とのつながりも整理します。目安になるのは次の役割分担です。

もし多くの案件で同じアドオンが必ず一緒に付くなら、単独販売より上位プランやバンドルのほうが自然です。

5. 導入後ログまで含めて設計する

アドオンは、公開後の数字とログを見ないと善し悪しがわかりません。追いたいのは次のような変化です。

• 追加購入率
• 無償付与の件数
• 何が入るのかに関する問い合わせ
• 契約変更や請求差し戻し
• 解除理由や縮小理由

追加購入率だけを見ていると、売れているように見えても、裏側の作業が増えていることに気づきにくくなります。

---

失敗しやすい形

1. 基本プランを軽くしすぎる

最初のプランでできることが少なすぎると、商談のたびに「結局どれを付ければ使えるのか」という説明が必要になります。入口を安く見せるための抜き出しは、長く見ると逆効果です。

2. ほとんどの案件で同じアドオンが付く

追加販売のはずなのに、毎回ほぼ同じものが一緒に売れるなら、アドオンではなく標準構成に近い状態です。独立販売の意味が薄くなっているため、基本プランや上位プラン側の置き方を見直したほうがよい場面です。

3. 上位プランと価値が重なる

上位プランにも同じ価値が入っているのに、低位プランではアドオンとして別売りにすると、説明が複雑になります。どちらが何の受け皿なのかを一言で言えないなら、役割整理が先です。

4. 無償付与が常態化する

営業担当が受注のたびに無料で付けるなら、その価格や置き方は現場に受け入れられていません。例外が多い状態を放置すると、価格表より現場慣行が優先されます。

5. 請求や停止の運用が人手に寄る

契約変更のたびに手作業が増えるなら、アドオンの境界より運用設計に無理があります。特に、付与、停止、請求反映が別々の仕組みになっていると、差し戻しが起きやすくなります。

---

見直しサイン

アドオンは一度作って終わりではありません。次の兆候が出たら置き方を見直します。

---

FAQ

Q1. アドオンと上位プランはどう使い分ければよいですか？

一部の用途だけ足したいときはアドオン、複数の追加要素や管理要件をまとめて受け止めたいときは上位プランが向きます。毎回同じ追加要素が一緒に売れるなら、上位プラン側へ寄せる余地があります。

Q2. 基本プランを安く見せるために機能を外へ出してもよいですか？

導入初日から高い確率で必要になる要素まで外へ出すと、商談説明が重くなります。まずは基本プランだけで使い始められるかを優先して見ます。

Q3. 価格単位は何を起点に決めるべきですか？

価値の出方と運用負荷の出方がそろう単位を選びます。個人ごとに価値が出るなら人数単位、管理や連携なら組織単位、保存や処理なら件数や容量単位が扱いやすくなります。

Q4. 最初の1本目として試しやすいアドオンは何ですか？

用途が一言で通り、付与と停止を要素単位で扱いやすいものから始めると進めやすくなります。容量拡張、承認機能、外部連携、導入支援のように境界を引きやすい領域が候補です。

Q5. 追加販売にした要素をあとで基本プランへ戻してもよいですか？

問題ありません。多くの案件で必須になった、無償付与が増えた、問い合わせの多くが中身確認になった、といった兆候が出たら戻す判断は自然です。固定の正解として扱わず、ログを見て置き場を調整します。

---

まとめ

アドオン価格は、単価を上げる小技ではなく、用途差をきれいに受け止める設計です。うまく機能するかどうかは、何を基本プランに残し、何を追加販売へ回し、どこまでを上位プランへまとめるかという境界の置き方で決まります。

金額だけ先に決めるよりも、追加価値の独立性、cost to serve、付与と停止の運用、無償付与の増え方を先に見たほうが、長く保ちやすい価格体系になります。

---

本記事はネクサフローの価格体系シリーズの一部です。