---
name: call-summary-crm-notes
description: 商談の文字起こしやラフなメモを、HubSpot・Salesforce・Pipedrive にそのまま貼れる CRM 用メモにする。項目は課題、影響、予算、決裁者、時期、次のアクション、ステージ案、リスクで、すべてプレーンテキスト。商談の文字起こし、Gong や Zoom のメモ、箇条書きのメモを渡されて、商談記録、CRM の更新、案件メモ、商談ログを頼まれたときに使う。
---

# 商談メモを CRM 用に整える

CRM のメモは、次にその案件を開く人のためのもの。3週間後の自分も含む。各項目には顧客が言ったことを、ひと目で読める短さで書き、話に出なかった項目は「話題に出ず」と書く。空欄は正直だが、推測で埋めた項目は売上予測を狂わせる。

## 使う場面

- ヒアリング、デモ、条件交渉の商談のあと、文字起こしかメモがあるとき。
- パイプラインレビューの前に、上司から「案件を更新しておいて」と言われたとき。
- 案件をほかの営業やカスタマーサクセスに引き継ぐとき。
- 顧客に送るメールには使わない。それは follow-up-email を使う。

## 用意するもの

- 文字起こしかメモ。話者が書かれていなければ、だれが顧客側か一度だけ聞く。
- CRM 上の現在のステージ（わかれば）。なければステージを提案し、提案であることを書く。
- あれば：チームのステージ定義。なければ手順6の既定のステージを使う。

## 手順

1. **顧客の発言だけを拾う。** 各項目には、営業が説明したことではなく、顧客が言ったことか認めたことを書く。言い回しが大事なときは、短く「」で引用する（「これ以上アナリストは採用できない」）。
2. **課題と影響を分けて書く。** 課題は困っていること（「レポートに3日かかる」）。影響はそれで失っているもの（お金、時間、リスク、達成できない目標）。顧客が数字を言わなかったら、見積もらずに「数字の言及なし」と書く。
3. **予算・決裁者・時期は厳密に書く。** この3つは Salesforce が定義する BANT（予算、決裁権、ニーズ、時期）の項目で、ニーズは課題でカバーする。予算：金額、幅、出どころ。出なければ「話題に出ず」。決裁者：だれが承認するかの名前と役職、ほかに意見を言う人。時期：顧客が挙げた日付か出来事（「来期の計画の前に」）。「近いうちに」から日付を推測しない。
4. **次のアクションを書く。** だれが、何を、いつまでに、を1行で。日付のある次のアクションが決まらずに終わった商談は「合意なし」と書き、リスクの先頭に置く。
5. **リスクを挙げる。** 最大4つ、重い順に。次のアクションがない、決裁者が不明、競合の名前が出た、予算が未確認、推進役が異動・退職する、時期が先方でどうにもできないことに左右される、など。
6. **ステージを提案する。** HubSpot では案件ステージごとに受注確度を設定し、それで案件金額を重みづけする。ステージを高くつけすぎると、加重パイプラインがふくらむ。チームの定義がないときの既定のステージ（このスキルの判断）：ヒアリング（課題が未確認）、見込みあり（課題と影響を確認、決裁者が判明）、提案（デモか提案書を検討中）、交渉（価格か条件を協議中）、内諾（日付つきの口頭での了承）。営業の期待ではなく、根拠が支えるステージを提案する。現在のステージと違うなら、理由を1行で書く。
7. **貼りつけられる形にする。** このスキルの既定値：プレーンテキストで1行1項目、表・Markdown・絵文字なし。HubSpot と Pipedrive のメモ欄はツールバーで書式をつける方式で Markdown ではないため、貼った Markdown の記号がそのまま文字として出ることがある。プレーンテキストなら1行のカスタム項目やスマホのアプリにも収まる。全体を500字以内にする。

## 出力の形式

```markdown
商談: [日付] - [会社名] - [商談の種類]
参加者: [顧客側の名前と役職]、[自社側の名前]

課題: [困っていること。顧客の言葉で]
影響: [お金・時間・リスクでの損失。なければ「数字の言及なし」]
予算: [金額か出どころ。なければ「話題に出ず」]
決裁者: [承認者の名前と役職。ほかの関係者]
時期: [顧客が挙げた日付か出来事。なければ「話題に出ず」]
次のアクション: [だれが何をいつまでに。なければ「合意なし」]
ステージ案: [ステージ]（現在: [ステージか不明]） - [理由を1行で]
リスク: [1] [2] [3]
競合: [名前か「なし」]
メモ: [次の担当者が知っておくべきこと。1〜2行]
```

## 例

**入力（抜粋）:** 2025年11月4日（火）の商談。「営業」は営業担当の高橋。

> 佐藤（北星ロジスティクス 経理部長）: 月次決算に9日かかっています。CFO は3月の監査までに5日にしたいと。
> 営業: 9日かかっている主な原因は何でしょう？
> 佐藤: ほとんどが運送会社の請求書の突き合わせです。2人が手作業でやっています。
> 営業: ツール選定には、ほかにどなたが関わりますか？
> 佐藤: 業務を回しているのは経理課長の森です。300万円を超えるものは CFO が決裁します。
> 佐藤: 去年 Ledgerline も見たんですが、重すぎて。
> 営業: 金曜にパイロットの計画をお送りしてもよろしいですか？
> 佐藤: はい。次回は森も呼びます。

**出力:**

```markdown
商談: 11月4日（火） - 北星ロジスティクス - ヒアリング
参加者: 佐藤（経理部長）、高橋（営業）

課題: 月次決算に9日。大半は運送会社の請求書の手作業での突き合わせ（2人）。
影響: CFO は3月の監査までに決算を5日にしたい。コストの数字の言及なし。
予算: 話題に出ず。300万円を超えるものは CFO が決裁。
決裁者: CFO が決裁（名前は不明）。森（経理課長）が業務を担当。窓口は佐藤（経理部長）。
時期: 3月の監査までに決算を5日に。
次のアクション: 高橋が11月7日（金）までにパイロット計画を送付。佐藤が次回に森を同席させる（日程未定）。
ステージ案: ヒアリング（現在: 不明） - 課題は明確だが、決裁者に会えておらず予算も不明。
リスク: [1] 次回の日程が未定。[2] CFO に未接触、名前も不明。[3] 予算が話題に出ず。[4] 以前 Ledgerline を検討し「重すぎ」と判断。
競合: Ledgerline（去年検討し、見送り）
メモ: パイロットは運用が軽いことを前面に。Ledgerline が落ちた理由は「重すぎ」。
```

## 送る前のチェック

- [ ] すべての項目が埋まり、話に出なかった項目は「話題に出ず」か「合意なし」になっている。
- [ ] 顧客が言っていない予算・日付・名前を書いていない。
- [ ] 課題と影響が別の内容になっている。
- [ ] ステージ案がステージの定義に合い、理由がある。
- [ ] プレーンテキストだけ（表・太字・絵文字なし）で、500字以内。

## よくある失敗

- 大企業だからと「予算: おそらく問題なし」と書く。「話題に出ず」と書く。
- 営業の説明を、顧客の課題として記録する。
- 商談の手ごたえがよかったからとステージを上げる。ステージは根拠（決裁者、課題、日付）で決める。