公開: 2026年5月15日 / 最終更新: 2026年5月15日 / 著者: 営業実務ラボ編集部
アップセル提案を「お願い営業」にしないための準備
アップセル提案を営業都合にせず、利用成果、未解決課題、追加部門、CSとAEの役割分担から設計します。

先に結論
アップセル提案は、営業都合のお願いではなく顧客成果から逆算して設計します。利用状況、未解決課題、追加部門の必要性、CSとAEの役割分担、追加導入後の運用まで確認してから提案します。
- ・顧客成果を起点に提案する。
- ・未解決課題と追加部門を確認する。
- ・CSとAEの分担を事前に決める。
この記事で整理すること
既存顧客へのアップセル提案が、契約更新前や営業都合のタイミングで行われると、顧客からは追加で買ってほしいだけに見えてしまいます。利用状況、成果、未解決課題、追加部門の必要性が整理されていないと、提案は押し売りに近づきます。この記事では、アップセルを顧客成果の拡張として設計する方法を整理します。
背景
アップセルは、新規営業より顧客理解がある分、簡単に見えることがあります。しかし、顧客は既に費用を払っており、追加投資には明確な理由が必要です。現在の利用で何が改善され、まだ何が残っているのか。追加機能や上位プランによって、どの部門のどの業務が変わるのか。ここが曖昧だと、提案は営業都合に見えます。
よくある失敗
- 契約更新や売上目標を理由にアップセルを提案している。
- 顧客の利用成果を確認する前に上位プランを説明している。
- CSとAEで提案タイミングと役割分担が決まっていない。
- 追加提案後の導入支援や活用計画がない。
実務での見直し方
提案前に見るべきなのは、利用状況、達成した成果、残っている課題、追加利用の対象部門、導入後の運用体制です。CSは利用実態と顧客の成功条件を把握し、AEは提案設計と商談進行を担います。提案の起点は更新日ではなく、顧客側に追加投資の理由が生まれたタイミングです。
見落としやすいのは、顧客がまだ現在の契約価値を実感していない段階で追加提案を始めることです。利用が浅い状態で上位プランを勧めると、顧客は追加価値ではなく追加負担として受け止めます。まず現在の成果を顧客の言葉で確認する必要があります。
現場で起きるサイン
このテーマで問題が起きている組織では、会議やSFA上に小さなサインが出ます。たとえば、契約更新や売上目標を理由にアップセルを提案している状態が続くと、担当者は前に進んでいる感覚を持っていても、顧客側の判断は進んでいないことがあります。顧客の利用成果を確認する前に上位プランを説明している場合も、案件の見た目は整っていても、次の関係者や次の判断に進む材料が不足します。
アップセルで失敗しやすいのは、更新月や営業目標を理由に上位プランを案内する場面です。顧客から見ると、現在の契約でどんな成果が出たのか、追加投資でどの未解決課題が解消するのかが見えなければ、提案は値上げや押し売りに見えます。
もう一つのサインは、会話が担当者個人の感覚に寄りすぎることです。温度感が高い、反応が良い、前向きそう、といった表現だけでは、営業組織として支援できません。実務で扱うには、誰が、何を、いつまでに、何のために判断するのかを記録する必要があります。記録できない情報は、商談中に確認できていない可能性があります。
チームで分担すること
この見直しは、営業担当者だけに任せると続きません。担当者は顧客との会話から事実を集め、マネージャーは案件レビューで不足している論点を確認します。営業企画やRevOpsは、SFA項目、会議アジェンダ、確認テンプレートを整えます。CSやプリセールスが関わるテーマでは、導入後や技術確認で必要になる情報を受注前の確認項目へ戻します。
分担を決めるときは、誰が入力するかだけでなく、誰がレビューするかまで決めます。入力欄を増やしても、レビューされなければ形だけになります。逆に、レビュー観点が明確であれば、営業担当者は何を確認すべきかを商談前から意識できます。運用の目的は管理を細かくすることではなく、顧客の判断を前に進めるための情報を欠かさないことです。
明日から使えるチェックリスト
- 現在の利用状況と成果を顧客と確認している。
- 未解決課題が追加提案とつながっている。
- 追加部門、利用者、運用責任者が分かっている。
- CSとAEの提案前後の役割が決まっている。
- 追加導入後の活用計画まで用意している。
このチェックリストは、すべてを一度に完璧に埋めるためのものではありません。最初は、次の商談や次の会議で確認する項目を二つだけ選びます。たとえば、現在の利用状況と成果を顧客と確認しているかどうかを確認し、次に未解決課題が追加提案とつながっているかどうかを見ます。未確認の項目があれば、次回商談の質問、フォローメール、社内レビューのいずれかに戻します。
重要なのは、空欄を責めるのではなく、空欄を次の確認事項として扱うことです。商談は常に情報が揃った状態で進むわけではありません。だからこそ、何が分かっていて、何がまだ分かっていないのかを分ける必要があります。この分離ができると、案件レビューは報告ではなく支援の場になります。
運用に落とす方法
CS定例の中で、アップセル候補を営業目標ではなく顧客成果から整理します。利用が進んでいる顧客、追加部門から相談が出ている顧客、手作業が残っている顧客を候補にします。AEが入る前に、CSが顧客と現状成果を確認し、提案理由を顧客の言葉で整理します。そのうえでAEが、社内説明に使える資料と次の進め方を設計します。
アップセル候補会議では、金額ポテンシャルより先に利用成果を確認します。CSが確認した成果、未解決課題、追加部門の具体性がそろった案件だけをAEの提案設計へ進めると、営業都合の提案を減らせます。
運用に落とすときは、既存の会議とSFAに接続します。新しいチェックシートを作っても、普段の案件レビューや1on1で見なければ定着しません。週次会議では、対象案件をすべて確認するのではなく、停滞している案件、次の判断者が不明な案件、未確認事項が多い案件に絞ります。限られた会議時間を、読み上げではなく次の打ち手に使います。
SFAでは、自由記述だけに頼らない方がよいです。自由記述は文脈を残すには便利ですが、集計や比較には向きません。最低限、確認済み、未確認、次回確認、対象外のように状態を分けられる項目を用意します。細かい項目を増やしすぎると入力されなくなるため、最初は営業が本当に判断に使う項目だけに絞ります。
見るべき指標またはレビュー観点
見るべき指標は、アップセル提案数だけではありません。利用成果確認済みの提案率、CS同席率、追加導入後の利用開始率、追加部門の定着率、提案後の顧客反応を見ます。アップセルは売った後に利用が広がって初めて成功です。
指標を見るときは、単月の結果だけで判断しません。営業活動には案件のタイミング、顧客側の稟議時期、担当者の経験差が影響します。まずは30日単位で、入力品質、次回アクション、停滞理由、関係者確認、失注理由の具体性が改善しているかを見ます。数字が悪い場合も、すぐに担当者の能力問題にせず、プロセス、資料、会議、マネージャー支援のどこに詰まりがあるかを分けます。
最後に、改善した内容を標準化します。うまくいった質問、顧客が社内共有しやすかった資料、案件レビューで有効だった確認項目は、個人の工夫で終わらせず、テンプレートや会議アジェンダに戻します。営業組織の実務改善は、一度の施策ではなく、現場で見つけた良い型を繰り返し更新することで定着します。
公開前に確認すること
この記事のテーマを自社で扱うときは、最後に三つの観点で確認します。第一に、現場が明日から使える粒度になっているか。第二に、マネージャーやRevOpsがレビューできる記録として残るか。第三に、顧客の判断を助ける内容になっているかです。社内向けの管理項目だけを増やしても、顧客の検討が進まなければ営業実務としては不十分です。
最初にチームで確認する問いは、「顧客は今の契約で何が良くなったと言っているか」です。この答えがないまま追加提案を作ると、提案理由が営業都合になりやすくなります。
また、記事の内容をそのまま全案件へ一律に適用しないことも重要です。新規商談、既存顧客、エンタープライズ、パートナー経由では、確認すべき相手やタイミングが変わります。まずは対象案件を絞り、運用してみて、会議で振り返る。そこで得た学びをチェックリストやSFA項目へ戻す。この小さな改善サイクルを前提にすると、営業組織に無理なく定着します。
編集・監修について
この記事は営業実務ラボ編集部が企画、執筆、編集しています。制作過程で生成AIを構成案作成、草案整理、表現確認に利用する場合がありますが、公開前に編集部が事実関係、出典、表現を確認しています。外部専門家による個別監修が入る場合は、記事内で監修者名または監修有無を明記します。
Related
次に読む記事

2026年5月15日
CSから見た「売り方が悪い案件」の共通点
受注後に失速しやすい案件を、営業段階の期待値、利用部門、成功条件、AEからCSへの引き継ぎから見直します。
解決すること: 導入後に失速しやすい案件を営業段階の期待値と引き継ぎから見直せる。
対象: AE / CS / 営業責任者 ほか

2026年5月11日
導入後に失速するSaaS案件の共通パターン
受注後に利用が進まないSaaS案件を、期待値、引き継ぎ、現場利用者、成功条件の観点で見直します。
解決すること: 導入後に失速するSaaS案件の期待値、引き継ぎ、成功条件を点検できる。
対象: AE / CS / 営業責任者