SFA 上のフェーズは「提案済み」。けれど、この 3 か月、案件はまったく動いていない。使用部門の窓口担当者とは毎週やり取りしていて、反応も決して悪くない。それでも購買部門はいっこうに動き出さない。
こうした状態の原因は、フォローの回数ではありません。商談管理が独立した仕事として扱われていないことです。
商談管理とは、顧客側が実際に満たさなければならない条件を一つずつクリアさせていく仕事であり、SFA のレコードを次のフェーズへ移す作業ではありません。 複数部門が関わる法人営業では、その条件があちこちに分散しています。使用部門は新しい業務フローを受け入れられるか。情報システム部門は連携とセキュリティを確認できるか。技術部門は保守と既存設備との整合を判断できるか。購買部門は手続きを進められるか。そして予算決裁者は、その金額を今期の枠に入れられるか。
どれも独立した未充足の条件で、それぞれに担当者がいて、それぞれに根拠があります。だから商談管理の中身は、次の 4 つを最新の状態に保つことに尽きます。
- 実際に何が起きたか——顧客接点の記録；
- 誰が関わっていて、それぞれ何を気にしているか；
- どの条件がまだ満たされていないか——意思決定ノード；
- いま進捗を止めているのはどれか——ボトルネック。
この作業の成果物はステータス報告ではありません。「次に誰と、何について話すか」という判断です。
以下、商談管理とパイプライン管理の違い、商談コンテキストを構成する 5 要素、病院案件の具体例、実行できる 5 つのステップ、そして週 10 分の振り返り方法の順に説明します。
商談管理はパイプライン管理ではありません
この 2 つは混同されがちで、多くの問題はそこから始まります。パイプライン管理は「手元の全案件」を対象とし、着地見込みを読み、時間配分を決めるための仕事です。商談管理は「一つの案件」の内側を見て、いま何が事実で、次に何をするかを決める仕事です。
| パイプライン管理 | 商談管理 | |
|---|---|---|
| 対象の単位 | 抱えている案件全体 | 1 つの商談 |
| 中心の問い | 今期いくら、いつ入るか | 何が未解決で、何が動かすのか |
| 主な成果物 | フェーズ、金額、着地予定、確度 | 顧客接点の記録、関係者、意思決定ノード、ボトルネック |
| 主な受益者 | 予測とマネジメント | その案件を実際に動かしている営業担当 |
| 典型的な失敗 | 精緻に見える予測が、検証されていない前提の上に乗っている | 情報は細かく残っているのに、行動に変換されない |
どちらも必要です。ただ、パイプライン管理しかしていない営業担当が管理しているのは、実質的には自分の仮定の集計です。商談レベルで見落としたものは、そのまま予測に引き継がれます。
なお、リード獲得は有効な商談が立ち上がった時点で役目を終えます。本稿が扱うのはすべてその後の話です。
フェーズはラベル、進捗には根拠が要ります
フェーズは自社が案件に貼ったラベルです。実際の進捗は顧客の組織が何をクリアしたかです。この 2 つは進む速度が違い、数か月にわたって食い違うこともあります。
「提案済み」のまま止まっている案件が、実際には——使用部門は完全に受け入れ済み、セキュリティ確認は未了、購買は起案すらされていない、予算の決裁者が誰かも判明していない——という状態であることは珍しくありません。ラベルは終盤に見えますが、5 つの条件のうち 3 つが未解決で、うち 1 つは着手すらされていません。
フェーズはラベル、進捗には根拠が要ります。
だから商談上で最も見るべきなのはフェーズではなく、「まだ解決していない条件の一覧」と、その一つひとつの根拠です。既存のフェーズ運用を残したまま実進捗を見る方法は〈商談フェーズと実際の購買進捗のズレ〉で扱っています。
商談コンテキストを構成する 5 要素
多くのシステムに蓄積されているのは「活動」であって「コンテキスト」ではありません。活動は自分が何をしたかを示し、コンテキストはそれが顧客の意思決定にとって何を意味するかを示します。
これは VINEQRA の設計思想ですが、ツールを使わなくてもモデルとして成立します。
顧客接点の記録 ＋ 関係者 ＋ マイルストーン／意思決定ノード ＋ ボトルネック → ネクストアクション（Next Best Action）
| 要素 | 答える問い | 根拠になるもの | よくある失敗 |
|---|---|---|---|
| 顧客接点の記録 | これまでに実際、何が起きたか | 打ち合わせ、電話、デモ、出た懸念、依頼された資料、交わした約束、まだ答えていない質問 | 「打ち合わせを実施」とだけ残し、何を求められ、何を約束したかが残っていない |
| 関係者 | 誰が、どの立場で、何を気にしているか | 役割、所属部門、明言された懸念、影響力、現時点の姿勢 | 名刺交換した全員をキーパーソン扱いし、かつ全員を入れ替え可能な存在として扱う |
| マイルストーン／意思決定ノード | 案件が前に進むために、顧客側が先に通すべき条件は何か | セキュリティ確認、技術検証、稟議、予算承認、購買手続き、試用の受け入れ | 自社が管理できるフェーズを定義してしまい、顧客が通すべき条件を定義していない |
| ボトルネック | いま実際に進捗を止めているのはどれか | 担当者が特定でき、まだ満たされていない具体的な条件 | 沈黙をボトルネックと見なし、本物の依存関係を「先方が多忙なだけ」と片づける |
| ネクストアクション | 以上を踏まえ、次に何をするのが最も有効か | 最も重要な未解決条件を一歩進める行動 | 既定値として「もう一度フォロー」になり、具体的な条件には何も触れていない |
矢印が重要です。前の 4 つは根拠であり、5 つ目はそこから導かれる判断です。根拠なしに判断すれば、それは単なる活動になります。根拠を集めながら判断に収束させなければ、記録だけは充実した動かない案件が残ります。
[Suggested Original Graphic 1] — 仕様は E 節参照。
具体例：受注間近に見える病院案件
以下は説明のための想定シナリオであり、VINEQRA の顧客事例ではありません。
地域中核病院の設備導入案件。金額は小さくなく、7 か月が経過し、SFA 上のフェーズは「提案済み」。
| 関連部門 | 意思決定上の役割 | 主な関心事 | 現状 | 未解決の条件 |
|---|---|---|---|---|
| 診療科（使用部門） | 要望の発信元・実際の利用者 | 業務フローへの適合、教育負荷 | 支持。実機評価も完了 | なし。ここは通過済み |
| 臨床工学部門 | 技術評価 | 設置、保守、既存機器との整合 | おおむね前向き。保守条件に未確認が 1 点 | 保守対応時間の書面確認 |
| 医療情報部門 | 技術承認 | システム連携、データの取り扱い | 6 週間前にセキュリティ確認票を送付。以降、音沙汰なし | 確認完了が購買起案の前提 |
| 購買・用度部門 | 手続き所管 | 調達手続き、契約条件 | 未着手 | 医療情報部門の承認待ち |
| 事務局／経営層 | 予算決裁 | 今年度予算の優先順位 | 名前は分かるが、面談したことがない | 今年度枠に含まれるかの確認 |
パイプラインのレコードとして見れば、この案件は「提案済み」で今期着地見込みです。商談として見れば、止まっている場所は 1 か所しかありません。セキュリティ確認です。その後の購買、契約、予算執行はすべてそれ待ちで、営業担当はこの 6 週間、すでに通過済みで、かつ止まっている当の件に権限を持たない診療科の窓口にフォローを重ねていたことになります。
社内推進者が悪いわけではありません。フォローそのものも間違いではありません。ただ、5 つの部門のうち唯一クリア済みの相手に当たっていただけです。
商談コンテキストの実用的な価値はここにあります。いま抱えている 5 本の関係のうち、どれが荷重を支えているのかを教えてくれる、ということです。
大型案件を前に進めるための 5 ステップ
1. 接点を「活動」ではなく「根拠」として残す
活動記録は「自分が動いたか」に答えます。根拠の記録は「何が分かったか、何が変わったか」に答えます。後のすべての判断が依存するのは後者です。「電話 ─ ○○病院」とだけ書かれたカレンダー予定から、ボトルネックを特定することはできません。
残すべきなのは意思決定に重みを持つ内容です。相手が何を求めたか、何に反対したか、何を約束したか、誰の承認が要ると言ったか、そしてどの問いが未回答のままか。具体的な方法は〈法人営業における顧客接点の記録のしかた〉で扱っています。
2. 整理するのは連絡先一覧ではなく決裁ライン
連絡先は「連絡手段を持っている人」です。関係者は「その人の姿勢が案件の進退に影響する人」です。そして決裁ラインとは、特定の条件を通す責任を負う一連の部門であり、そこには一度も会っていない人が含まれていることがあります。
部門ごとに、役割・関心事・現時点の姿勢・こちらに求めているものを記録します。この表の空欄こそ、最も信頼できる早期警告です。方法論は〈法人営業のキーパーソン把握：誰が案件を左右するのか〉と〈大型案件における決裁ラインの追い方〉にあります。
3. 顧客側が通すべき意思決定ノードを定義する
購入が成立する前に満たされる必要のある条件を、顧客の言葉で書き出します。セキュリティ確認、技術検証、稟議、予算承認、契約条件。
良いノードかどうかの判定基準は単純で、顧客側の担当者が見て「うちの話だ」と分かるかどうかです。「修正見積を送る」はこちらのタスクです。「今年度予算に含まれることを経営層が確認する」が顧客側の条件です。案件が進めるかどうかを教えてくれるのは後者だけです。
4. 「返信がない」と「本当のボトルネック」を切り分ける
ボトルネックとは、商談の進行を妨げる、あるいは進行の可能性を著しく下げる、未充足の条件を指します。
沈黙が自動的にボトルネックになるわけではなく、ボトルネックが必ず沈黙として現れるわけでもありません。次の状況は、それぞれ対応がまったく異なります。
| 兆候 | 実際の正体 | 妥当な対応 |
|---|---|---|
| 2 週間返信がない | 停滞——多くは優先順位の問題で、姿勢の問題ではない | 接触を取り直し、何が変わったかを確かめる |
| 「まだ検討中でして」 | 不確実——言語化されていない懸念がある | その具体的な未解決の論点を引き出す |
| 「連携のところが不安で」 | 反対意見——明言された懸念 | 正面から、技術側の担当者を交えて対応する |
| 「情報システムの承認が出ないと購買が動けない」 | 依存関係——抵抗ではなく順序の問題 | 上流の条件そのものに取り組む |
| 予算の決裁者が誰か、誰も話題にしていない | 関係者の抜け——把握の欠落 | 社内推進者に決裁経路を確認してもらう |
| セキュリティ確認票を提出後、結果が来ない | 承認の未了——これは生きたボトルネック | 確認の所管と想定スケジュールを突き止める |
いま自分が直面しているのがどれなのかを見分ける方法は〈法人営業の案件が止まる理由と、本当のボトルネックの見つけ方〉で扱っています。
5. 次の一手は、リマインダーではなくコンテキストから決める
取るべき次の一手は、「最も重要な未解決条件」を一歩進められるものです。先ほどの病院案件でいえば、診療科の窓口ともう一度話すことではなく、セキュリティ確認の所管が誰で、完了に何が足りていないのかを突き止めることです。
使える順序はこうです。前回から何が変わったか → いま重要なのは誰か → どの条件が未解決か → それを止めているのは何か → その依存や不確実性を最も減らせる行動はどれか。判断手順の全体は〈商談の次の一手をどう判断するか〉に、それを運用リズムに落とす方法は〈法人営業のフォロー体制のつくり方〉にあります。
週 10 分でできる商談レビュー
重要案件ごとに、7 つの問いを通します。
- 今週入ってきた新しい根拠は何か。それによって見立ては変わったか。
- どの部門がすでにクリアしたか。その根拠は何か。
- いまクリティカルパスに最も近い未解決の条件はどれか。
- それは反対意見か、依存関係か、関係者の抜けか、承認の未了か。
- 技術・商務・予算・経営——決裁経路のうち、担当者名が埋まっていないものはないか。
- 約束したまま、まだ渡せていないものは何か。
- 以上を踏まえ、次に最も価値のある一手は何で、相手は誰か。
3 番の答えが 4 週続けて同じで、7 番が毎回「フォローする」になっているなら、その案件は進みが遅いのではありません。止まっていて、しかも止まっている場所は特定できています。
ソフトウェアが担えること、担えないこと
多くの CRM は記録システムとして設計されています。何が起きたか、相手は誰か、案件がどのフェーズにあるか。これは確かに有用ですし、主たる利用者が個人ではなく組織であるシステムとしては妥当な設計です。
一方で、記録システムがそれ自体では行わないのが、記録をまたいだ推論です。顧客接点の記録も、関係者の一覧も、未解決の条件も、答えていない問いも、すべて同じシステムの中にあります。しかし、それらを結びつける作業は人手のままです。5 つの部門が関わり 7 か月の経緯を持つ案件では、その作業こそ、週が忙しくなった瞬間に省かれます。
VINEQRA は、営業担当個人のワークフローに推論レイヤーを加えるものとして設計されています。
- 記録する——後から使える粒度で顧客接点を残す；
- つなぐ——記録を、関わる人・部門・意思決定ノードに結びつける；
- 推論する——蓄積されたコンテキストを分析し、進捗の兆し、抜け、ボトルネックの候補を浮かび上がらせる；
- 動く——「次に何を検討すべきか」について提案を示す。
実際の案件で必要になる 2 つのモードに対応しています。営業担当が起きたことを記録しているだけの場合、AI はその経緯そのものを対象に推論できます。マイルストーンや意思決定ノード、関係者の構造を明示的に定義している場合は、その構造に対して推論し、どのノードが動き、どれが未解決のままかの判断を支援できます。
このうちサポートされている AI 分析は、Apple Foundation Models を通じて Apple のオンデバイスのシステム言語モデルで実行されます。そのため、当該の推論を第三者のクラウド LLM に送る必要がありません。病院の担当者名、社内の反対意見、価格の議論が書かれた営業コンテキストを扱う以上、この構成は前提として流すのではなく理解しておく価値があります。詳細は〈オンデバイス AI で機微な営業データをどう扱うか〉にあります。
どの機能よりも重要な原則が一つあります。VINEQRA は提案し、決めるのは営業担当です。 提案は判断のきっかけであって、判断の代替ではありません。「医療情報部門の確認が止まったまま、購買が 6 週間動いていない」とツールが示すことはできます。エスカレーションするのか、待つのか、別ルートを取るのかを決められるのは担当者だけです。
[Product Screenshot：複数部門の商談ビュー] — 配置は E 節参照。
役割分担をさらに詳しく比較したい場合は〈CRM と商談インテリジェンス：法人営業に本当に必要なもの〉をご覧ください。
案件を静かに失う 5 つのパターン
- 止まっている関係ではなく、連絡しやすい関係を維持してしまう。 社内推進者に連絡するのは楽ですが、セキュリティ確認の所管を探すのは楽ではありません。
- 「打ち合わせを実施」と残し、「そこで何が分かったか」を残さない。 半年後に価値があるのは後者だけです。
- 一人の担当者を顧客そのものと見なす。 単線で進めた案件は、その人が異動・方針変更・心変わりをした瞬間に崩れます。
- 自社のプロセスを顧客の条件と取り違える。 修正提案書を送るのは行動です。経営層が予算を確認して初めて進捗です。
- 根拠の代わりにフェーズを使う。 前回のフェーズ変更が何を根拠にしていたか言えないなら、そのフェーズはただの見解です。
よくある質問
商談管理とは、具体的に何を管理するのですか。 単一の案件について、実際に何が起きたか、誰が関わっているか、顧客側にどの条件が残っているか、いま何が進捗を止めているかを追跡し、それらを踏まえて次の一手を決めることです。
パイプライン管理との違いは何ですか。 パイプライン管理は複数案件を横断して見込みと優先順位を扱います。商談管理は一つの案件の内側で、事実の確認と行動の決定を扱います。予測の精度は、その下にある商談管理の質を超えません。
大型案件では関係者は何人くらいを想定すべきですか。 業界と案件規模で大きく変わるため、固定の人数を前提にするのは危険です。より有用な問いは、利用部門の受け入れ・技術承認・商務条件・予算承認・経営の後押しという各経路に、具体的な担当者名が入っているかどうかです。名前が入っていない経路が、終盤に想定外として現れます。
「進みが遅い」と「止まっている」はどう見分けますか。 同じ条件が何度のレビューをまたいでも未解決で、しかも打った手のどれもそこに直接触れていないなら、止まっています。遅いだけの案件は新しい根拠を生み続けますが、止まった案件はフォロー記録しか生みません。
AI は次に何をすべきか教えてくれるのですか。 記録されたコンテキストを分析し、提案を示すことはできます。誰に当たるべきか、どの条件が未解決に見えるか、何が進捗を止めていそうか、といった内容です。ただし、その場の空気まで知ることはできませんし、案件に対する確定的な判定として扱うべきものでもありません。提案はあくまで判断の材料です。
会社ですでに CRM を使っている場合、別のツールは必要ですか。 必ずしも必要ではありません。答えている問いが違うためです。CRM は組織のために顧客の記録を残します。推論レイヤーは、蓄積されたコンテキストが次の一手にとって何を意味するかを、営業担当個人が判断するのを助けます。実際には両方を併用している例も少なくありません。
案件の本当の進捗を把握し、次の一手を決める。
VINEQRA は、顧客接点の記録・関係者・意思決定ノードを、推論に使える商談ビューとして整理します。サポートされている AI 分析はオンデバイスで実行されます。