この記事の要約
SaaSの値上げを進めるときに、契約更新日、移行案、告知文面、例外承認、発表後フォローをどう組み立てるかを解説します。
SaaSの値上げは、単価表を差し替える作業ではありません。契約更新、請求、営業説明、CS運用を同じ順番で組み直す仕事です。値上げ案そのものよりも、「誰から切り替えるか」「どの移行案を出すか」「発表後にどのログを見るか」を先にそろえるほど、混乱は小さくなります。
本記事では、契約更新を軸にした価格改定のロードマップを、準備、告知、移行、発表後フォローの順で整理します。固定の率や月数ではなく、自社の契約構造と運用負荷に合わせて組み立てる前提で読み進めてください。
| 項目 | 内容 |
|---|---|
| トピック | SaaSの価格改定ロードマップ |
| カテゴリ | 価格戦略 |
| 難易度 | 中級〜上級 |
| 対象読者 | 経営、プロダクト、営業、CSの責任者 |
値上げ実行の5ステップロードマップ値上げは「いくら上げるか」から入ると、あとで契約や運用が追いつかなくなります。先に骨組みを決めておくと、社内の説明と実施順序がぶれにくくなります。
| 論点 | 先に決めること | 後ろに回すと起きやすい詰まり |
|---|---|---|
| 対象アカウント | どの契約群から新価格へ切り替えるか | 同じプラン名なのに請求条件が混ざる |
| 更新タイミング | 更新日、請求締め日、社内承認に要る日数 | 案内日と請求日がずれて説明が難しくなる |
| 移行案 | 旧条件を残すか、段階移行にするか | 例外が増え、標準案より個別交渉が多くなる |
| 社内台本 | 営業、CS、請求で何をどう伝えるか | 窓口ごとに言い回しが変わり、信頼を損ないやすい |
値上げ後に混乱しやすいのは、価格表そのものよりも、例外の置き方と説明のずれです。ロードマップは、単価を決める前にそのずれを減らすためのものだと考えると整理しやすくなります。
最初に決めるのは値上げ幅ではなく、「何を守るための改定か」です。ここが曖昧だと、値上げ後に個別交渉が増えたときに判断がぶれます。
先にそろえたい入力項目
| 入力項目 | 見たい状態 | 先に引いておく線 |
|---|---|---|
| 粗利帯 | 継続利用でも赤字に寄らない | 下限価格、例外承認が要る条件 |
| 利用量のばらつき | 重い利用者だけが得をしすぎない | 上限、従量課金、上位プランへの誘導条件 |
| 高工数アカウント | 個別要望で標準運用が崩れすぎない | 個別見積もりへ切り出す線 |
| 値引き理由 | 値引きが恒常化しない | 代替オファー、期限、承認者 |
| 更新時の要望 | 交渉論点が毎回ゼロから増えない | テンプレ文面、営業トーク、FAQの骨子 |
固定の率を先に置くより、どの条件ならその率を説明できるかを先に決める方が、あとで運用しやすくなります。
SaaSの値上げは、全件一斉よりも契約更新に沿って切り替えた方が実行しやすい場面が多くあります。特に年契約、月契約、個別見積もりが混ざる商材では、更新日を軸にした設計が欠かせません。
| 契約群 | 先に見る項目 | 値上げ案の置き方 |
|---|---|---|
| 新規契約 | 新価格表、初回オンボーディング | まずはここから新価格へ寄せる |
| 通常更新 | 更新日、社内稟議、利用実績 | 事前説明と切替日をセットで置く |
| 個別条件つき契約 | 特別条項、個別SLA、追加工数 | 更新前に再見積もりの流れを固める |
| 休眠復帰アカウント | 復帰理由、利用再開の範囲 | 旧条件を戻すのか、新条件に寄せるかを分ける |
ここで大切なのは、対象群ごとに「いつ話すか」と「何を見せるか」を切り分けることです。全員に同じ説明文を送るより、更新順に沿って順番を付けた方が社内の動きも整いやすくなります。
値上げ時の不満は、価格そのものより「選べる余地がない」と感じたときに強くなりがちです。移行案をいくつか持っておくと、価格改定を押し付けだけで終わらせずに済みます。
| 型 | 向いている場面 | 気をつけたい点 |
|---|---|---|
| 旧条件を期限つきで残す | 長期契約が多い、切替時期をそろえたい | 旧条件の残存期間を曖昧にしない |
| 機能追加とセットで上位へ寄せる | 価格差より価値差を伝えやすい | 何が増えるのかを一目で示す |
| プランを整理して導線を絞る | 類似プランが多く、説明が複雑になりやすい | 既存アカウントの逃げ道を細くしすぎない |
Grandfathering は有力な選択肢ですが、全件に長く残すと旧条件の管理が重くなります。誰にいつまで残すのか、切替時にどの案へ移るのかまで決めておくと、例外運用が増えにくくなります。
価格改定の発表では、文面そのものよりも、窓口ごとの説明がそろっているかが重要です。メール、商談、アプリ内メッセージ、請求画面で言っていることがずれると、それだけで不信感が強まります。
文面に入れておきたい項目
社内でそろえたいもの
同じ情報を長く書くより、どの窓口でも同じ順で伝わることの方が効果的です。発表前に一度ロールプレイを行い、言い回しがそろっているかを見ておくと実行しやすくなります。
値上げは、発表した時点では終わりません。むしろ発表後の数週間で、どこに詰まりが出るかが見えてきます。ここで見るべきなのは、単一の数値よりも、どの論点で止まっているかです。
| 見るログ | 何を読み取りたいか | 次に置く手 |
|---|---|---|
| 解約理由メモ | 価格だけが原因なのか、他の不満もあるか | 文面修正、上位プラン案内、導入支援 |
| ダウングレードの申請 | どの機能や枠が重く見られているか | プラン構成の見直し、利用上限の調整 |
| 問い合わせの主題 | 説明不足なのか、請求処理の詰まりか | FAQ更新、台本更新、請求手順の補足 |
| 例外承認の申請 | 標準案で拾えない契約が多すぎないか | 対象群の切り直し、移行案の追加 |
| 商談メモ | 値上げが失注要因になっているか | 価値訴求の順番、提案資料、導線の見直し |
発表後に見るログを決めずに始めると、声の大きい案件にだけ引っ張られやすくなります。どのログを週次で見るか、誰が更新するかまで先に決めておくと、微修正の質が上がります。
固定の率から始めるより、どの条件なら説明できるかから始める方が安全です。粗利帯、利用量、個別要望、移行案を並べたうえで、契約群ごとに妥当な差を置く方がぶれにくくなります。
一律の日数ではなく、更新日、請求締め日、相手側の承認フローから逆算します。全体告知の前に、個別説明が要る契約群だけ先に話す形でも問題ありません。
長期契約が多いとき、重要アカウントを急に動かしたくないとき、旧条件から新条件へ段階的に寄せたいときに使いやすい案です。期限と切替先を決めずに残すと、運用が重くなりやすくなります。
まずは文面よりログを見ます。どの契約群で止まっているか、どの論点が繰り返し出ているかを整理し、台本、FAQ、移行案の順で手当てすると、局所的な要望に振り回されにくくなります。
定期点検そのものは有効ですが、毎回同じ粒度で全件を動かす必要はありません。更新順、利用量の偏り、例外承認の増え方を見ながら、動かす契約群を絞った方が社内の負荷を抑えやすくなります。
SaaSの値上げは、単価の話だけでなく、契約更新、移行案、告知文面、例外承認、発表後の観察までを一つの流れで設計する仕事です。固定の率や月数を前提にするよりも、どの契約群をどう切り替えるかを先に決めた方が、社内の判断も顧客向けの説明もそろいやすくなります。
最初の一歩としては、次の3点を先に埋めると進めやすくなります。
価格体系シリーズ