順調に見えていた案件が承認の直前で止まるとき、原因の多くはそれまで存在に気づいていなかった部門です。
推進者が協力的で、利用部門の評価も良く、接触頻度も十分。それでも、稟議の段階で品質保証部門の基準が出てくる、情報セキュリティの審査が未実施だと判明する、購買部門の既存ベンダー要件に引っかかる。こうした事態は、関係が悪かったから起きるのではありません。その部門が一度も会話に登場していなかったから起きます。
予防の方法は、案件の初期から次の5軸で承認のカバレッジを点検することです。
| 承認の軸 | 問い |
|---|---|
| 利用部門の受け入れ | 実際に使う部門は、導入を受け入れているか |
| 技術承認 | 技術要件を判断する部門は特定され、審査は進んでいるか |
| 商務承認 | 価格・契約条件を判断する部門と接点があるか |
| 予算承認 | 費用の裏付けと、その決裁者は特定できているか |
| 経営層の後ろ盾 | この案件を優先事項として支持する立場の人はいるか |
**空白はリスク信号です。**埋まっていない軸の数が、その案件が後から覆る可能性の目安になります。
推進者が1人いる状態が、なぜ危うくなるのか
協力的な推進者がいる案件は、進めやすく感じられます。連絡が取れ、社内調整も引き受けてくれる。この状態自体は資産です。
危うさは、推進者の存在が点検の代わりになってしまうことにあります。
- 推進者が「大丈夫です」と言うので、他部門の確認をしていない
- 推進者が把握していない部門については、こちらも把握できない
- 推進者自身が、社内の承認経路を正確に知らない場合がある
- 推進者が異動・休職すると、案件の文脈ごと消える
とくに3点目は見落とされがちです。推進者は自分の部署の業務には詳しくても、他部門の審査基準や稟議の要件までは知らないことがあります。推進者の善意と、その人が持つ情報の範囲は別のものです。
承認カバレッジ点検 ― 5軸
各軸について、確認の質問と、空白のまま進んだ場合に起きやすいことを整理します。
① 利用部門の受け入れ
**確認：**実際に使う部門は誰か。使ってみた上での評価か、説明を聞いた上での評価か。 **空白のリスク：**導入後の反発。現場が納得していない案件は、決裁が下りても運用段階で問題が出ます。 **注意：**この軸は最も埋まりやすく、埋まっていることで安心しやすい軸です。利用部門の支持は必要条件ですが、他の4軸の代わりにはなりません。
② 技術承認
**確認：**技術要件を判断するのはどの部門か。情報システム、情報セキュリティ、品質保証、設備管理など、業種によって単位が異なります。 **空白のリスク：**承認直前での要件提示。技術部門は推進する立場にないため、賛成者としては現れません。要件を満たさないと判断すればそこで止まります。 **注意：****1部門とは限りません。**システム連携は情報システム、セキュリティ基準は別部門、という分離がよくあります。
③ 商務承認
**確認：**価格と契約条件を判断するのはどこか。購買部門の関与時期はいつか。 **空白のリスク：**条件交渉の段階で、既存ベンダー要件、相見積の必須要件、契約書式の指定といった制約が判明します。これらは技術的な合意が終わった後に出てくると、やり直しの範囲が大きくなります。
④ 予算承認
**確認：**費用はどの予算枠から出るか。その枠を管理しているのは誰か。今期か次期か。 空白のリスク：すべての条件が整った後に「今期は予算がない」という結論に至ります。この軸は確認が遅れやすく、かつ遅れたときの損失が最も大きい軸です。 **注意：**予算の存在と、決裁者の特定は別の確認です。予算枠があっても、誰が判子を押すのかが不明なままの案件があります。
⑤ 経営層の後ろ盾
**確認：**この案件を組織の優先事項として支持する立場の人はいるか。 **空白のリスク：**案件は否定されないまま、他のテーマに優先順位を奪われます。反対がないのに進まない案件の多くは、この軸が空白です。 **注意：**経営層と接触することが目的ではありません。推進者の上位に、この案件を支持している人がいるかを確認することが目的です。
空白には3種類ある
5軸の空白は、すべて同じ意味ではありません。対処が異なります。
| 空白の種類 | 状態 | 対処 |
|---|---|---|
| 未接触 | 部門も担当者も分かっているが、接点がない | 推進者経由で紹介を依頼する。最も対処しやすい |
| 未特定 | その軸を誰が判断するのか分からない | 経路を質問する。「どちらにご確認いただくことになりますか」 |
| 存在するか不明 | その軸の審査自体が必要なのか分からない | 過去の類似導入の経緯を聞く。最も危険な空白 |
3番目が最も危険です。必要かどうか分からない審査は、存在しないものとして扱われがちだからです。品質保証部門の確認が必要な業種で、その確認の存在を知らないまま提案を進めれば、承認直前に判明します。
過去の類似導入について聞く質問は、この種類の空白を埋める最も確実な方法です。
「以前、同様のシステムを導入されたときは、どちらの部門がご確認に関わられましたか」
推測で組織図を描くより、実際の経緯を1つ聞く方が正確です。関係者を個別に整理する手順は ++関係者マッピングの考え方++ で扱っています。
早期に検出するための運用
点検は、案件が止まってから行うものではありません。運用として組み込みます。
1. 案件の開始時に、5軸を空欄で並べる 接触した部門だけを記録すると、一覧は常に「順調」に見えます。5軸を最初から並べておけば、埋まっていない軸が視覚的に残ります。
2. 顧客接点の記録に、どの軸に関する接点かを紐づける 面談を記録する際、その接点がどの軸を前進させたかを残します。記録が増えても軸が埋まらない場合、活動が特定の軸に偏っていることが分かります。記録の方法は ++商談履歴の残し方++ を参照してください。
3. 定期的に「一度も登場していない軸」を確認する 2週間に一度程度、5軸を見返します。確認するのは進捗ではなく、空白のままの軸があるかです。
4. 空白の種類を判定する 未接触なのか、未特定なのか、必要かどうか不明なのか。種類によって次の行動が変わります。
例：食品メーカーへの検査機器導入
※ 以下は考え方を示すための仮想例です。実在の顧客事例ではありません。
案件：食品メーカーの製造拠点への検査機器導入。提案から2か月、製造部門の評価は良好。
| 承認の軸 | 状態 | 空白の種類 |
|---|---|---|
| 利用部門の受け入れ（製造部門） | 実機評価済み、肯定的 | ― |
| 技術承認 | 設備管理部門と接触、仕様確認中 | ― |
| 技術承認（品質保証） | 未登場 | 存在するか不明 |
| 商務承認（購買） | 見積提出済み | ― |
| 予算承認 | 設備投資枠との回答のみ、決裁者不明 | 未特定 |
| 経営層の後ろ盾 | 未確認 | 未特定 |
この時点で見えること
製造部門の支持と設備管理部門との技術確認は進んでおり、表面的には順調です。しかし、検査機器という性質上、品質保証部門が検証や承認に関与する可能性があります。その部門が一度も会話に登場していません。
これは「品質保証部門が反対している」という意味ではありません。関与するのかどうかすら分かっていないという意味です。
確認の一手
推進者に対して、過去の類似導入の経緯を聞きます。
「以前、検査工程の設備を更新された際は、どちらの部門がご確認に入られましたか」
この質問の回答によって、3つのうちどれかが分かります。品質保証の関与が必要なのか、設備管理で完結するのか、それとも推進者自身も把握していないのか。3番目であれば、推進者の情報範囲の限界が判明したことになり、それ自体が重要な情報です。
予算軸の扱い
設備投資枠という回答は、予算の存在を示していますが決裁者を示していません。この状態で条件がすべて整うと、最後に「誰が決めるのか」から始めることになります。
停滞が実際に起きた後の切り分けは ++商談が進まない理由の見つけ方++ で扱っています。本記事は、その前段の予防に焦点を置いています。
空白が埋まらないこと自体が情報
推進者に紹介を依頼しても、他部門との接点が作られないことがあります。何度依頼しても「こちらで確認します」で止まる状態です。
この状態は、次のいずれかを示している可能性があります。
- 推進者が、社内でその部門に働きかける立場にない
- 案件がまだ社内で正式な検討対象になっていない
- 推進者自身が、他部門の関与を避けたい理由がある
- 組織として、ベンダーと個別部門を直接つなげない方針がある
いずれの場合も、接触量を増やしても状況は変わりません。紹介が得られない理由を確認する方が、案件の実態に近づけます。
「差し支えなければ、社内でのご検討はどの段階にありますでしょうか」
この質問は、案件が正式化しているかどうかを確認するものです。正式化していない案件に対して条件交渉を進めても、条件は確定しません。
埋まっていない空白を、見える状態に保つ ― VINEQRA の考え方
VINEQRA は、複数の関係者が関わる長期案件を担当する営業担当者個人のために設計された iOS 向けの AI CRM です。設計上の前提のひとつは、記録に現れないものこそがリスクであるという点にあります。
商談の文脈は次の構造で捉えます。
顧客接点 ＋ 関係者 ＋ 意思決定ポイント ＋ 阻害要因 → 次に取るべき行動（Next Best Action）
（VINEQRA Opportunity Context Model）
カバレッジの点検に関係するのは、記録された顧客接点と関係者情報を照合し、接点の記録が存在しない関係者や、未解決のまま残っている条件を手がかりとして提示できる点です。
対応する AI 分析は、Apple Foundation Models を通じて端末内のシステム言語モデルで実行できます。
そして、前提となる原則があります。
VINEQRA は提案します。判断するのは営業担当者です。
どの軸が本当に必要かは業種と顧客組織によって異なります。提示されるのは記録から読み取れる手がかりであり、その案件に品質保証部門の承認が必要かどうかを判定するものではありません。
よくある質問
Q. 5軸すべてを埋めないと提案を進められませんか？ 進められます。5軸は進行の前提条件ではなく、点検の枠組みです。埋まっていない軸があることを認識したうえで進めるのと、気づかずに進めるのとでは、後から出てくる要件への備えが変わります。
Q. 中小企業が相手の場合、5軸は過剰ではありませんか？ 軸の数は変わりませんが、1人が複数の軸を担うことがあります。社長が商務・予算・経営の3軸を兼ねる場合、その3軸は同時に埋まります。軸を減らすのではなく、誰がどの軸を担うかを確認すると考えてください。
Q. 相手に「他にどなたが関わりますか」と聞いても、はぐらかされます。 権限を尋ねる形は警戒されやすい傾向があります。過去の類似導入の経緯を聞く形、または資料の送付先を尋ねる形の方が答えやすくなります。それでも答えが得られない場合、答えられない理由の方が重要な情報です。
Q. 技術承認の部門は、どうやって想定すればいいですか？ 自社製品が触れる領域から逆算します。データを扱うなら情報システムと情報セキュリティ、製造工程に関わるなら設備管理と品質保証、施設に関わるなら施設管理。想定した部門が実際には関与しないこともありますが、想定しておけば確認できます。
Q. 空白が多い案件は、追わない方がいいのでしょうか？ 空白の数自体は追う・追わないの基準になりません。基準は、空白を埋める行動を取ったときに反応があるかどうかです。埋まらない状態が続く案件は、社内で正式化していない可能性があります。
後から出てくるものは、最初から存在している
承認の直前に現れる部門は、その時点で生まれたわけではありません。最初から存在していて、こちらの記録に登場していなかっただけです。
接触した相手の数ではなく、承認の軸がいくつ埋まっているか。この見方に変えると、順調に見える案件のリスクが早い段階で見えます。
VINEQRA は、複数部門の関係者と顧客接点を1つの商談として保持し、接点の記録がない関係者や未解決の条件を手がかりとして提示します。
空白に、手遅れになる前に気づく。 → VINEQRAをApp Storeでダウンロード