ソリューション営業とは、顧客の課題を理解し、その解決につながる商品・サービスや方法を提案する営業手法です。Salesforceも、顧客のニーズや困りごとを中心に解決策を勧める手法として説明しています。Salesforceの解説
実際に提案を考えるときは、「何が欲しいか」に加えて、「何を変えるために必要か」を確かめます。この記事ではIT営業を想定し、要望の整理から解決案の比較までを進める方法を紹介します。以下の判断表と事例は編集上の提案であり、受注や改善効果を保証するものではありません。
商品を起点にする営業との違い
商品起点では、機能や仕様を中心に説明します。ソリューション営業では、顧客が抱える課題から、どの機能や支援が必要かを考えます。この出発点の違いが、Salesforceの説明する両者の主な対比です。商品起点との比較
たとえば「問い合わせ管理ツールが欲しい」という相談に対し、製品一覧を提示する前に、返信の遅れ、担当者の不在、対応履歴の分散など、何を解決したいのかを確認します。これは説明用の架空例です。返信が遅い原因を確認しない段階では、ツールの追加が適切な案かは決められません。
商品知識は、課題に対して何ができるかを判断する材料として使います。機能の説明を省くという意味ではありません。課題とのつながりを確認したうえで、機能・費用・制約を説明する進め方です。
顧客課題から提案を組み立てる5段階
次の表は、商談の情報を整理し、次に進めるかを判断するための案です。各段階で未確認事項が残れば、仮説として記録して追加確認へ戻ります。
| 段階 | 整理する内容 | 次に進むための確認 | 足りない場合の行動 |
|---|---|---|---|
| 1. 要望を業務に戻す | 誰が、どの作業で、何に困るか | 具体的な場面を顧客と共有できたか | 実際の作業手順や記録を確認する |
| 2. 課題の優先順位を決める | 影響を受ける業務、解決したい時期 | 今回取り組む課題を顧客が選べるか | 課題ごとの影響と期限の理由を聞く |
| 3. 到達点を決める | 何がどう変われば改善と判断するか | 確認方法と対象範囲が合っているか | 現状の測り方や評価する人を確認する |
| 4. 解決案を比較する | 運用変更、既存機能、新規導入など | 各案の適用条件と不足が説明できるか | 技術担当や運用担当に確認する |
| 5. 次の判断を合意する | 未決事項、担当者、確認期限 | 誰が何を確認して判断するか明確か | 次回の確認項目を絞って決める |
1. 要望と課題を分けて記録する
「ツールを導入したい」は要望です。「担当者が不在のとき、問い合わせの引き継ぎ先が分からない」は業務上の困りごとです。さらに「履歴の保管場所が分かれていることが原因ではないか」は原因の仮説です。この3つを別々に書きましょう。
顧客が話した内容と営業側の推測を混ぜず、「確認できたこと」「仮説」「追加で確認すること」に分ける方法を勧めます。原因を仮説のまま扱えば、後から情報が増えたときも解決案を見直せます。
2. 影響と優先順位を確かめる
質問の整理にはSPINの考え方を参照できます。開発元のHuthwaiteは、状況、問題、問題の影響、解決の価値を確認する4種類の質問を紹介しています。また、固定した順序で聞くものではないと説明しています。Huthwaiteの質問分類
本記事では、この考え方を参考に「その状態が続くと、どの業務に支障が出るか」「今回は何を先に解決したいか」と確認する方法を提案します。影響を営業側で大きく見せず、顧客が説明できる範囲を記録します。金額や工数が不明なら、無理に数値化する必要はありません。
3. 解決後の状態と評価方法を決める
「業務を効率化する」だけでは、提案を比較する基準が曖昧です。先ほどの架空例なら、「担当者が不在でも、別の担当者が対応履歴を確認して引き継げる状態」のように、対象者と行動を具体化してみましょう。
時間の短縮を評価する場合は、測る作業、測定期間、対象件数を顧客と決めます。現状値がない段階では、削減率を約束せず、まず測定する計画を置きます。目標値と営業側の試算も分けて扱ってください。
4. 解決案を同じ条件で比べる
製品を選ぶ前に、運用の変更や既存機能の活用も比較候補に含めます。比較の例は次のとおりです。実際の適否は顧客の環境と利用条件を確認して判断します。
| 架空の比較案 | 確認する条件 | 判断を保留する条件 |
|---|---|---|
| 引き継ぎルールを整える | 履歴を共有できる場所があり、担当を決められるか | 情報の所在自体が分からない |
| 既存ツールの設定を変える | 必要な共有機能や権限設定が利用できるか | 契約プランや設定の影響が未確認 |
| 新しいツールを導入する | 要件、費用、移行、運用担当が整理できるか | 既存環境との接続や運用体制が未確認 |
「安い」「高機能」だけで決めず、今回の課題を解決できる範囲、導入時の作業、導入後の管理まで並べます。技術的に可能か分からない項目は、営業だけで断定せず確認事項として残します。
5. 次に何を確かめるかまで提案する
提案の最後には、採否の判断に足りない情報を整理します。「顧客の運用担当が現行の引き継ぎ手順を確認する」「自社の技術担当が必要機能の実現条件を調べる」など、担当者と確認内容を具体化し、期限を相談します。
情報がそろったら、課題・解決案・導入条件を資料にまとめます。資料の章立てや提出前の確認は、IT営業の提案書の作り方で説明しています。
提案を進めず、確認に戻るべき場面
次の状態では、商品を決める前に追加確認へ戻ることを勧めます。
- 顧客の要望は聞けたが、解決したい業務上の問題が分からない。
- 現場と判断者で、優先する課題や評価基準が食い違っている。
- 必須条件を満たせるか、技術面や契約面の確認が終わっていない。
- 導入後に使う人や管理する人が決まっていない。
自社が提供できる範囲で課題を解決できないと判断した場合は、その理由を説明し、提案の見送りも選択肢にします。複数の課題を一度に盛り込まず、まず合意できた課題に対象を絞る方法もあります。
IT営業を目指す人が練習できること
身近な業務を一つ選び、「要望」「困っている場面」「原因の仮説」「解決後の状態」「比較する案」「未確認事項」を1枚にまとめてみてください。練習では、詳しい商品説明を作る前に、なぜその案が課題に合うのか、どの条件が変わると別の案を選ぶのかを説明してみましょう。
ソリューション営業の進め方を職務理解につなげたい方は、テクノヴァースの営業職の紹介もご覧ください。