BtoB営業で商談履歴を管理する目的は、活動量を記録することではありません。数か月後に「この案件は今どこまで進んでいて、何が止まっているのか」を再構成できる状態にしておくことです。
そのために、1回のやり取りごとに残すべき情報は次の5つです。
- 事実 ― 実際に何が起きたか
- 関係者 ― 誰が出席し、誰が発言したか、その役割は何か
- 要求・宿題 ― 相手から何を求められたか、こちらは何を約束したか
- 動いた条件 ― どの承認・検証・意思決定ポイントが前進したか
- 未解決事項 ― 何が決まっていないまま残ったか
日付と「訪問、良い感触」だけのメモでは、3か月後に商談の状態を説明できません。長期・多部門の案件ほど、この差が失注の理由になります。本記事では、実務で続けられる記録の型と、記録を判断につなげる構造を整理します。
なぜ「記録しているのに使えない」が起きるのか
多くの営業担当者は、記録していないわけではありません。記録の粒度と構造が、後の判断に耐えないだけです。
典型的な状態は次の通りです。
- 議事メモはあるが、誰がどの立場で発言したのかが残っていない
- 「検討中」とだけ書かれ、何を検討しているのかが書かれていない
- 相手の宿題と自分の宿題が混在し、どちらが止まっているのか分からない
- CRM には活動が登録されているが、活動の意味（何が前進したか）が登録されていない
この状態だと、商談の進捗を語る材料がステージ表示しか残りません。ステージは社内の管理ラベルであって、顧客側の意思決定がどこまで進んだかを表していません。
| よくある記録 | 判断に使える記録 |
|---|---|
| 4/12 A病院 訪問、感触良好 | 4/12 A病院 臨床部門 田中課長・技師2名に実機デモ。運用フローは問題なしとの評価。院内ネットワーク接続要件について情報システム部の確認が必要と指摘あり |
| 見積提出済み | 4/20 購買部あて見積提出。比較対象は他社2社との回答。価格根拠より保守体制の説明を求められている |
| 返信待ち | 5/2 情報システム部のセキュリティ確認待ち。担当者不明のため、臨床部門経由で照会を依頼済み（回答期限の合意なし） |
右列は文字数が多いのではなく、再利用できる情報が入っているという違いです。
商談履歴として残すべき5つの要素
記録の目的別に定義すると、次のようになります。
| 要素 | 何を書くか | なぜ必要か |
|---|---|---|
| 事実 | 日時、形式（訪問・Web会議・電話・メール）、実際のやり取り | 解釈と事実を分離するため。後から解釈だけ書き換えられる |
| 関係者 | 参加者、所属部門、役割、その人の関心事 | 部門ごとに判断基準が違うため。誰の懸念かが分からない記録は使えない |
| 要求・宿題 | 相手からの依頼、こちらの約束、期限 | 商談が止まる原因の多くは、未回収の宿題である |
| 動いた条件 | 検証・承認・稟議・予算確認などのうち、前進した項目 | 進捗とは活動量ではなく、条件の充足である |
| 未解決事項 | 決まらなかったこと、確認できなかったこと | 次回の議題がここから決まる |
「事実」と「解釈」を分ける
営業メモで最も劣化しやすいのが、この2つの混在です。
- 事実：「情報システム部が院内ネットワークの接続要件を確認すると述べた」
- 解釈：「情報システム部は前向きだと思われる」
解釈は書いて構いませんが、解釈だと分かる形で書きます。3か月後、事実は判断材料として使えますが、根拠の消えた解釈は誤った楽観を残すだけです。
関係者は「名前」ではなく「役割と関心事」で残す
連絡先と関係者は同じではありません。名刺交換した相手全員が意思決定に関与するわけではなく、一度も会っていない人物が承認を左右することもあります。
記録時点では、最低限この3項目を残します。
- 所属部門（使用部門／情報システム／購買／経理／経営層 など）
- 案件内での役割（推進者・技術評価者・承認者・影響者）
- その人が気にしていること（運用負荷、セキュリティ、価格、保守、院内調整 など）
役割が不明な場合は「不明」と書きます。空欄は「いない」と誤読されますが、「不明」は次に確認すべき項目として残ります。関係者の構造化そのものについては、++関係者マッピングの考え方++ で詳しく扱います。
「動いた条件」を書くと、進捗が説明できるようになる
複数部門が関わる案件では、進捗は一本の線ではありません。使用部門の評価は完了していても、情報システムの確認が未着手、購買は未接触、予算の決裁者が未特定、という状態が同時に存在します。
そのため、記録では どの条件が満たされたか を項目として残します。日本企業の案件では、稟議・決裁の承認ラインも重要な条件のひとつになります。ステージ表示が「提案中」のままでも、条件単位で見れば前進も停滞も説明できます。
1回のやり取りをどう記録するか（記録フォーマット）
現場で続けられる分量として、次の型を推奨します。所要時間は5分前後です。
■ 日時・形式
2026/04/12 14:00 訪問（実機デモ）
■ 出席者
臨床部門：田中課長（使用部門責任者／運用負荷を重視）
臨床部門：技師2名（実務評価）
※情報システム部の出席なし
■ 事実
・実機デモを45分実施。現行運用フローとの整合性について異論なし
・院内ネットワークへの接続要件は情報システム部の確認が必要と田中課長が指摘
・導入時期は次年度予算での検討と発言
■ 相手の宿題
・情報システム部の担当者を紹介（期限の合意なし）
■ 自社の宿題
・接続要件の技術資料を4/19までに提出
■ 動いた条件
・使用部門による機能評価：実質完了
■ 未解決
・情報システム部の要件および担当者が未特定
・次年度予算の決裁者が未特定
■ 解釈（根拠付き）
・使用部門は支持側と見られる（デモ時の発言および運用フローへの異論なしから）要点は、次に何を確認すべきかが、記録そのものから読み取れることです。上の例では「情報システム部の担当者特定」と「予算決裁者の特定」が、次回以降の行動候補として自動的に浮かび上がります。
記録を判断材料に変える構造
記録は蓄積するだけでは意味を持ちません。VINEQRA では、商談の文脈を次の構造で捉えます。
顧客接点 ＋ 関係者 ＋ 意思決定ポイント ＋ 阻害要因 → 次に取るべき行動（Next Best Action）
（VINEQRA Opportunity Context Model）
- 顧客接点：実際に何が起きたか
- 関係者：誰が関与し、何を重視しているか
- 意思決定ポイント：前進のために満たすべき条件
- 阻害要因：進行を妨げている、または前進の可能性を大きく下げている未解決の条件
- 次に取るべき行動：現在の状態を踏まえて、次に検討すべき最も適切な一手
ここで重要なのは、未返信と阻害要因は違うという点です。
| 状態 | 例 | 阻害要因か |
|---|---|---|
| 未返信 | 1週間メールの返信がない | いいえ（情報不足の状態） |
| 懸念 | 保守体制に不安があると言われた | いいえ（対応可能な論点） |
| 依存関係 | 情報システムの確認が終わるまで購買は動けない | はい |
| 未承認 | 稟議が起案されていない | はい |
| 関係者不在 | 予算の決裁者が特定できていない | はい |
「返信がない」を阻害要因として扱うと、本当に止まっている条件が見えなくなります。この切り分けの詳細は ++商談が止まる理由の特定方法++ で扱います。
実例：病院向け医療機器案件
※ 以下は製品説明のための仮想例です。実在の顧客事例ではありません。
案件概要：中規模病院向け機器導入、想定サイクル6〜9か月、使用部門主導で開始。
| 関係者／部門 | 役割 | 関心事 | 現在の状態 |
|---|---|---|---|
| 臨床部門（田中課長） | 使用部門責任者・推進者 | 運用負荷、業務適合 | 機能評価は実質完了 |
| 情報システム部 | 技術評価・承認 | 接続要件、セキュリティ | 担当者未特定、未接触 |
| 購買部 | 契約・条件交渉 | 価格、保守条件 | 見積提出済み、比較検討中 |
| 経営層 | 最終決裁 | 予算優先度 | 決裁者未特定 |
顧客接点の履歴（抜粋）
- 4/12 実機デモ：使用部門が運用適合を確認。情報システム部の確認が必要と指摘
- 4/19 技術資料提出：先方からの受領確認のみ
- 4/20 購買部へ見積提出：他社2社との比較と回答
- 5/2 進捗確認：情報システム部の確認待ちとの回答、担当者名は不明のまま
阻害要因の候補 情報システム部による接続要件の確認が完了しないと購買プロセスが前に進まない、という依存関係。担当者が特定できていないため、依存関係の解消に着手できていない。
次に取るべき行動の候補 価格や保守条件の追加提案ではなく、推進者である臨床部門を通じて情報システム部の担当者を特定し、確認事項と所要期間を合意すること。
この結論は、記録の中に関係者・宿題・未解決事項が分離して残っていたから導けます。「訪問、感触良好」という記録しかなければ、次の行動は値引き提案か定期的な進捗確認に落ちていたはずです。行動選択の設計そのものは ++次に取るべき行動の決め方++ で詳しく扱います。
記録を続けるための運用ルール
- その日のうちに残す。 翌日には、誰がどの立場で何を言ったかが曖昧になります。
- 1接点＝1記録。 週次でまとめると、条件の前進と未解決事項が混ざります。
- 未確定は「不明」と書く。 空欄は情報がないことを意味しません。
- 相手の宿題と自社の宿題を分けて書く。 停滞の所在が一目で分かります。
- 商談単位で束ねる。 連絡先単位で記録すると、複数部門が関わる案件の全体像が失われます。
避けたい失敗として多いのは、記録の完璧さを追求して続かなくなることです。5要素が揃っていれば、文章として整っている必要はありません。
顧客接点の記録から、商談の状態把握へ ― VINEQRA の考え方
VINEQRA は、複数の関係者が関わる長期案件を担当する営業担当者個人のために設計された iOS 向けの AI CRM です。設計上の前提は、顧客接点の履歴は活動ログではなく、商談を推論するための根拠層であるという点にあります。
製品としての流れは次の4段階です。
- 記録（Capture）：顧客接点、関係者、要求、未解決事項を商談単位で残す
- 構造化（Understand）：記録を関係者・部門・意思決定ポイントと結びつける
- 推論（Reason）：蓄積された文脈から、進捗の兆候、関係者の空白、阻害要因の候補を提示する
- 行動（Act）：現在の状態に対して、次に検討すべき行動を提案する
[Product Screenshot: Multi-Stakeholder Deal View] （1つの商談に複数部門の関係者と、それぞれの状態が表示されている画面）
AI による分析は、対応する処理について Apple Foundation Models を通じて端末内のシステム言語モデルで実行できます。これにより、対象となる推論処理を外部のクラウド LLM に送らずに実行でき、プライバシーに配慮した構成を支えます。ただし、これは当該の推論処理に関する範囲の説明であり、アプリ全体のデータの取り扱いを一律に示すものではありません。
そして、前提として次の原則があります。
VINEQRA は提案します。判断するのは営業担当者です。
AI の提案は確実な結論ではなく、検討すべき候補です。商談の文脈を最も理解しているのは、その場にいた担当者本人です。
よくある質問
Q. 会社の CRM に入力していれば十分では？ CRM は「何が起きたか」を記録する仕組みとして機能します。一方で、記録された内容から「今どの条件が満たされていないのか」を読み取るには、関係者・意思決定ポイント・未解決事項が構造として残っている必要があります。多くの場合、不足しているのはツールではなく記録の粒度です。
Q. どこまで細かく記録すればいいですか？ 判断基準は文字数ではなく、「3か月後の自分が、この記録だけで次の一手を決められるか」です。本記事の5要素が残っていれば、多くの案件で足ります。
Q. 通話やメールを自動で取り込めば解決しますか？ 自動取得は「事実」の収集を効率化しますが、役割・関心事・未解決事項の判断は自動化しにくい領域です。取り込んだ情報に、担当者自身の観察を加える運用が現実的です。
Q. 記録は誰のために残すのですか？ 第一に、数か月後の自分自身のためです。副次的に、引き継ぎ時の情報損失を減らし、上長への進捗説明をステージ表示ではなく条件の充足状況で説明できるようになります。
Q. 記録を AI に要約させれば十分ですか？ 要約は読む負担を減らしますが、元の記録に関係者や未解決事項が含まれていなければ、要約にもそれらは現れません。推論の精度は、入力された文脈の質に依存します。
商談の現在地を、記録から説明できる状態に
商談履歴の管理は、報告のための作業ではありません。長期・多部門の案件で、どの条件が満たされ、何が止まっているのかを説明できる状態を保つための手段です。
VINEQRA は、記録した顧客接点を関係者・意思決定ポイント・阻害要因と結びつけ、次に検討すべき行動を提示します。
商談の現在地と次の一手を、手元の iPhone で。 → VINEQRAをApp Storeでダウンロード