既存顧客の引き合い管理がCRMから漏れる理由｜見込み客は動くのに商談だけ止まる構造と対策

引き合い管理とは、お客様からの問い合わせや相談（引き合い）を受けた時点で記録し、受注まで追えるようにすることです。CRMで引き合い管理をしていても、見込み客や連絡先など入口側のデータは毎日のように更新されているのに、商談（受注に向けて進めている案件）のデータだけが何週間も更新されない、という状態が起こります。CRM全体が使われていない状態とは違い、一部はきちんと回っているため、問題に気づきにくいのが特徴です。

この記事では、私たちが支援している中小の金属表面処理加工業で実際に起きたこの状態を、事例として紹介します。ログを調べて分かったこと、現場と話して分かった本当の原因、そして合意した対策までを順に書きます。CRMがまったく使われていない場合の立て直しは、別の論点になります。この記事は、その立て直しが進んだ後に出てくる「一部だけ止まる」問題を扱います。

何が起きていたのか？

この支援先では、以前はほとんど使われていなかったCRMを、運用手順書と週次の定例で立て直してきました。見込み客の判定や会社情報の入力は担当者が決まり、日々の運用として回るようになっていました。

そこで、定例の議題に入る前に、CRMが実際にどう使われているかを更新履歴（ログ）から確かめました。調べ方は単純です。直近30日に更新されたレコードを、モジュールごと・更新した人ごとに数えます。そのとき、一括処理でまとめて更新されたデータ（同じ秒に数十件が更新されているもの）は、人の操作ではないので数から外します。

結果は、モジュールによってはっきり分かれました（2026年7月時点、直近30日）。

モジュール	直近30日の動き	状態
見込み客	数百件規模の更新と、百件前後の新規登録があった。担当者がほぼ毎日操作	日々の運用として回っている
商談	更新ゼロ。最後の更新は1か月以上前	止まっている

入口は毎日動いているのに、その先の商談は1か月以上誰も触っていない。数字だけを見ると「見込み客を商談に上げる作業が抜けている」ように見えます。私たちも最初はそう考えました。

最初の仮説は外れていた

定例でこの結果を共有し、「見込み客の中に、本当は商談に上げるべき案件が残っていませんか」と確認しました。答えは、上げ漏れはない、というものでした。見込み客の多くはまだ商談にするほど話が進んでおらず、Web経由で来た案件に限れば、商談の数は実態どおりだったのです。

ここで経営者から、別の角度の指摘がありました。要旨は次のとおりです。

• いまCRMに入っているのは、Webサイト経由で来て商談につながった案件だけではないか
• 既存のお客様から、久しぶりに新しい案件で相談したいという引き合いが、ちらほら来ている
• それをCRMに登録するルールが、まだない

つまり、商談が止まって見えた原因は、見込み客から商談への「上げ漏れ」ではありませんでした。Web以外の経路で来た引き合いが、そもそもCRMに入る入口を持っていなかったのです。

なぜWeb経由の引き合いだけがCRMに入るのか？

この構造は、CRMを丁寧に導入した会社ほど起きやすいと私たちは考えています。理由は、導入時に作る「自動で入る仕組み」が、経路ごとの差を生むからです。

多くの会社は、CRMの導入時にWebサイトの問い合わせフォームをCRMにつなぎます。フォームから送られた内容は見込み客として自動で登録され、担当者に通知が飛びます。この支援先でも、Web経由の問い合わせは自然に見込み客として上がり、それを更新していく流れが手順書にまとまっていました。見込み客が毎日動いていたのは、この流れがきちんと機能していた証拠です。

一方、既存顧客からの相談は、まったく違う経路をたどります。

• 担当者や製造現場の責任者に、電話や来社のついでに口頭で相談が来る
• その内容は社内の会議で報告され、対応が話し合われる
• しかし「CRMに登録する」という作業は、どの場面にも組み込まれていない

報告は上がっているので、社内では案件として認識されています。ただ、CRMの上には存在しません。CRMから見ると、Web経由の新規の問い合わせだけが「案件」で、既存顧客からの相談は見えないままになります。

製造業のBtoB取引では、売上の多くを既存顧客との取引が占めることが珍しくありません。その既存顧客から来る新しい相談がCRMに入らないと、商談の一覧は「売上の大きな部分を映していない一覧」になります。売上予測や受注率をCRMで見ようとしても、肝心の部分が欠けた数字になってしまいます。

自社のCRMが同じ状態か見分けるには？

次の4つを確認すると、同じ構造かどうかが分かります。

1. モジュール別の最終更新日を並べる：見込み客・商談・取引先など、モジュールごとに直近30日の更新件数と、最後に更新された日を出します。片方だけが動いていれば要注意です。
2. 更新した人を見る：動いているモジュールを更新しているのが特定の1〜2名だけなら、その人が担っている経路しか入っていない可能性があります。
3. 入口の経路を数える：商談や見込み客の「流入元」「リードソース」などの項目を集計し、Web以外の経路（既存顧客、紹介、展示会、電話など）がほとんどゼロになっていないかを見ます。
4. 会議の話題と突き合わせる：直近の営業会議の議事録から案件を数件選び、CRMに商談として入っているかを確かめます。会議では話されているのにCRMにない案件があれば、入口が欠けています。

4つ目がいちばん確実です。ログの数字は「何が入っているか」しか教えてくれません。「何が入っていないか」は、CRMの外にある記録と照らし合わせて初めて分かります。

更新履歴を使った診断の手順そのものは、CRMの更新履歴で定着を診断する方法で詳しく解説しています。

合意した対策：既存の会議の議事録に1行足す

この支援先で合意した対策は、驚くほど小さなものでした。

毎週の現場責任者の会議の議事録に、「CRMに登録済みか」の確認欄を1行追加する。

この会議では、すでに最近の営業の進み具合が報告されていました。お客様のどこで問題が起きているか、来社の予定があるか、といった最新の情報が集まる場です。そこに確認欄が1行あれば、報告された案件のうちCRMに入っていないものがその場で分かります。結果として、会議で報告されている案件の大部分はCRMに入ると見込んでいます。

役割も決めました。確認欄の追加は、CRMの運用を担っている担当者が行います。いま登録すべき案件は営業担当が入力し、入力のしかたは運用担当が教えます。新しい会議を増やさず、新しい入力画面も作らず、すでにある報告の流れに「CRMへの橋渡し」を差し込んだ形です。

確認欄は次の定例までに作られ、会議の場で登録状況を確かめながら運用を続けることになりました。定着したかどうかは、この先の商談の更新状況で確かめていく段階です。

なぜ「ルールを作って周知する」ではないのか

「既存顧客からの相談も商談として登録すること」というルールを決めて周知する方法もあります。ただ、ルールだけでは、登録する場面が業務の中にないという問題は解けません。忙しい時期に真っ先に抜けるのは、こうした「覚えていればやる作業」です。

議事録の確認欄は、登録漏れに気づく場面を毎週の会議に固定します。漏れていても、翌週の会議で必ず見つかります。CRMが定着しない原因としてよく挙がる「週次レビューがない」への対策と、根は同じです。CRMの外で回っている会議と、CRMの中身をつなぐ場所を1つ作ることが要点です。

既存顧客の引き合いは、どこまで商談として管理すべきか？

確認欄を作るとき、もう1つ決める必要があったのが「既存顧客からの引き合いを、どこまで商談として登録するか」です。

既存顧客との取引をすべて商談にすれば、売上予測としては正確になります。しかし、毎月決まって入る注文まで1件ずつ商談にしていては、入力の負担が大きすぎます。そこで、次の線引きで整備を進めることにしました。

引き合いの種類	扱い	理由
安定して継続取引が見込める顧客からの、いつもの注文	取引先として管理し、商談は作らない	受注までの工程がなく、販売実績の取り込みで十分に追える
既存顧客からの新しい製品・新しい案件の相談	商談として登録する	見積や試作など、受注まで進める工程がある
Web・紹介・展示会などから来た新規の相談	見込み客から商談へ（従来どおり）	既存の流れがすでに回っている

具体的な線をどこに引くかは、この記事の時点ではまだ詰めている途中です。考え方としては、「みんなで受注まで持っていくための工程管理が必要か」で分けるのが分かりやすいと私たちは考えています。見積・試作・決裁といった段階を経るなら商談、決まった注文が流れてくるだけなら取引先の管理、という分け方です。

この線引きを曖昧にしたまま「全部入れてください」と頼むと、入力の負担が増えます。CRMの項目は最小限に絞るのが原則です。入れるものと入れないものを先に決めることで、入れるべきものが確実に入るようになります。

商談が止まったままだと、何が困るのか？

「Web経由の案件は回っているのだから、それでよいのでは」と考える方もいるかもしれません。私たちがこの状態を放置しないほうがよいと考える理由は3つです。

1. 売上予測がずれる：既存顧客からの新しい相談は、新規の問い合わせより受注に近いことが多い案件です。それが一覧にないと、見込みの売上を小さく見積もることになります。
2. Web施策の効果が測れない：この支援先では、Webサイトのどのページから来た問い合わせが商談・受注につながったかを追う仕組みを整えている最中でした。商談の運用が動いていないと、その仕組みを作っても数字に表れません。
3. 担当者の引き継ぎで情報が消える：口頭と会議の報告だけで回っている案件は、担当者が替わると経緯が残りません。CRMに入っていれば、誰が引き継いでもやり取りの履歴を追えます。

チェックリスト：商談の入口に穴がないか

自社のCRMで、次の項目を確認してみてください。

• 見込み客と商談の、直近30日の更新件数と最終更新日を並べて見たことがある
• 商談の入口が、Webフォーム以外にもある（既存顧客・紹介・電話など）
• 既存顧客からの新しい相談を、商談として登録する決まりがある
• その決まりを確認する場面が、毎週の会議などに組み込まれている
• 継続取引の定期的な注文を、商談にするかしないかの線が決まっている
• 会議で話題に出た案件と、CRMの商談一覧を突き合わせたことがある

チェックが付かない項目が多いほど、CRMの商談一覧は実際の営業の一部しか映していない可能性があります。

商談の入口を整えたあとの運用は、当社の受注プロセス管理の支援でも扱っています。

まとめ

見込み客は毎日動いているのに商談だけ止まっている。この状態の原因は、入力する人の怠慢ではなく、CRMに入る経路が片寄っていることにある場合があります。Webフォームとつないだ経路は自動で入りますが、既存顧客からの新しい相談は、登録する場面が業務の中にない限りCRMには入りません。

対策は大がかりな仕組みではありませんでした。すでに案件の報告が上がっている会議の議事録に、「CRMに登録済みか」の確認欄を1行足す。そして、継続取引の注文は取引先で、新しい相談は商談で、と線を引く。CRMの外で回っている会議とCRMの中身をつなぐ場所を1つ作ることが、止まった商談を動かす最初の一歩です。

自社のCRMのどこに穴があるのかを外から確かめたい場合は、受注プロセスの無料診断で現在の営業管理とCRMの使われ方をお知らせください。更新履歴を見ながら、止まっている場所と、その理由の切り分けをお手伝いします。

よくある質問

商談が更新されていないのは、営業が入力をさぼっているからではないのですか？

そうとは限りません。今回の支援先では、見込み客の担当者は毎日のようにCRMを更新していました。商談が止まって見えた理由は、Webから来た問い合わせ以外に、商談として登録する決まりがなかったことです。入力する人の意識を問う前に、どの経路の引き合いがCRMに入る設計になっているかを確かめてください。

既存顧客からの注文や相談も、すべて商談として登録すべきですか？

すべてを登録する必要はありません。安定して継続取引が見込める顧客からの定期的な注文は、取引先として管理し、商談は作らないという線引きが現実的です。一方、既存顧客からでも、新しい製品や久しぶりの別案件についての相談は、受注まで進める工程があるので商談にします。線引きの基準は、見積や試作など受注までの工程があるかどうかで考えると決めやすくなります。

会議の議事録に1行足すだけで、本当に登録されるようになりますか？

登録漏れに気づく場面が業務の中に生まれる、というのがこの方法の効き目です。案件の報告がすでに上がっている会議なら、確認欄があれば「この案件はまだCRMに入っていない」とその場で分かります。登録そのものは担当を決めて会議の後に行います。新しい会議や新しい入力画面を増やさないので、続けやすいのが利点です。定着したかどうかは、数週間後に商談の更新状況をもう一度確認して判断します。

引き合い管理と商談管理は、何が違いますか？

引き合いは、お客様から来た問い合わせや相談そのものです。商談は、そのうち見積や試作など受注に向けて進める工程に入った案件を指します。CRMでは、引き合いを見込み客として受け、受注までの工程があるものを商談に上げる、と分けて管理すると、どこで止まっているかが見えやすくなります。

自社のCRMが同じ状態かどうか、どう確かめればいいですか？

まず、見込み客・商談などモジュールごとに、直近30日の更新件数と最終更新日を並べてください。片方だけが動いていれば、入口が片寄っている可能性があります。次に、直近の営業会議で話題に出た案件を数件選び、CRMに商談として入っているかを確かめます。会議では話されているのにCRMにない案件があれば、今回と同じ構造です。