CRM(HubSpot_Salesforce)を導入したのに営業が使わない:導入後に詰まる7つの設計不足

CRM(HubSpot/Salesforce)を導入したのに営業が使わない:導入後に詰まる7つの設計不足

この記事の要約

HubSpotやSalesforceを導入したのに、商談やタスクの入力が続かず、気づけば個人の手帳やExcelに逆戻りしている――。

この記事は、その原因を「営業の意識が低いから」ではなく「導入後の設計不足」として整理します。具体的には、①入力目的の未定義、②入力負荷と営業活動の不一致、③運用ルールの空白、④現場フィードバックの経路欠如、⑤マネージャーの活用不在、⑥データが返ってこない構造、⑦定着の責任者不在という7つの設計不足に分解します。

全体像を先に押さえたうえで、それぞれがなぜ入力放棄につながるのかを仮想例つきで解説し、読み終える頃には自社のCRM運用をどこから点検すればよいか、優先順位をつけて判断できる状態を目指します。

この記事でわかること

  • CRMが定着しない原因を「現場の怠慢」ではなく「設計不足」として捉え直す視点
  • 導入後につまずきやすい7つの設計不足の全体像と相互関係
  • HubSpotやSalesforceを問わず共通して起きる入力放棄のメカニズム
  • 自社のCRM運用をどこから点検すべきかの優先順位のつけ方
  • 定着を仕組みとして支える体制づくりの考え方

はじめに

「せっかく高い費用をかけてCRMを導入したのに、いつの間にか営業が入力しなくなっている」。CRM責任者であれば、一度はこうした状況に直面したことがあるのではないでしょうか。導入直後は研修も行い、ダッシュボードも整えたはずなのに、数か月経つと商談情報が古いまま止まっている。管理側は「営業のリテラシーの問題」と結論づけがちですが、それは本当に現場の意識だけの話でしょうか。実は、多くの場合その裏には、導入後の設計段階で見落とされてきた構造的な不足があります。

CRMを導入したのに営業が使わないという現象は、業界を問わず繰り返し起きています。HubSpotやSalesforceのようなプラットフォーム自体の機能は年々強化されていますが、それでも定着しない企業は後を絶ちません。ここで一度立ち止まって考えるべきは、「なぜ入力しないのか」ではなく「なぜ入力し続けられる設計になっていないのか」という問いです。

結論:営業が使わないのは「7つの設計不足」が重なっているから

まず結論から述べます。CRMが定着しない状態は、単一の原因ではなく、導入後に見落とされがちな7つの設計不足が積み重なって生まれます。順番に並べると次のとおりです。

  1. 入力目的の未定義:何のために入力するのかが営業本人に伝わっていない
  2. 入力負荷と営業活動の不一致:営業の実際の動き方とCRMの入力項目が噛み合っていない
  3. 運用ルールの空白:いつ・誰が・何を入力するのかのルールが明文化されていない
  4. 現場フィードバックの経路欠如:入力しても現場に何も返ってこない、意見も届かない
  5. マネージャーの活用不在:管理職自身がCRMを見て動いていない
  6. データが返ってこない構造:入力した情報が営業本人の役に立つ形で還元されない
  7. 定着の責任者不在:導入後の運用を継続的に見る担当が決まっていない

これらは独立した問題ではなく、連鎖しています。例えば「入力目的が不明」なまま「運用ルールも空白」だと、営業は自己判断で入力の要否を決めるようになり、結果として「マネージャーも使っていない」状態を招きます。

つまり、点検すべき順序は上から下へ、目的→負荷→ルール→フィードバック→マネジメント→データ還元→責任体制という流れで見ていくのが合理的です。以下、それぞれを具体的に見ていきます。

設計不足1:入力目的の未定義という土台の欠落

「何のために入力するか」が営業に伝わっていない

CRM導入プロジェクトでは、要件定義や項目設計に時間をかける一方で、「この項目は何のために営業が入力するのか」という説明が現場まで届いていないケースが目立ちます。管理側にとっては「案件の可視化のため」「予測精度を上げるため」と自明に見えても、日々の商談をこなす営業担当者からすれば、入力そのものが目的化した作業に見えてしまうのです。

例えば、ある仮想の製造業向けSaaS企業では、HubSpotの導入時に商談ステージや確度スコアを細かく設定しましたが、営業向けの説明は「入力してください」という一枚のマニュアル配布だけで終わっていました。結果として、営業は「上司に見られるための作業」だと受け取り、後回しにするようになった、という状況が起こり得ます。

目的の未定義が招く三つの連鎖

目的が不明確なまま運用が始まると、次のような連鎖が起きやすくなります。

段階起きやすい現象
初期「なぜこの項目が必要か」を営業が理解できず、入力の優先度が下がる
中期入力の質がばらつき、同じ案件でも担当者ごとにステージの解釈が違う
後期データの信頼性が下がり、マネージャーもCRMを見なくなる

この連鎖を断ち切るには、項目ごとに「誰が」「何のために」「どう使うか」を一文で説明できる状態を、導入後にあらためて整理し直すことが出発点になります。

CRMを売上を生む仕組みとして再設計する全体像は、次の記事で確認できます。

HubSpotを売上を生む仕組みとして設計し直す:診断から90日まで
HubSpot責任者・CMO向けに、顧客名簿化したHubSpotを定義・データ・運用・レポートの4視点で診断し、90日の実行順序で再設計する考え方を解説します。

設計不足2:入力負荷と営業活動の不一致

営業の動き方とCRMの項目設計がずれている

CRMの入力項目は、往々にして管理側が欲しい情報を優先して設計されます。しかし、営業担当者が商談中に確認できる情報と、事後に思い出しながら埋める情報とでは、負荷がまったく異なります。訪問直後にスマートフォンから入力できない項目、選択肢が多すぎるプルダウン、必須項目が多すぎる商談登録画面――こうした細部の積み重ねが、営業にとっての「入力コスト」を押し上げていきます。

具体的には、以下のような不一致がよく見られます。

  • 入力タイミングの不一致:商談直後ではなく週次報告のタイミングでまとめて入力させる設計になっている
  • 項目粒度の不一致:営業が把握していない社内情報(発注プロセスの内部承認状況など)まで入力を求めている
  • デバイスの不一致:外回りが多い営業でも、入力は社内PCからしかできない画面設計になっている

負荷を点検するためのチェック観点

自社の入力負荷が過大になっていないかを点検する際は、次の観点で確認すると整理しやすくなります。

  • 商談後5分以内に、スマートフォンから完結できる入力になっているか
  • 必須項目が営業自身の記憶だけで埋められる内容か
  • 入力にかかる時間が、1商談あたり数分程度に収まっているか
  • 選択肢の数が、直感的に選べる程度(目安として5〜7個程度)に収まっているか

負荷が高い設計のまま「もっと丁寧に入力してほしい」と依頼しても、現場の行動は変わりません。むしろ入力項目を減らし、営業の動線に合わせて再設計するほうが、定着への近道になります。

設計不足3:運用ルールの空白が生む「なんとなく運用」

導入時に業務フローを整理しても、運用開始後にルールが更新されないまま放置される企業は少なくありません。「いつまでに入力するのか」「誰がステージを更新する権限を持つのか」「案件がクローズしたら誰が最終確認するのか」――こうした運用ルールが明文化されていないと、現場は各自の解釈で動くようになります。

とくに問題になりやすいのが、複数の営業やチームが同じ商談に関わるケースです。役割分担のルールが曖昧なままだと、「自分が入力しなくても誰かが入力するだろう」という心理が働きやすくなります。これは個人の怠慢というより、責任の所在を決めていない運用設計の不足と捉えるべきです。運用ルールは一度作って終わりではなく、組織変更や商談プロセスの変化に合わせて定期的に見直す前提で設計しておく必要があります。

入力ルールとデータ品質を是正する優先順位は、次の記事で整理しています。

HubSpot/Salesforceのデータ品質が悪化する原因と、最初の是正順序
HubSpot/Salesforceのデータ品質悪化を入力・定義・運用・重複・連携の原因に分解し、Sales Ops/IT向けに最初の是正順序と判断基準を解説します。

設計不足4:現場フィードバックの経路欠如

入力した情報がどう使われているのか、営業本人に一切フィードバックがない状態も、定着を妨げる大きな要因です。人は、自分の行動が何らかの結果につながっていると実感できて初めて、その行動を継続しやすくなります。CRMへの入力も同様で、「入力したデータがレポートに反映され、経営会議で使われている」という手応えがなければ、単なる作業として処理されてしまいます。

さらに、現場から「この項目は使いにくい」「この選択肢では実態を表せない」といった声を吸い上げる経路がないことも見過ごされがちです。現場の声が届かないまま項目だけが増え続けると、CRMは「管理側が一方的に要求するツール」という印象を強めてしまいます。定期的に営業からの改善提案を受け付ける場を設け、実際に項目を見直した実績を示すことが、信頼回復の第一歩になります。

設計不足5:マネージャー自身がCRMを活用していない

「上司が見ていないもの」を部下は使わない

営業組織において、マネージャーの行動は現場に強い影響を与えます。もしマネージャーが1on1や週次会議でCRMの画面を開かず、口頭報告だけで商談状況を確認しているなら、部下にとってCRMは「入力する意味の薄いツール」に見えてしまいます。

逆に、マネージャーが日常的にCRMを開き、「このステージの根拠は?」「この確度の数字はどこから来ている?」と具体的に問いかける文化があれば、入力の精度は自然と上がっていきます。

活用度を測る簡易チェック

自社のマネージャー層がCRMをどの程度活用できているか、次の簡易チェックで確認できます。

  • 1on1でCRMの商談画面を開きながら会話しているか
  • 週次の営業会議で、口頭報告ではなくCRMのレポートを起点に進行しているか
  • マネージャー自身が案件のステージ更新やメモ入力を行っているか

このいずれかが「いいえ」であれば、マネジメント層の活用不在が定着を阻んでいる可能性を疑うべきです。

設計不足6:データが営業本人に還元されない構造

入力は「一方通行」になっていないか

営業が入力する情報は、多くの場合、経営層やマーケティング部門のレポート作成に使われます。しかし、営業本人にとって「自分の入力が自分の仕事を楽にする」形で還元されていなければ、入力は単なる義務作業にとどまります。例えば、過去の類似案件の勝率データや、失注理由の傾向がCRMから簡単に引き出せて、次の提案づくりに役立つとしたら、営業自身が積極的にデータを蓄積する動機が生まれます。

具体的には、次のような還元の形が考えられます。

  • 類似業種・類似規模の過去商談を検索し、提案の参考にできる仕組み
  • 自分の担当案件の進捗を、上司への報告なしに可視化できるレポート機能
  • 失注理由の傾向を集計し、次の商談での注意点として提示する仕組み

こうした還元がないまま「データを入れてほしい」と求め続けても、営業からすれば「自分には得のない作業」に映ってしまいます。

設計不足7:定着を継続的に見る責任者の不在

最後に、そして最も見落とされやすいのが、導入後の運用を継続的に見る責任者が決まっていないという問題です。CRMの導入プロジェクトには推進担当がいても、稼働後の「定着フェーズ」を誰が担うのかが曖昧なまま放置される企業は少なくありません。

導入直後は熱量が高くても、半年、一年と経つうちに担当者が異動し、気づけば誰も入力状況を点検していない――という状態に陥りやすくなります。

定着を仕組みとして維持するには、月次で入力率や更新頻度を確認し、現場の声を拾い、必要に応じて項目やルールを見直す役割を、特定の個人ではなく「機能」として組織内に位置づけておくことが有効です。担当者が変わっても引き継げるよう、点検の頻度や確認項目をあらかじめ定めておくことが、長期的な定着の土台になります。

まとめ

CRMを導入したのに営業が使わないという状態は、現場の意識の問題として片づけられがちですが、実際には導入後の設計不足が積み重なった結果であることがほとんどです。入力目的の未定義から始まり、入力負荷と活動の不一致、運用ルールの空白、フィードバック経路の欠如、マネージャーの活用不在、データ還元の欠如、そして定着責任者の不在まで、7つの設計不足は互いに連鎖しています。

自社の状況を点検する際は、目的の明確化という土台から順に確認し、どこで連鎖が断たれているのかを見極めることが、再設計の第一歩になります。

Q&A

Q
CRMの定着率を測る際、まず何を確認すればよいですか?
A

入力の有無だけでなく、いつ・誰が・どの項目を入力しているかの頻度と精度を確認することが出発点になります。単純な入力率だけを見ると、実態とずれた評価になりやすい点に注意が必要です。

Q
営業への研修を増やせば定着率は上がりますか?
A

研修だけでは根本的な解決にならないことが多いです。入力目的や項目設計、運用ルールといった構造面の不足が残っていれば、研修効果は一時的なものにとどまりやすくなります。

Q
HubSpotとSalesforceで、定着のしやすさに違いはありますか?
A

どちらのプラットフォームを使っていても、定着の可否は機能そのものよりも導入後の運用設計に左右される傾向があります。ツールの選定以上に、この記事で挙げた設計不足の有無を点検することが重要です。

専門用語解説

  • CRM:顧客との商談履歴や連絡先情報を一元管理するためのシステム
  • RevOps:マーケティング・営業・カスタマーサクセスの業務プロセスを横断して整える専門機能
  • 商談ステージ:見込み客が受注に至るまでの進捗段階を区分したもの
  • 確度スコア:商談が受注に至る可能性の高さを数値や段階で示した指標
  • 失注理由:商談が成約に至らなかった際の原因を分類した情報
この記事の執筆・監修者
Kazuhiko Nishikawa

GTM Engineer / BizOps / RevOps。Web制作・UI/UXを10年経験。BtoB・BtoCマーケティング、CRM/MA設計、プロダクト開発、Webディレクション/デザイン、CSを横断した事業改善に従事。外国人材ベンチャーでBtoBマーケティングを0→1で立ち上げ、リード獲得と営業支援を中心に収益プロセスを改善。HubSpot、AI、CRM、データを活用した業務設計・自動化・分析・制作を経験。

本記事は、BtoBマーケティング、HubSpotの導入・運用、CRM設計、営業・マーケティング連携に携わってきた実務経験をもとに、現場で実際に感じた課題や判断、起こりうるパターンを整理・想定し、AIライティングにて執筆・編集、監修者によるリライトを行なっています。
CRMHubSpotRevOpsSalesforce営業DX