商談振り返り例文|シーン別テンプレートと3要素の書き方

商談振り返りが「形式的で終わる」原因

商談後に振り返りを書いているにもかかわらず、「次の商談で何かが変わった実感がない」という状況は珍しくありません。この原因は書く意欲や能力の問題ではなく、振り返りに必要な3要素のうちひとつが構造的に抜け落ちていることにあります。その3要素とは「事実(何が起きたか)」「解釈(なぜそうなったか)」「行動(次はどうするか)」です。多くの人が採用している「良かった点・改善点・次のアクション」というフォーマットは記入しやすいため便利ですが、「解釈」の層が抜け落ちやすい構造になっています。それぞれの欄を思い浮かぶままに埋めるだけでは出来事の羅列で終わり、「次のアクション」が仮説のない施策になってしまいます。この構造的な問題を理解することが、振り返りを実効性のあるものに変える第一歩です。

PR|運営者より

営業のために顧客管理システムを作ったら、社内通貨「Gold」が生まれて、組織が動き出しました。その経緯をnoteに書いています。

→ 【30】営業のために顧客管理システム作ったら、Goldという社内通貨ができて組織が地球儀ぐるぐる回し始めた

この仕組みを、どの会社でも使える形にして、私たちが提供しているのが「Game toB」です。

Game toB法人向けゲーミフィケーションサービスwww.game-tob.bizGame toB 法人向けゲーミフィケーションサービス

商談振り返り例文の骨格——3要素で書く

振り返り例文を「機能させる」ためには、事実・解釈・行動の3要素を意識して書く必要があります。この3要素は競合他社の提案との比較や顧客の業界特性といった文脈とも組み合わせられるため、シーンを選ばない汎用的な骨格として使えます。

「事実」は起きたことの記述です。「ヒアリングが足りなかった」ではなく、「予算に関する質問を複数回したが、担当者は毎回『検討中』とだけ答え、具体的な金額感が出なかった」という粒度で書きます。記憶が薄れる前に書くことが重要で、商談直後の短い時間が最も価値のある記録時間です。「解釈」は、その事実に対する自分の仮説です。「なぜ担当者は数字を言わなかったのか」を考え、「決裁者が別にいて担当者自身が予算を把握していない可能性がある」と言語化します。この解釈の層があることで、振り返りが自己分析として機能します。「行動」は、その解釈に基づいた具体的な次のステップです。解釈が仮説である以上、行動は「その仮説を検証するための動き」になります。「次回は決裁構造を確認する質問を冒頭に入れる」という形にすることで、振り返りが次商談の設計まで完結します。

これが「ダメな振り返り例文」——何が足りないか

振り返り例文の書き方を解説する記事の多くは「良い例文」だけを掲載して終わります。しかし、自分が書いている振り返りが「ダメな例文」に近い形になっていないかを確認しなければ、どれだけ良い例文を読んでも改善のきっかけはつかめません。ここでは、営業現場でよく見かける2種類のダメな振り返り例文を取り上げ、それぞれ「何が足りないのか」を3要素の観点で解説し、修正版を示します。自分の過去の振り返りと照らし合わせながら読んでいただくと、どの要素が抜けやすいかが明確になります。

ダメ例①「ヒアリングが不足していました」

この一文は反省のように見えますが、振り返りとしては機能しません。「何を聞いて、何が返ってきて、どこで詰まったか」という事実が一切書かれていないからです。「ヒアリングが不足していた」という結論だけが先に来ており、次回に活かせる具体的な手がかりが残りません。

ダメな例文:「ヒアリングが不足していました。次回は丁寧にヒアリングします。」

修正版(3要素形式):「〔事実〕予算感を確認しようとしたが、担当者は『社内で確認します』と繰り返すだけで、具体的な金額は出ませんでした。〔解釈〕担当者が予算決定権を持っていない可能性があります。もしくは、こちらの提案金額が相場とかけ離れており、担当者が反応しにくい状況になっているかもしれません。〔行動〕次回商談の冒頭で、決裁フローと検討スケジュールを確認する質問を入れます。」

事実が記録されることで、「なぜヒアリングができなかったか」の仮説が立つようになります。仮説が立って初めて、次回の具体的な行動改善が生まれます。

ダメ例②「次回は提案書を改善します」

行動項目だけが書かれており、なぜ提案が刺さらなかったのかという解釈が抜けています。「提案書を改善する」という方向性は正しいかもしれませんが、「何が問題だったのか」の仮説がなければ、どこをどう直すかが見えません。改善施策が仮説なきまま実行され、次の商談でも同じ結果になるリスクがあります。

ダメな例文:「次回は提案書をもっとわかりやすく改善します。」

修正版(3要素形式):「〔事実〕ROIを示すスライドで担当者の反応が止まり、『少し難しいですね』との発言がありました。〔解釈〕ROIの試算式が複雑すぎて、担当者が社内で上司に説明できないと感じた可能性があります。決裁者向けの内容ではなく、担当者が稟議を通すための資料になっていなかったかもしれません。〔行動〕次回は担当者が上司に見せる想定で、要点を1枚にまとめたサマリスライドを追加します。」

修正版では、提案書のどの部分をどういう目的で直すかが明確になります。改善の方向性に根拠が生まれることで、次商談の準備が具体的になります。

シーン別 商談振り返り例文集

汎用的な例文テンプレートは振り返りの「型」を理解するには役立ちますが、実際の商談場面で使おうとすると抽象度が高すぎて当てはめにくいことがあります。振り返りは「自分の商談」に照らして書くものであるため、シーンが特定されていない例文ではどう変換すればよいかが見えないからです。ここでは「初回接触でニーズが掴めなかったとき」「価格交渉で前に進まなかったとき」「失注直後」という3つのシーンに絞り、そのまま転用できる例文を示します。各シーンとも事実・解釈・行動の3要素で構成しています。

初回接触でニーズが掴めなかったとき

初回商談は情報量が少なく、振り返りが「相手のことがよくわからなかった」で終わりがちです。だからこそ「どの質問をしたか、何が返ってきたか、どこで会話が止まったか」を丁寧に記録することが重要です。初回振り返りの精度が高いほど、次回商談の質問設計が具体的になります。

例文:「〔事実〕現在の業務課題を尋ねると担当者は『特に大きな問題はない』と答えました。その後、月末の締め処理の話題になったとき、担当者の言葉数が増え、声のトーンが変わりました。〔解釈〕顕在化した課題がないのではなく、担当者自身が課題として認識していない業務上の不便さがあると思われます。締め処理に潜在的な不満が存在する可能性が高いです。〔行動〕次回は締め処理の具体的な工程を聞き出す質問を準備します。担当者が自分で『困っている』と気づくような問いかけを設計します。」

※著者の体験

採用支援の立場で企業の初回商談に入ると、HR担当者から「採用は特に問題ないです」と言われることは珍しくありませんでした。私がその後に記録として残せたかどうかは、「どの質問で相手の反応が変わったか」まで書けたかどうかで次回の準備が大きく変わりました。

あるとき、選考の具体的な工程を確認する質問に切り替えた瞬間に、担当者の話量が急に増えたことがありました。「実は内定承諾率が…」という話が出てきたのは、その質問のあとでした。商談後に「話が弾んだ場面があった」とだけ書いていたら、翌日の準備には何も残りません。

「何を聞いたら会話が動いたか」まで書いておけば、次回の冒頭で同じ問いかけを再設計できます。書かなければ「なんとなく盛り上がった」という感覚だけが残り、それは次の商談設計には使えないと感じています。

価格交渉で前に進まなかったとき

価格交渉が止まるとき、問題が「価格そのもの」なのか「優先度・タイミング・社内事情」なのかを見極めることが重要です。その判断材料を振り返りの解釈の層に残しておくことで、次回アプローチの方向性が変わります。

例文:「〔事実〕見積を提示したところ、担当者から『もう少し検討させてください』とのみ返答がありました。金額に対する具体的な反応(高い・安い・想定範囲内)はなく、その後の質問にも短い回答が続きました。〔解釈〕価格が想定外に高く、担当者が上司に持ち帰りにくい状況になっている可能性があります。あるいは、予算はあるが他の優先事項があり、このタイミングでは意思決定できない状態かもしれません。〔行動〕次回は他に検討中のプロジェクトとの優先度感を確認します。稟議が通るために必要な条件を担当者と一緒に整理します。」

失注直後の振り返り

失注直後は感情が揺れているため、振り返りの事実記録が主観的になりやすいシーンです。「なぜ負けたか」を感情論で書くのではなく、「何を言われたか」「何を聞いたか」という事実ベースの記録を優先します。感情が落ち着いた後でも読み返せる記録にすることが、次の改善につながります。

例文:「〔事実〕最終選考で競合他社に決定した旨を担当者から連絡がありました。選定理由として『導入実績の多さ』が挙げられました。価格・機能についての言及はありませんでした。〔解釈〕担当者が稟議を通す際に、導入実績という客観的な根拠が必要だったと思われます。機能や価格よりも、社内説得の材料として実績を重視する組織文化があったかもしれません。〔行動〕同規模・同業種の導入事例をまとめた資料を次回提案時には必ず用意します。初回接触の段階で意思決定基準を確認する質問を追加します。」

※著者の体験

転職エージェントとして候補者を支援していると、別のルートで内定が決まったと連絡が来ることがあります。エージェントにとっての失注です。最初の頃は、そういう場面の振り返りに「もっと丁寧に進めるべきだった」「相性の問題だったかもしれない」という言葉を書いていました。

3,000名ほど面談を重ねる中で変わったのは、事実と解釈を分けて書くことでした。「最終面接の結果待ちの段階で候補者からの連絡が途絶えた」「その後、別会社への入社報告が来た」これだけ書けば、感情が落ち着いてからでも読める記録になります。感情が動いているうちに書いた記録は、後から読み返しても「その時こう感じた」という記録にしかなりませんでした。

事実だけが書いてある記録の方が、次に何を確認すべきだったかが後から見えやすい気がしています。

振り返り例文をKPT形式に落とし込む

チームでの振り返りや上司への報告に「KPT形式」を求められる組織では、ここまでの3要素形式の例文をKPTに変換して提出する場面があります。KPTとは「Keep(継続)・Problem(問題)・Try(次のアクション)」の頭文字で、改善サイクルを整理するためのフレームワークです。営業チームや組織全体の振り返り会議では、個人の振り返りをKPT形式にまとめて共有するケースが多く見られます。3要素形式とKPTは矛盾しません。事実・解釈・行動がKPTのどの項目に対応するかを理解すれば、同じ振り返りをどちらの形式でも表現できます。

KPTのK・P・Tに3要素例文をマッピングする

3要素とKPTの対応は次のように整理できます。K(Keep)は「事実のうち今後も維持したいもの+その解釈」です。上手くいったことを、なぜ上手くいったかという解釈とセットで記録します。P(Problem)は「事実のうち問題だったもの+その解釈(なぜ問題だったか)」です。事実だけを書かず解釈を必ず添えることで、同じ問題が繰り返されるリスクを下げます。T(Try)は「次の行動」にあたります。Pの解釈が仮説として書かれているため、Tryが感覚的な改善案ではなく仮説検証のアクションになります。たとえば「失注直後の振り返り」例文をKPT形式にすると、K「最終選考まで残れた・差は実績数にあった」、P「担当者が稟議に使える実績資料を提供できなかった・意思決定基準を初回に確認していなかった」、T「同規模・同業種の事例集を次回提案時に持参する」となります。

書いた後が勝負——例文を次商談の改善に変えるサイクル

振り返り例文を書くことは手段であり、目的ではありません。「行動」の項目に書いたことが実際に次商談で試され、その結果が次の振り返りにつながるサイクルが回らなければ、例文はただの記録として埋もれていきます。多くの振り返り例文集が「書き方」で終わっているのは、この「書いた後」の設計を扱っていないからです。振り返りを成長に変えるためには、例文を書く技術だけでなく、書いた後の仕組みが必要です。ここでは振り返りから次商談の改善へつなげる具体的な接続の方法と、記録を蓄積する意義について説明します。

振り返り→仮説→次商談設計の接続

振り返りの「行動」項目は、そのまま次商談の冒頭アジェンダに変換できます。たとえば「次回は決裁構造を確認する質問を冒頭に入れる」という行動項目があれば、次回商談の準備として「誰が最終的に意思決定しますか」という質問を1問目に設定します。「振り返りの行動項目を次商談の冒頭質問に変換する」という接続を習慣にすることで、商談1件ずつが仮説検証の機会として機能します。今回の商談で仮説が当たったか外れたかを確認することが、次の振り返りをより深くします。

※著者の体験

ネオキャリアNEXTで5C Studioというツールを設計する際、振り返りの行動項目から次商談のアジェンダを生成する機能をどう組み込むかを考えていました。商談の文字起こしから提案書を生成するパイプラインを作る中で、振り返りと次商談設計の接続がシステムの中でも自然に起きるはずだという仮説を立てていました。

実際にシステムを動かしてみると、行動項目の記録粒度によって出力が大きく変わりました。「次回は決裁構造を確認する」という粒度で書かれた記録はアジェンダに変換できましたが、「もっと丁寧にヒアリングする」では何も出てきませんでした。

ツールを作る側に回って初めて、振り返りの粒度が次商談の設計品質を直接決めるという構造が見えた気がします。紙やスプレッドシートで振り返りを書いていた頃は、接続が途切れていても気づきにくかったと思っています。

上司共有・SFA記入で「証跡」を作る意義

振り返りを上司に共有したり、SFA(営業支援システム)に入力したりすることを「義務的な作業」と感じている方は多いと思います。しかし、事実・解釈・行動の3要素で書いた振り返りは、そのままSFAの商談メモとして使えます。記録が蓄積されることで、自分がどんな商談パターンに弱いか、どの解釈の精度が上がってきたかを後から確認できます。上司への共有も単なる「報告」ではなく「仮説の壁打ち」として機能します。「この解釈は合っていますか」「このアクションで十分ですか」という問いを持って共有することで、フィードバックの質が変わります。記録が蓄積されることで、自分の成長パターンが可視化されていきます。

振り返りが続かない3つのパターン

振り返りが長続きしない原因は、意志の問題ではなくフォーマットや運用の設計にあることがほとんどです。よく見られるパターンは3つあります。1つ目は「時間がかかりすぎる」です。商談ごとに長い振り返りを書こうとすると、商談数が増えるほど振り返りが滞ります。商談直後に事実だけをメモし、解釈・行動は移動中や翌朝に補足する分割方式が有効です。2つ目は「書いた後に活かせない」です。これは前の章で示した「行動→次商談アジェンダへの変換」が抜けていることが主な原因です。3つ目は「ネガティブな振り返りが苦痛」です。失注や停滞した商談を振り返るのは精神的に負荷がかかります。事実ベースで書くことを徹底し、「自分の能力の問題」ではなく「仮説が外れた」という視点で記録するだけで、苦痛は軽減されます。

そもそも「商談の振り返り」は何のためにするのか(パートB)

振り返りの目的として「成長のため」「次回改善のため」と答える方は多いです。それは間違いではありませんが、少し抽象的すぎます。もう少し解像度を上げると、商談の振り返りは「仮説の検証サイクルを回すこと」だと言えます。1回の商談は1回の実験です。商談前に「この顧客には、この問いかけをすれば、こういう反応が返ってくるはずだ」という仮説があり、商談後にその仮説が当たったか外れたかを確認します。それが振り返りの本質です。

この視点に立つと、例文を書くこと自体が目的化するリスクが見えてきます。フォーマットを埋めること、SFAを更新すること、上司に報告することは、すべて仮説検証サイクルを回すための手段です。振り返りの質を上げるためには、商談後だけでなく商談前の仮説設定が必要です。仮説がなければ「何を検証したのか」がわからないまま例文を書くことになります。「次の商談で確かめたいことは何か」を先に考える習慣をつけることが、振り返りの実効性を高める最初のステップです。

振り返りを「書く習慣」として整えようとするとき、「丁寧に書くこと」自体が目的に変わっていく瞬間があります。3要素の枠を丁寧に埋めるほど、振り返りの完成度は上がります。しかし、完成度が高い振り返りが「有効な振り返り」と同じかどうかは、別の問いかもしれません。事後の記録の精度よりも、商談前に立てた仮説の解像度の方が、振り返りの深さを先に決めているという見方もできます。仮説が曖昧であれば、どれほど丁寧に書いても、記録は「起きたことの整理」で止まります。振り返りの質を高めたければ、書き方の技術と同時に、商談前の問いの立て方を並走させる必要があります。例文の型を知ることは出発点です。その先に「商談前の問いをいかに解像度高く立てるか」という問いを置き続けることが、振り返りを実力に変えていく構造です。

あわせて読みたい

筆者:店長

営業と、競馬と、しゃべる植物。あっAIも。つい、いろいろ作ってしまう人です。

→ 店長の正体(詳しいプロフィール)

店長

Xアカウント:@nishi_sales_ai 新卒で大手の人材・情報サービス系の会社に入社し、飛び込み営業から深耕営業、大手企業担当まで第一線で経験を積む(表彰歴多数)。その後、事業企画・営業企画部門で経営に近い立場から営業組織と数字に向き合い、10年勤続を経て独立。営業組織の改善に特化したコンサルタント企業を立ち上げる。 コンサルタントして数々の現場に入りつつ、自ら営業特化の転職エージェントも運営。近年はAIを活用した営業組織の業務改善・生産性向上プロジェクトに携わる。現在は、自分たちで作った法人向けゲーミフィケーションサービス「Game toB」と営業向けSFA「商談ノート」を提供しながら、その公式メディアである当サイトで、営業と組織づくりの実践知を発信している。

この著者の記事一覧

\ 最新情報をチェック /

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です