商談管理エクセル無料テンプレートの選び方と運用設計

商談管理にエクセルを使うメリットと向いているケース

エクセル(またはGoogleスプレッドシート)で商談を管理することには、シンプルで実用的な強みがあります。導入コストがゼロで今日からすぐ始められ、自社の業種・営業フローに合わせた列の追加・削除が自由にできます。社内に既存のPC環境があれば、追加の投資は不要です。

エクセル管理が向いているのは、月間商談数がおよそ50件以下、チームが3名以下、かつCRMやSFAの本格導入をまだ検討していない段階です。この条件に当てはまる場合、エクセルで十分に管理が回ります。「CRMにすべきかどうか」という判断基準は、後半で改めて扱います。

商談管理テンプレートの基本構造と必須項目

テンプレートを選んだり作ったりするとき、「どの項目を入れるべきか」で迷いがちです。市販・配布のテンプレートの多くは20列以上を持っており、そのまま全列を埋めようとすると入力負荷が上がり、続けられなくなります。ここでは最低限必要な8項目と、業態によって追加する項目を整理します。「まず8項目で動かす」というスタンスが、継続率を高める出発点です。

最低限入れる8項目

商談管理が機能するために最低限必要な項目は、案件名・顧客名・担当者・商談日・次回アクション・期待受注額・ステータス・備考の8つです。この8項目が揃っていれば、「今どの案件がどの状態にあり、次に何をするか」を全員が把握できます。逆にいずれかが欠けると商談管理の基本機能が揺らぎます。たとえば「次回アクション」がなければフォローが抜け落ちますし、「ステータス」がなければ進捗が見えなくなります。「全部入れなくていい」というメッセージをここで明確にしておくのは、全列入力を前提にすると続かなくなるためです。不要な列を削るか非表示にするかという具体的な手順は、後半のカスタマイズのセクションで扱います。

業態・規模別の追加項目

法人向けで複数のステークホルダーが関わる商談では、「決裁者」と「窓口担当者」を区別する列が必要になります。窓口が話を進めていても最終承認は別の人物が行うケースでは、両者の情報を分けておかないと提案の歯車が噛み合わなくなります。受注確度をABC判定で入力する列は案件の優先順位づけに役立ちます。商談経緯メモ列は、担当者が変わったときや間が空いた案件を再起動するときに特に力を発揮します。ただしこれらは必要な業態・規模のチームだけが足せばよく、全員が最初から入れるべきものではありません。「自社に本当に必要かどうか」を判断してから追加する順序が大切です。

無料テンプレートを選ぶ3つの確認ポイント

ネット上には多くの無料テンプレートが配布されていますが、「どれをダウンロードすればよいか」の選択基準を示しているページはほぼありません。ダウンロードリンクが並んでいるだけでは、どれを選んでも同じように見えてしまいます。実際には選び方を誤ると、ダウンロード後に「自社に合わない」と気づいて作業をやり直すことになります。テンプレートを選ぶとき、次の3点を確認しておくことでその無駄を省けます。

① 項目数が多すぎないか

列数が多いほど1件の入力にかかる時間が増えます。1件の入力が2分以内に収まる項目数かどうかを確認してください。2分を超えると「後でまとめて入力しよう」という先送りが習慣化し、管理台帳が空白だらけになります。

② ステータス欄を自社フェーズに合わせられるか

汎用テンプレートのステータスは「初回接触・提案・見積・受注/失注」のような一般区分になっています。自社の営業プロセスと一致しているか、またはカスタマイズできる形式かどうかを確認してください。変更の手順は後述のカスタマイズのセクションで扱います。

③ チームで共有・同時編集できる形式か

ローカル保存のExcelファイルを複数人で使い回す運用は、バージョン違いや上書き事故が起きやすいです。チームで使う場合は、Googleスプレッドシートや、OneDrive上での共同編集が可能な形式を選ぶことで、この問題を回避できます。

テンプレートを自社向けにカスタマイズする手順

配布されているテンプレートはそのまま使える前提で作られていますが、実際には自社の業種・フロー・チーム規模に合わせた手直しが必要です。競合サイトの多くは「ダウンロードしてご使用ください」で終わっており、どの列を削るか・ステージをどう書き換えるかという具体的な判断手順がないため、受け取った側が迷います。このセクションでは、カスタマイズを「削る列の判断」と「自社ステージの定義」という2ステップに分けて解説します。この2ステップを完了したテンプレートが、実際に継続して使えるツールになります。

営業組織の支援に入るとき、私はまず商談管理のファイルを見せてもらいます。あるとき20列以上ある共有ファイルを開いて、実際に埋まっている列と空欄の列を数えてみました。機能しているのは8列か9列で、残りはほぼ空欄のままでした。

どこから手をつければいいかをチームに聞くと、「列が多すぎて、毎回どこを見ればいいかわからなくなる」という声が出ました。入力負荷というより、列が多いこと自体が「ファイルを開くこと」のハードルになっている、という印象に近かったです。

最初の数件の支援では、私も全列を生かす方向で調整しようとしていました。うまくいった記憶はあまりありません。「どこを削るか」より先に、「全列入れようとしていたこと自体」が問題だったと後から気づいた気がします。

削る列の判断基準——入力負荷を半分にする

カスタマイズの第一歩は列を削ることです。ただし削除ではなく「非表示」にすることを推奨します。非表示であれば後から必要になったときに復元できます。削るかどうかの判断基準は一つに絞ることが大切です。「週次で更新するとき、この列を埋めるのに10秒以上かかるか」——この問いにYesと答えた列は非表示にする候補です。残す列の上限は10列以内を目安にしてください。列を減らすことへの抵抗感として「情報が減る」という懸念が出ますが、入力されない列に格納された情報量はゼロです。10列に絞り込んで全件入力が続く状態のほうが、20列あって半分が空欄の状態より圧倒的に価値があります。先に示した8項目から始め、運用しながら本当に必要な列を足していく順序が、継続率を高める近道です。

自社の商談ステージを定義する

汎用テンプレートのステータス欄(例:「初回接触→提案→見積→受注/失注」)を自社のフェーズに置き換えるとき、3つの原則を守るとステージ定義が機能しやすくなります。第一に「境界が明確であること」——ある案件が「提案」と「見積」のどちらに属するか、誰でも迷わず判断できる状態を作ります。第二に「誰でも判断できること」——営業担当が変わっても、ステータスの判断が変わらないよう定義します。第三に「4〜6段階に収めること」——ステージが多すぎると入力時の判断に時間がかかり、更新頻度が落ちます。ステージの境界が曖昧なままだと、進捗管理が形骸化します。「なんとなく進んでいる」という状態ではフォローの優先順位がつけられず、重要案件が先送りされるリスクが高まります。自社のフェーズ定義をチーム内で確定しておくと、テンプレートの継続率と商談管理の精度が同時に上がります。

「続かない」失敗パターン3つとその原因

テンプレートを導入したのに数週間後には更新が止まっていた、という経験を持つ方は少なくありません。「続かない」のは意識や習慣の問題ではなく、テンプレート設計と運用体制に構造的な原因があります。失敗パターンは3つに整理できます。①項目が多すぎて入力が面倒になる、②誰がいつ更新するかが決まっていない、③テンプレートの置き場や共有方法が整備されておらずアクセス自体が負担になる——という3つです。このうち特に再発性が高く構造的な影響が大きい①と②を、次の節で詳しく解説します。

転職支援を始めた最初の1年ほど、私は候補者のメモをExcelにまとめていました。面談内容と次の連絡タイミングを書くだけのシンプルなものでしたが、最初の数十件は問題なく動いていました。

件数が増えてくると、「後でまとめて書こう」が出てきました。1日に何件か面談が重なると、夜になってから記憶が混ざることがあります。書ける分は書いていましたが、メモが濃い候補者と薄い候補者の差が広がっていく一方でした。

当時は「忙しかったから仕方ない」と思っていました。入力のタイミングを意識的に固定してからメモの密度が変わったので、忙しさより「いつ書くかが決まっていなかったこと」が原因だったのかもしれません。ただ、そのことに気づくのにしばらくかかりました。

項目が多すぎて入力が面倒になる

配布されているテンプレートのほとんどは「全部入り」で設計されています。全列を埋めようとすると1件の入力時間が大幅に伸び、「後でまとめて入力しよう」という先送りが起きます。先送りが数日続くと入力すべき件数が積み上がり、「追いつかない」という感覚から入力をやめてしまうパターンに陥ります。失敗の構造として理解しておくべきなのは、「入力が途絶えた原因はやる気の問題ではなく、1件あたりの入力コストが高すぎたことだ」という点です。前セクションで扱ったカスタマイズが、この失敗パターンへの直接的な解決策です。

「誰がいつ更新するか」が決まっていない

テンプレートはフォームであり、それ自体は仕組みではありません。「このファイルで商談を管理しよう」という合意だけでは、誰がいつ更新するかが決まっていないため、更新の責任が曖昧になります。複数人のチームでは「誰かがやっているだろう」という前提のもとで全員が更新を後回しにする状態が起きやすくなります。一人の営業担当であっても、更新タイミングを決めていないと「気が向いたとき」という運用になり、1ヶ月後には空欄だらけになります。この失敗パターンの解決策は、後述の運用ルールの設計です。「誰が・いつ・どの頻度で」を明示的に決めることが、テンプレートを生きた管理ツールに変える唯一の手段です。

商談管理ツールが機能しなくなる原因を、多くの記事はテンプレートの選択に帰します。しかし同じテンプレートを導入しても、継続できる組織とできない組織の差は、ツール選びよりも前の段階で生まれていることが多いです。

道具は、使い続けるための決まり事とセットにならないと機能しません。「このファイルで管理しよう」という合意は入口であって、「誰が・いつ・どの基準で更新するか」を決めた時点で初めて、ツールは仕組みになります。テンプレートを変えても定着しない場合は、ツールを変えているのであって仕組みを変えていない——という見方をすると、次にとるべき一手が変わってくるかもしれません。

テンプレートを定着させる運用ルール設計

テンプレートは入手した瞬間に価値を持つわけではありません。継続的に更新され、チームで参照され続けて初めて、商談管理の道具として機能し始めます。前セクションで確認した「続かない」失敗パターンのうち、「入力が面倒すぎる」は前述のカスタマイズで対処できます。もう一方の「誰がいつ更新するかが決まっていない」は、運用ルールを設計することで解消できます。このセクションでは、入力タイミングの決め方とレビューサイクルの組み方という2つの具体的なルール設計を説明します。

入力タイミングの決め方(商談直後 vs 日次バッチ)

入力タイミングには大きく2つのパターンがあります。商談直後にその場で入力する「その場入力」と、1日の終わりにまとめて入力する「バッチ入力」です。その場入力は記憶が鮮明なうちに入力できるため、メモの精度が高くなります。一方、商談直後は次の行動(移動・準備・連絡)が続くことが多く、入力の時間を確保しにくい場面もあります。バッチ入力は効率よくまとめて処理できますが、複数の商談が重なると記憶が混在するリスクがあります。どちらが優れているかという議論よりも、「ルールを決めること」が最重要です。推奨するのは「商談から30分以内に入力する」という具体的な基準をチームで決め、カレンダーや行動習慣に組み込むことです。

週次・月次レビューサイクルの設計

入力ルールと並んで重要なのが、定期的な見直しのサイクルです。推奨するのは週次と月次の2段階です。週次レビューでは各案件のステータスが正しく更新されているかを確認します。所要時間の目安は5分程度で、ステータスの漏れや次回アクションの未入力を拾うことが目的です。月次レビューでは受注確度の見直しとフォーキャスト(見込み受注額)の精査を行います。所要時間の目安は15分程度で、停滞案件の判断や優先順位の見直しが主な作業です。このサイクルを定着させるための最も実用的な手段は、カレンダーに週次・月次のレビュー予定を繰り返しの予定として入れることです。「時間が空いたときに見る」という運用では、繁忙期にレビューが飛んで管理が形骸化します。

エクセル管理が限界になるサインとCRM移行の判断基準

エクセルでの商談管理が「合わなくなった」と感じるタイミングは、いくつかの共通サインとして現れます。①月間商談数が50件を超えてきた、②3名以上のチームで同じファイルを編集する際に上書き衝突が頻繁に起きる、③「あの案件、いつ誰と何を話したか」という過去商談の検索ニーズが増えてきた——この3つのサインが重なったタイミングが、CRMやSFAの検討を始める目安です。ただし、この記事を読んでいる方の多くは、まだエクセルで十分な段階にいます。ツールを変えることに投資するよりも、今のエクセル管理を「続けられる状態」に整えることが先決です。

よくある疑問Q&A

テンプレートの導入や運用にあたって、よく寄せられる疑問を3つ取り上げます。「Googleスプレッドシートで代替できるか」「マクロや関数の知識が必要か」「商談件数が少なくても使うべきか」という3点は、多くの方が導入前や使い始めに気になる共通の疑問です。本文を読み終えた後でも、実際に手を動かし始めると細かい疑問が出てくることがあります。このセクションはそうした疑問を先回りして解消し、スムーズに使い始めるためのものです。

Q. Googleスプレッドシートでエクセルのテンプレートを代替できますか?

できます。むしろ複数人での共有・同時編集についてはGoogleスプレッドシートの方が優れています。URLを共有するだけで全員が同じデータを参照でき、ファイルのバージョン管理が不要です。エクセル形式のテンプレートをGoogleスプレッドシートにインポートして使うことも可能です。

Q. マクロや複雑な関数は必要ですか?

必要ありません。DATEDIFやIFなどの基本的な関数で十分に機能します。複雑な関数やマクロは、担当者が変わったときのメンテナンス負荷を高め、運用の障壁になります。シンプルな設計を維持することが長期的な継続につながります。

Q. 商談件数が少なくてもテンプレートは必要ですか?

5件以下であれば、メモやメールの管理で事足りる場合があります。しかし10件を超えたタイミングで導入しておくと、件数が増えたときの移行コストがかかりません。早い段階で管理の型を作っておくことは、後で楽になるための投資です。

あわせて読みたい

筆者:店長

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

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

店長

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

この著者の記事一覧

\ 最新情報をチェック /

コメントを残す

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