目次
- 結論
- この記事が役立つ状況
- 「営業が入力しないんだよ」は本当か
- CRM設計で最初にやるべきこと——「作らない」という判断
- データが汚れる構造的原因
- 1. 必須項目の設計ミス
- 2. 選択肢の粒度が合っていない
- 3. 入力タイミング設計の欠如
- GTMエンジニアが設計するCRMデータモデル5つの原則
- 原則1: 入力コストを最小化せよ
- 原則2: ステージ連動で段階的に必須化せよ
- 原則3: 分析ゴールから逆算してフィールドを設計せよ
- 原則4: 一つのフィールドには一つの意味だけを持たせよ
- 原則5: データの鮮度を仕組みで担保せよ
- Before/After: 失注理由フィールドの再設計
- 今日からできるCRMデータ設計チェックリスト
- データ品質は設計品質
- 参考文献
- CRMのデータが汚い原因は何ですか?
- CRMの入力率を上げるにはどうすればいいですか?
CRMのデータが汚いのは営業のせいじゃない、設計のせいだ
Salesforce・HubSpotのデータ品質問題の本質は入力する営業ではなく、設計にある。GTMエンジニアの視点からCRMデータ設計の原則を解説します。
渡邊悠介
結論
- CRMのデータが汚いのは営業の怠慢ではなく、必須項目・選択肢・入力タイミングの設計ミスが原因である
- 項目をむやみに作らず、段階的必須化と分析ゴールからの逆算でフィールドを設計することが鍵となる
- 入力コスト最小化・一意の意味・鮮度の仕組み化を含む5原則でCRMを再設計すべきだ
この記事が役立つ状況
- 対象者: 営業マネージャー / 営業企画担当 / CRM管理者 / GTMエンジニア
- 直面している課題: CRMの入力率が低くデータが汚れ、レポートが信頼できず「失注理由の60%は価格」のようなミスリーディングな数字に振り回されている
- 前提条件: Salesforce・HubSpot等のCRMが導入済みで、フィールド設計やValidation Rule・Required Propertiesを変更できる権限があること
このノウハウをAIで実行するプロンプト(クリックで開く)
以下をコピーしてLLMに貼り付け、[ ] 内を自社の情報に書き換えてください。
あなたはGTMエンジニアの視点を持つCRM設計の専門家です。
以下の前提で、私のCRMデータ設計を診断してください。
# 現状
- 利用CRM: [Salesforce / HubSpot / その他]
- 商談作成時の必須項目数: [N]個
- 主要な必須項目: [項目を列挙]
- 失注理由の選択肢: [現在の選択肢]
- 入力タイミングのルール: [現在のルール]
- データ品質の課題: [具体的な症状]
# 診断してほしい観点
1. 必須項目の設計ミス(その時点で確実にわかる情報か)
2. 選択肢の粒度(分析に使える×営業が迷わず選べる)
3. 入力タイミングが業務フローに埋め込まれているか
4. 5原則(入力コスト最小化/段階的必須化/分析ゴールから逆算/一意の意味/鮮度の仕組み化)への適合度
各観点で具体的な再設計案を提示してください。
「営業が入力しないんだよ」は本当か
CRMの定例で、こんなセリフを聞いたことはないだろうか。
「営業がちゃんと入力してくれない」「データが汚くてレポートが出せない」「入力率が50%を切っている」。
営業マネージャーは営業担当を責め、経営層はマネージャーに「入力を徹底させろ」と指示を出す。入力率向上施策が走り、朝会で入力チェックが始まり、未入力者リストが共有される。
だが、冷静に考えてほしい。営業は怠けているのではない。「入力する合理的な理由がない」か、「入力しようとしても正しく入力できない」のだ。
データが汚いのは営業の問題ではない。CRMの設計の問題だ。
CRM設計で最初にやるべきこと——「作らない」という判断
CRMの設計で最初に重要なのは、項目をむやみに作らないことだ。
複数の組織でCRMの立ち上げや再設計に関わってきた経験から言えるのは、最初に項目を作りすぎたプロジェクトは、ほぼ例外なく後で苦しむということだ。使われない項目が大量に残り、「削除したいが怖くて消せない」「過去のデータを移し替える工数が読めない」という理由で放置される。結果、CRMはフィールドだらけなのに使えないシステムになる。
最初にどれだけ重要なポイントだけに絞れるか。これがCRM設計の最初の、そして最も重要な判断だ。
もう一つ、見落とされがちなのがダッシュボードとレポートの管理体制だ。CRMが稼働し始めると、マネージャーや企画担当が思い思いにレポートやダッシュボードを作り始める。それ自体は悪いことではないのだが、フィルター条件や集計ロジックが微妙に違うレポートが乱立すると、数字がずれる。「どのレポートが正しいのか」という不毛な確認作業に時間を使うことになる。
現場のマネジメントに求められるのは二つのルールだ。「分かっている人が一括管理し、ダッシュボードとレポートを作る」「それ以外の人は見ることに専念し、勝手に作らない」。このルールを最初に決めておかないと、CRMは数字の迷宮になる。
データが汚れる構造的原因
CRMのデータ品質が崩壊する原因は、大きく3つの構造的問題に帰結する。
1. 必須項目の設計ミス
商談作成時に15個の必須項目がある。営業は商談の初期段階で決裁者名も予算も競合情報もわからない。しかし必須だから「未定」「不明」「-」と入力する。こうして「入力率100%、情報価値ゼロ」のデータが量産される。
必須項目は「その時点で確実にわかっている情報」だけに絞るべきだ。商談ステージが進むにつれて入力すべき項目が増える「段階的必須化」の設計が正解だ。
2. 選択肢の粒度が合っていない
失注理由のプルダウンに「価格」「機能」「タイミング」「その他」の4択。現場の営業は「価格が高いんじゃなくて、ROIを説明しきれなかった」と思っているが、一番近い「価格」を選ぶ。結果、「失注理由の60%は価格」というミスリーディングなレポートが生まれる。
選択肢は「分析に使える粒度」と「営業が迷わず選べる粒度」のバランスで設計する必要がある。現場の営業3人に実際に選んでもらうテストを経ずにリリースしてはいけない。
3. 入力タイミング設計の欠如
「商談後にCRMを更新してください」。このルールは破綻する。営業は商談後、次の商談に向かうか、移動中にメールを返している。CRMを開くのは翌日か、週末のまとめ入力だ。
入力タイミングを営業のワークフローに埋め込む設計が必要だ。商談終了後にSlackで3問だけ聞く、カレンダーイベント終了時に自動プロンプトを出す。入力を「追加タスク」から「業務フローの一部」に変えること。これが設計の仕事だ。
GTMエンジニアが設計するCRMデータモデル5つの原則
では、どう設計すればいいのか。GTMエンジニアの視点から、CRMデータモデルの5原則を提示する。
原則1: 入力コストを最小化せよ
1回の入力に30秒以上かかるフィールドは設計を疑え。自由記述より選択式、選択式より自動入力。営業の行動データ(メール送信数、通話回数)はツール連携で自動取得し、手入力させない。
原則2: ステージ連動で段階的に必須化せよ
商談作成時の必須項目は最大5つ。ステージが「提案」に進んだら予算と決裁者を必須に、「交渉」に進んだら競合情報と導入時期を必須にする。SalesforceのValidation Rule、HubSpotのRequired Propertiesで実装できる。
原則3: 分析ゴールから逆算してフィールドを設計せよ
「このフィールドのデータで何を分析するのか」を答えられないフィールドは削除候補だ。まずダッシュボードの設計図を描き、そこに必要な指標を洗い出し、その指標を算出するためのフィールドだけを作る。
原則4: 一つのフィールドには一つの意味だけを持たせよ
「備考」フィールドに失注理由も顧客の反応も社内メモも入る状態は設計の放棄だ。一つのフィールドが一つの意味を持ち、構造化されたデータとして集計・分析できる状態を作る。
原則5: データの鮮度を仕組みで担保せよ
「最終更新日が30日以上前の商談」を自動検出してアラートを出す。ステージが90日間動いていない商談は自動でレビュー対象にする。データの鮮度は人の意識ではなく、システムのルールで担保する。
Before/After: 失注理由フィールドの再設計
Before(よくある設計)
- フィールド名: 失注理由
- 形式: 単一選択
- 選択肢: 価格 / 機能 / タイミング / 競合 / その他
- 結果: 「価格」が60%を占め、対策が「値引き」一辺倒に
After(GTMエンジニアの設計)
- フィールド名: 失注カテゴリ(単一選択)+ 失注詳細理由(カテゴリ連動の単一選択)
- 失注カテゴリ: 経済性 / プロダクト / タイミング / 競合 / 組織要因 / 関係構築
- 「経済性」選択時の詳細: 予算未確保 / ROI不明瞭 / 費用対効果で他社優位 / 価格交渉不成立
- 結果: 「経済性」の内訳が可視化され、「ROI説明の強化」「事例資料の拡充」など具体的な営業施策に落とし込める
たった1つのフィールドの再設計で、営業戦略の精度が変わる。
今日からできるCRMデータ設計チェックリスト
自社のCRMを以下の観点でチェックしてみてほしい。
- 商談作成時の必須項目は5つ以下か
- 「その他」「未定」「不明」が20%以上を占めるフィールドはないか
- 全てのカスタムフィールドに「何の分析に使うか」を説明できるか
- 自由記述フィールドが選択式に置き換えられないか検討したか
- 入力タイミングが営業のワークフローに組み込まれているか
- 最終更新日が30日以上前のレコードを検出する仕組みがあるか
- フィールドの選択肢を現場の営業にテストしてもらったか
3つ以上チェックが入らなければ、CRMの設計を見直す時期だ。
データ品質は設計品質
「営業の入力を徹底させる」は対症療法であり、持続しない。CRMのデータ品質は、設計品質の写し鏡だ。
入力する人間のことを理解し、分析の目的から逆算し、業務フローに溶け込む設計をする。これはツールの設定作業ではなく、営業プロセスとデータ基盤の両方を理解した人間が行うべき設計行為だ。
それがGTMエンジニアの仕事であり、「営業のせいにしない」組織を作る第一歩になる。CRMデータ設計のより体系的な解説はCRMデータ設計の教科書で詳しく説明している。RevOps視点でのデータガバナンスについてはRevOpsデータガバナンスガイドも参考になる。
参考文献
- Salesforce, https://www.salesforce.com/
- HubSpot, https://www.hubspot.com/
CRMのデータが汚い原因は何ですか?
主な原因は3つの設計問題です。商談初期に不明な情報まで必須にする必須項目の設計ミス、営業が迷う選択肢の粒度不一致、そして営業のワークフローに入力タイミングが組み込まれていない設計の欠如です。営業を責めるのではなく設計を見直すことが根本解決になります。
CRMの入力率を上げるにはどうすればいいですか?
入力コストの最小化が最も効果的です。自由記述より選択式、選択式より自動入力を優先し、メール・カレンダーなどの行動データはツール連携で自動取得します。商談後にSlackで3問だけ聞くなど、入力を業務フローに溶け込ませる設計が重要です。
よくある質問
QCRMのデータが汚い原因は何ですか?
QCRMの入力率を上げるにはどうすればいいですか?
QCRMデータ設計の5原則とは何ですか?
Related Services
関連記事
CRMデータ品質管理|汚れたデータが営業組織を蝕む前に
CRMデータ品質の劣化原因と実践的な管理手法を解説。データクレンジング、バリデーション設計、品質モニタリングまで、SalesforceやHubSpotで今日から始められる品質管理の全体像を示す。
CRMデータ設計の教科書|オブジェクト・命名・クレンジングまで実装手順
CRMのデータ設計を体系的に解説。オブジェクト設計、プロパティ設計、データクレンジング、命名規則まで、GTMエンジニアが最初に取り組むべきデータ基盤構築の実践ガイドです。
CRM/SFAを使いこなせない本当の理由と解決策
HubSpot・Salesforceを導入したのに活用できない企業が多い本当の理由を3つの失敗パターンから分析。営業プロセスとデータ基盤の設計で解決する方法を解説します。
渡邊悠介
代表取締役 / 株式会社Hibito
リクルート、MagicMomentを経て現職。幅広い営業経験と、営業推進、新規事業開発、採用の観点から企業の急成長を営業支援で支える。営業企画とAIを掛け合わせた「GTMエンジニア」として、営業組織の仕組み化・自動化を支援。CRMと生成AIを活用し、営業推進機能のAI化を推進する。
YouTubeでも発信中