Mutual Action PlanにAIをどう使う？受注前の共同進行表を止めない運用
大型案件ほど、失注の理由は『競合に負けた』ことより『進行が止まった』ことにあります。会議は開けていても、誰が何をいつまでにやるかが曖昧なままでは、顧客側も自社側も前に進めません。
3行でいうと、Mutual Action PlanにAIを使う価値は『共同進行表を作ること』ではなく『止まりそうな条件を先に見つけること』にあります。商談後フォローAI の延長として設計し、パイプライン管理AI とつなぐと、受注前の進行が安定しやすくなります。
本記事のポイント
- Mutual Action PlanにAIを使う価値は、表の作成より、顧客側と自社側の進行条件を同じ型で更新することにあります。
- AIは遅延兆候や依存関係を整理できますが、どの条件を受注前の必須マイルストーンにするかは人が決めるべきです。
- 導入初期は、マイルストーン更新頻度、遅延検知件数、次アクション確定率を追うと効果が見えやすくなります。
この記事で扱うテーマ
関連キーワード
- Mutual Action Plan AI
- 共同進行表 AI 営業
- MAP AI 営業
- 受注前 進行管理 AI
- 営業 マイルストーン AI
このページで答える質問
- Mutual Action PlanでAIは何を助ける？
- 受注前の共同進行表をどう止めない？
- MAP運用でAIに任せてよい範囲は？
- Mutual Action Plan AIのKPIは何を見る？
Mutual Action Plan AIの結論は「表の共有」より「前進条件の更新運用」で効く
Mutual Action Planは、見た目のきれいな共有表を作っても、更新されなければ意味がありません。重要なのは、顧客側と自社側の前進条件がどこで止まり、何を解消すべきかを両者が同じ画面で見られることです。
そのため、AIにはタスクの列挙ではなく、『マイルストーン』『担当』『依存関係』『遅延兆候』『次に必要な材料』を更新レイヤーとして扱わせる方が実務に合います。
Mutual Action PlanにAIを入れる意味は、共同進行表を作ることではなく、『どこで止まりそうか』を営業が早く掴めることにあります。
| 進行要素 | AIが先に出すもの | 人が確認すること | 見るべきKPI |
|---|---|---|---|
| マイルストーン | 必要な前進条件と日付候補 | 本当に必須の条件か | 更新頻度 |
| 担当整理 | 顧客側と自社側の担当案 | 責任者と承認者の確定 | 担当未設定率 |
| 依存関係 | 先に終わるべきタスクの整理 | 順番の妥当性 | 未解消件数 |
| 遅延検知 | 止まりそうなタスク、未返信、宿題滞留の提示 | 介入の優先順位 | 遅延検知件数 |
MAPテンプレート構造
Mutual Action Planを属人的な表にしないためには、共通のテンプレート構造が必要です。以下の構造を基本にすると、案件規模やディールタイプが変わっても同じフォーマットで進行管理ができます。
| テンプレート要素 | 記載内容 | 更新頻度 | 責任者 |
|---|---|---|---|
| 案件概要 | 目的、期待成果、検討開始の背景 | 初回のみ（変更時に更新） | 営業担当 |
| マイルストーン一覧 | 受注前に通るべき節目と目標日 | 週次 | 営業担当+顧客担当 |
| タスク・担当マトリクス | タスク名、担当（顧客/自社）、期限、ステータス | 週次 | 各タスク担当者 |
| 依存関係マップ | 先行タスクと後続タスクの関係 | マイルストーン変更時 | 営業担当 |
| リスク・ブロッカー | 停滞要因、未確認事項、対処方針 | 週次 | 営業担当 |
| ステークホルダー一覧 | 関与者の役割、意思決定権限、温度感 | 変更時 | 営業担当 |
| 次回アクション | 次の接点日、議題、準備物 | 接点ごと | 営業担当+顧客担当 |
ディールタイプ別のマイルストーン例
マイルストーンはディールタイプによって大きく変わります。自社の典型的な案件パターンに合わせてテンプレートを分けておくと、新規案件の立ち上げが速くなります。
| ディールタイプ | 主要マイルストーン | 典型的な期間 | 止まりやすいポイント |
|---|---|---|---|
| 新規SaaS導入 | 要件定義 → デモ → PoC → 評価 → 稟議 → 契約 | 3-6ヶ月 | PoC評価基準の合意、稟議書作成 |
| リプレイス案件 | 現状課題整理 → 比較評価 → 移行計画 → 稟議 → 契約 | 4-8ヶ月 | 移行コストの社内承認、既存ベンダーとの交渉 |
| アップセル・追加導入 | 利用状況確認 → 追加要件 → 見積 → 承認 → 契約 | 1-3ヶ月 | 追加予算の確保、既存契約との整合 |
| コンサルティング案件 | 課題診断 → スコープ合意 → 提案 → 稟議 → 契約 | 2-4ヶ月 | スコープの膨張、ROI根拠の作成 |
| 複数部門横断案件 | 部門別ヒアリング → 全体要件 → 提案 → 各部門承認 → 契約 | 6-12ヶ月 | 部門間の優先順位調整、横断予算の確保 |
ステークホルダー整合表
Mutual Action Planが形骸化する最大の原因は、関与者の役割と期待が整理されていないことです。以下の整合表を使って、誰がどの判断に関わるかを可視化すると、止まりやすいポイントが事前に見えます。
| ステークホルダー役割 | MAP上の関与 | 必要な情報 | 整合が取れないとき起きること |
|---|---|---|---|
| 意思決定者 | マイルストーンの承認 | 費用対効果、リスク評価 | 稟議が差し戻される |
| 評価者 | PoC・デモの評価基準設定 | 技術要件、運用要件 | 評価基準が後出しで変わる |
| 推進者（チャンピオン） | 社内調整、スケジュール管理 | 持ち帰り用の要約材料 | 社内調整が遅延する |
| 利用者（現場） | 要件のインプット | 具体的な運用イメージ | 導入後に現場から反発が出る |
| 法務・購買 | 契約条件のレビュー | 契約書ドラフト、SLA | 契約交渉で想定外の遅延 |
Mutual Action Plan AIが効く場面
複数部門が関与する大型提案
現場部門、情報システム、法務、購買が別の論点を持つ案件です。どの条件が受注前に必要かを並べるだけでも前進しやすくなります。
PoCから本契約へ進む案件
評価項目、意思決定、契約条件が段階的に進む場面です。PoCの出口条件を曖昧にしないことが重要になります。
四半期またぎの案件
稟議や予算化のタイミングがずれると進行が止まりやすい場面です。遅延兆候を拾えるほど、先回りしたフォローがしやすくなります。
Mutual Action Plan AIを運用に載せる手順
1. 受注前の必須マイルストーンを決める
提案提出、評価完了、稟議開始、契約確認など、自社で必ず通るべき節目を固定します。ここが曖昧だと、MAPが単なるToDo表になります。
2. 顧客側と自社側の責任を分けて見せる
双方の担当が混ざると、遅延原因が見えにくくなります。誰が止めているのかを可視化するために、責任のレイヤーを分ける方が有効です。
3. タスクではなく依存関係を先に整理する
順番を誤ると、いくら頑張っても進みません。どの条件が終わらないと次に行けないかを先に出すと、進行の詰まりが見えやすくなります。
失敗しやすい3つのパターン
MAPを営業側のToDo表にしてしまう
顧客側の前進条件が入っていなければ、共同進行表にはなりません。双方の責任を見える化することが前提です。
遅延の発見が会議直前になる
止まってから気付くと挽回が難しくなります。未返信や未設定タスクを定期的に見る運用が必要です。
マイルストーンが多すぎて優先順位が消える
細かいタスクを増やしすぎると、どの条件が本当に重要か見えなくなります。まずは受注前の必須条件に絞る方が実務的です。
よくある質問
Mutual Action Planは顧客に必ず見せるべきですか？
基本的には顧客と共有する前提の方が機能します。ただし、社内向けの補助レイヤーと分けて持つ方が安全な情報もあります。
普通のタスク管理と何が違いますか？
Mutual Action Planは、受注前に何が整えば前進するかを顧客と自社で共有する運用です。営業側のタスク管理だけでは前進条件が見えません。
最初に見るべきKPIは何ですか？
マイルストーン更新頻度、遅延検知件数、次アクション確定率です。案件が止まる前に兆候を捉えられているかが重要です。
小規模案件でもMAPは必要ですか？
必須ではありませんが、意思決定者が2名以上いる案件では簡易版のMAPでも効果があります。マイルストーンと担当だけを整理するだけでも、進行の見通しが改善します。
