%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
CRMが定着しない背景には、入力項目、運用ルール、現場への還元のずれがあります。人に入力を頼み続けるのではなく、入力負担を減らし、必要な情報が自然に集まる仕組みへ変えることが核心です。
CRMが定着しない背景には、入力項目、運用ルール、現場への還元のずれがあります。人に入力を頼み続けるのではなく、入力負担を減らし、必要な情報が自然に集まる仕組みへ変えることが核心です。
「CRMを導入したのに、営業担当者がデータを入力してくれない」「結局、マネージャーが各担当者にヒアリングしている」「CRMとExcelの両方を更新している」——こうした状態では、入力を促すほど現場の負担が増えてしまいます。
CRMの定着とは、担当者が入力を思い出して頑張ることではなく、日々の営業活動の中で必要な情報が記録され、その情報が次の行動や判断に使われている状態です。対策の中心になるのは、入力項目の最小化、ステージ移行時の必須プロパティ、自動入力、入力結果の可視化です。
本記事では、CRM定着を阻害する構造的な原因を分析し、人に頼らずシステムと運用ルールで定着させる方法を解説します。 前提となる考え方はCRM/SFA導入ガイドで解説しています。
この記事でわかること
CRMを導入したものの活用が進まないと感じている営業マネージャー・CRM管理者の方に向けた内容です。CRMが定着しない原因を分解し、入力負担を抑えながら運用を仕組み化する方法がわかります。
- CRMが定着しない構造的な原因 — 入力項目の多さ、現場へのメリット不足、Excelとの二重管理、営業プロセスとのずれを整理します。
- 入力されない問題を仕組みで解決する方法 — 必須プロパティ、自動入力、営業会議のルールをどのようにつなげるかを解説します。
- 入力負担を抑えるプロパティ設計 — 残す項目と外す項目を、業務上の必要性と利用場面から判断する考え方を紹介します。
- 現場に合うパイプラインの作り方 — 取引ステージ、受注確度、ステージ定義、必須プロパティを一体で設計する方法を整理します。
- 定着を継続させる展開と改善の進め方 — 限られたメンバーでの先行運用からチーム展開、全社展開へ進める際の判断基準を解説します。
CRMが定着しない原因は入力作業だけにない
CRMが使われないとき、担当者の意欲やITリテラシーだけを原因にすると、入力依頼や研修の回数を増やす対策に偏ります。しかし、日々の業務とCRMの設計が合っていなければ、呼びかけだけでは入力が続きません。まずは、入力する人、入力する場面、入力後の利用目的がつながっているかを分解して考えます。
入力項目が多く、判断まで担当者に委ねている
CRM導入時には、将来の分析に使えそうな情報まで集めたくなり、プロパティが増えやすくなります。ところが、入力項目が多いほど、担当者は「どこまで書けば完了なのか」「どの選択肢を選ぶべきか」を毎回判断しなければなりません。
ほとんど使われていない項目が画面に並ぶと、本当に重要な項目も見つけにくくなります。入力画面は情報の保管場所ではなく、次の営業行動に必要な情報をそろえる画面として設計することがポイントです。
入力が止まっている場合は、空欄を埋めるよう依頼する前に、各項目が使われる会議、レポート、引き継ぎ場面を書き出します。利用場面を説明できない項目は表示対象から外し、営業プロセス上の判断に使う項目を優先します。
入力結果が営業担当者へ返ってこない
入力したデータがマネージャー向けの集計だけに使われていると、営業担当者にとってCRMは報告作業のための道具になります。入力後に自分の案件状況、次回アクション、商談履歴を把握できなければ、日常業務でCRMを開く理由が生まれません。
定着させるには、担当者が入力した情報を担当者自身の業務へ返す設計が必要です。例えば、次のように使います。
- 商談メモ ── 次回の準備に使います
- クローズ予定日 ── 行動予定の把握に使います
- 取引ステージ ── 案件の優先順位づけに使います
管理者向けのレポートと現場向けの一覧を分けることも有効です。管理者が見たい集計だけでなく、担当者が今日の行動を決められるビューを用意することで、入力と利用が同じ流れに入ります。
Excelとの二重管理と現場に合わないパイプライン
CRMの導入後もExcelの案件表が残っていると、担当者は同じ内容を複数の場所へ入力することになります。Excelを会議用、CRMを会社の記録用として使い分けると、どちらが最新情報なのか分からなくなり、更新前の照合作業も発生します。
また、標準のパイプラインをそのまま使い、実際の営業活動と取引ステージが合っていない場合も入力は止まります。担当者が商談の状態を見ても該当するステージを選べなければ、更新を後回しにするか、人によって異なる判断をします。
導入後のフォローが不足すると、このずれが修正されないまま残ります。Excelにしかない情報、CRMにしかない情報、両方にある情報を整理し、営業会議で参照する基準をCRMへ寄せられる状態になった項目から二重管理を解消します。
「入力されない問題」を仕組みで解決する
CRMの定着は、「入力してください」と繰り返すことではなく、営業プロセスの節目で必要な情報がそろう仕組みを作ることから始まります。入力を強制するだけでは負担が増えるため、必須化する項目と自動化する項目を分けます。さらに、入力された情報を会議や次回アクションで使い、記録する意味が現場に伝わる流れを作ります。
ステージ移行時に必須プロパティを設定する
すべての項目を常に入力させるのではなく、情報が必要になるステージで必須にします。商談の初期段階で受注理由を求めても入力できませんが、クローズ時であれば判断材料がそろっています。
| ステージ移行 | 必須入力項目 |
|---|---|
| アポ取得 → 初回提案 | 商談日、商談メモ |
| 初回提案 → 見積提示 | 金額、クローズ予定日 |
| 見積提示 → 受注内示 | 受注確度、意思決定者 |
| 受注 → クローズ | 受注理由 |
| 失注 → クローズ | 失注理由（カテゴリ選択） |
この設計では、ステージを進める行為と必要情報の記録が一つの操作になります。担当者が何を把握すべきかも画面上で示せるため、新人への引き継ぎや営業プロセスの標準化にもつながります。
HubSpotでは、ステージごとの必須化を「条件付きステージプロパティ」（画面では「条件付きロジックルール」の列）で設定します。公式ナレッジ（Set up and manage object pipelines）に沿った手順は次のとおりです。設定には「プロパティ設定の編集」の権限が必要です。
- 設定（歯車）＞「データ管理」＞「オブジェクト」で「取引」を選び、「パイプライン」タブを開きます。
- 対象のパイプライン名をクリックし、必須にしたいステージの行で「条件付きロジックルール」の列にカーソルを合わせて「ルールを追加」をクリックします。
- 条件（例: 取引ステージが「見積提示」に該当する）を選び、「依存プロパティ」で表示したいプロパティを追加します。
- 必須にするプロパティは「必須」にチェックを入れ、「ロジックを保存」をクリックします。
読み取り専用のプロパティ（スコアや計算プロパティなど）は、ステージプロパティとして使えません。ステージの移動で取得できるかを、新人にも説明できる項目に絞ります。
移動そのものを制御したい場合は、パイプラインルール（Set up pipeline rules）を使います。設定場所は、同じパイプライン画面の「Pipeline Rules」タブです。
| ルール | できること | 注意すること |
|---|---|---|
| 記録を作成できるステージの限定 | 新規の取引を作れるステージを絞る | 既定ステージも指定する |
| ステージのスキップ禁止 | 途中のステージを飛ばせなくする | 受注・失注への移動は例外になる |
| 後退の禁止 | 指定ステージに到達したら前に戻せなくする | 受注・失注からの再開は戻せる |
| 編集権限の制限 | ステージに応じて編集できる人を限る | Super Adminなどには適用されない場合がある |
スーパー管理者、ワークフロー、APIで作成・編集したレコードはルールを回避できる点に注意し、ワークフローで取引を更新する場合は、必須項目が空のまま次のステージへ進まないよう、登録条件に入力済みの条件を加えます（ワークフローの設計項目はワークフロー設計書の書き方で整理しています）。
ただし、入力できない情報を必須にすると、仮の値が登録されてデータの信頼性が下がります。現場がその時点で顧客へ聞ける情報だけを必須にし、取得できない場合の選択肢が必要な項目には、未確認であることが分かる値を用意します。
入力が止まったときは、症状から原因を切り分けます。
| 症状 | 疑う原因 | 直す場所 |
|---|---|---|
| 特定のステージで入力が止まる | そのステージで取得できない項目を必須にしている | 条件付きロジックルールの必須ステージを後ろへ移す |
| 空欄が特定の項目に集中する | 利用場面がなく、入力する理由がない | 画面から外す（非表示にする）か、項目を廃止する |
| Excelの更新が続いている | 会議の資料がCRMの一覧やダッシュボードになっていない | 会議用のビューを作り、Excelの更新を止める |
| 担当者ごとに同じ項目の値が違う | 選択肢や定義が曖昧 | 選択式にして定義を文章で共有する |
手入力と自動入力の役割を分ける
担当者が判断しなくても取得できる情報は、手入力から外すことを検討します。メール連携によるやり取りの記録、カレンダー連携によるミーティングの記録、計算プロパティによる集計や分類など、既存の業務操作から生成できる情報を手で再入力させない設計にします。
スマートプロパティを使う場合は、企業情報の調査や入力をBreezeで補助できます。最初から多くの項目を自動入力の対象にするのではなく、商談準備や企業分類に使う項目から始め、結果が実務に使えるかを見ながら対象を広げます。
ワークフローから使える「Data Agent: Fill Smart Property」は、スマートプロパティに値を自動で入力するアクションです。利用にはProfessionalまたはEnterpriseとHubSpotクレジットが必要で、値はワークフローの実行時にだけ更新されます（出典: Use Breeze to manage data in workflows）。継続的に最新になるわけではないため、更新のタイミングを運用に組み込みます。
ただし、Breezeが入力した内容をそのまま顧客対応や重要な判断に使うのではなく、担当者が元の情報と照合して採用する運用にします。誤りが続く項目は自動更新の対象から外し、補助情報として表示するか、担当者が照合後に確定する項目へ切り替えます。
営業会議とCRMのルールをそろえる
CRMへ入力した後も、会議用のExcelを別に作る運用では二重管理が残ります。営業会議ではCRMの取引情報とダッシュボードを参照し、更新されていない案件は会議前に担当者が見直す流れにします。
「CRMにない案件は会議で取り上げない」というルールは、入力経路とステージ定義が整ってから適用します。先に厳格なルールだけを設けると、現場は会議に間に合わせるための形式的な入力を増やしてしまいます。
会議では状況報告を読み上げるのではなく、停滞している案件、支援が必要な案件、次に進める条件を話し合います。CRMが報告先ではなく、チームで営業判断を行う共通の基盤になると、入力した情報がその場で利用されます。
入力負担を抑えるプロパティ設計
プロパティは、集められる情報ではなく、営業活動や経営判断に使う情報から設計します。項目を減らすだけでは必要な情報まで失われるため、利用目的、入力時点、入力者、更新方法をセットで整理します。自社の営業プロセスに沿って、初期画面に表示する項目と後工程で必要になる項目を分けます。
残す項目を利用目的から決める
取引名、金額、クローズ予定日、取引ステージ、担当者は、案件の識別や進捗管理に使う情報です。商談メモと次回アクションは、担当者の振り返りや引き継ぎに使えます。
| 優先度 | プロパティ | 理由 |
|---|---|---|
| 必須 | 取引名 | 案件の識別 |
| 必須 | 金額 | フォーキャスト算出 |
| 必須 | クローズ予定日 | 売上予測 |
| 必須 | 取引ステージ | 進捗管理 |
| 必須 | 担当者 | 責任の明確化 |
| 推奨 | 商談メモ | 引き継ぎ・振り返り |
| 推奨 | 次回アクション | フォロー管理 |
重要なのは、項目の数だけでなく、入力時点を決めることです。取引作成時に集める情報、提案時に必要な情報、クローズ時に残す情報を分けると、担当者はその場で必要な項目に集中できます。
自由記述と選択式を使い分ける
失注理由や案件分類のように集計したい情報は、選択式にすると表記のばらつきを抑えられます。一方、商談の背景や顧客の発言など、選択肢だけでは文脈が失われる情報は自由記述に向いています。
選択式の項目を増やしすぎると、似た選択肢が並び、担当者が判断できなくなります。レポートで分類して比較する情報は選択式、次の担当者が経緯を理解するための情報は自由記述というように、利用目的で分けます。
ただし、自由記述だけでは集計が難しく、選択式だけでは背景が残りません。失注理由はカテゴリを選び、必要に応じて補足メモを残すなど、分析用の項目と引き継ぎ用の項目を組み合わせます。
プロパティを増やす権限と棚卸し方法を決める
利用者が自由にプロパティを追加できる状態では、同じ意味の項目や一時的な用途の項目が増えやすくなります。プロパティ設定は管理者が扱い、追加依頼を受けたときは、利用目的、入力者、利用するレポート、既存項目との違いを書き出します。既存項目で代替できる場合は追加せず、代替できず利用場面が明確な場合だけ追加します。
棚卸しでは、空欄の多さだけで削除を判断しません。特定のステージでだけ使う項目は、対象となる取引に絞って利用状況を集計し、対象取引で使われていれば残し、使われていなければ非表示候補にします。
入力されていても会議やレポートで使われていない項目は、表示から外す候補です。反対に、入力が少なくても契約や引き継ぎに必要な項目は残し、入力するステージと担当者を明確にします。
現場に合うパイプラインで入力基準を統一する
パイプラインは、案件を並べるための表示ではなく、営業プロセスを共通化するための設計です。取引ステージだけを作るのではなく、各ステージの意味、受注確度、移行時に必要な情報を一体で決めます。マネージャーと現場の営業担当者が同じ基準で案件を見られることが、データの信頼性につながります。（出典：Set up pipeline rules）
取引ステージとステージ定義をそろえる
取引ステージは、社内作業の完了ではなく、顧客との関係や受注可能性が変わる節目に置きます。例えば、アポ取得、初回提案、見積提示、受注内示、受注、失注という流れを使う場合、それぞれの状態を文章で定義します。
「初回提案」は資料を送った時点なのか、顧客へ説明した時点なのかによって担当者の判断が分かれます。ステージ名だけで運用を始めず、「どの事実が分かれば移動するか」を定義し、チームで共有します。
標準テンプレートが実際の営業フローと合わない場合は、自社の商談の進み方に合わせて見直します。ステージを増やす判断は、その段階で受注確度や必要な行動が変わるかを基準にします。
受注確度と必須プロパティを連動させる
受注確度は担当者の感覚だけで更新するのではなく、取引ステージと対応させます。同じステージの案件を同じ基準で見られるようになると、マネージャーは案件ごとの説明を集めなくてもパイプライン全体を把握しやすくなります。
| 設計要素 | 決める内容 | 定着への効果 |
|---|---|---|
| 取引ステージ | 顧客との関係が変化する節目 | 案件の進捗を共通言語にする |
| 受注確度 | 各ステージの見込みの扱い | 担当者ごとの楽観や悲観を抑える |
| ステージ定義 | 移動できる客観的な条件 | 判断のばらつきを減らす |
| 必須プロパティ | 移行時に取得する情報 | 必要なデータの空白を防ぐ |
HubSpotの取引では、ステージごとに「取引確度」（Deal probability）を設定します。ボードビューの加重金額は、ステージの合計金額に確度を掛けて算出されます。既定の販売パイプラインは、「商談予定」（20%）から「受注」（100%）、「失注」（0%）まで7段階で、受注と失注はクローズのステージとして必ず含めます（出典: Set up and manage object pipelines）。確度の数値は、自社の過去の案件でそのステージから受注した割合を見て調整します。
必須プロパティは、営業プロセス上で聞いておく情報と、レポートに必要な情報の両方から決めます。現場が取得できる時点より早く必須化されている場合は、項目を外すのではなく、必須にするステージを後ろへ移します。
ベテランの知見を引き継げる形にする
ベテラン営業が独自の方法で案件を進めている場合、その方法を否定して入力を求めるだけでは協力を得にくくなります。どの段階で何を聞き、どの情報から次の行動を判断しているかを聞き取り、ステージ定義や必須プロパティへ反映します。
これにより、担当者個人の経験が、チームで再利用できる営業プロセスになります。新人はステージ移行時の項目を見ることで、次に何を把握すべきかを学べます。
ただし、一人の進め方をそのまま全体へ適用すると、商材や顧客によって合わない場面が生じます。複数の担当者が共通して使える条件をステージ定義にし、個別の工夫は商談メモや運用ガイドで補います。
一元管理と自動化と可視化を一つの流れにする
CRMは情報を保存するだけではなく、営業プロセスの標準化、部門間の引き継ぎ、判断の基盤として使うことで価値が生まれます。コンタクトから取引、顧客化後の対応、請求までの流れの中で、どの情報をどこで作り、誰が使うかを整理します。一元管理、自動化、可視化を別々に導入せず、一つの業務フローとしてつなげることが要点です。
ExcelからCRMへ基準となる情報を寄せる
Excelは集計や一時的な検討に使いやすい一方、担当者ごとにファイルや列が増えると、更新差分が起こりやすくなります。CRMとExcelに同じ顧客情報や案件情報がある場合は、どちらを基準にするかを項目ごとに決めます。
最初からすべてのExcelをなくすのではなく、営業会議で参照する取引ステージ、金額、クローズ予定日、担当者などからCRMへ寄せます。CRMの情報だけで会議を進められる状態になった項目は、Excel側の更新を止めます。
ただし、CRMに必要なビューや集計がなく、Excelを残さないと業務が止まる場合は、先にCRM側の表示やレポートを整えます。CRMだけで同じ判断ができる状態になってから、重複する表の運用を終了します。
取引一覧を日常業務の入口にする
取引一覧には、担当者が案件を識別し、次の行動を決めるための情報を表示します。全プロパティを並べるのではなく、取引名、ステージ、担当者、金額、クローズ予定日など、日々見る項目に絞ります。
以下の画面は、HubSpotの取引をテーブル形式で一覧表示した例です。
担当者向けのビューには自分の案件や更新が必要な案件を表示し、マネージャー向けのビューにはチーム全体の停滞や見込みを表示します。役割ごとに次の行動を決められる列だけを残します。
同じ取引データを役割に応じた見え方で利用すれば、報告用の表を別に作る必要が減ります。入力先は共通にしながら、担当者とマネージャーが必要な情報へすぐにたどり着ける状態を作ります。
入力結果をダッシュボードへ返す
入力した情報が一覧やダッシュボードに反映されると、担当者は自分の案件状況や次回アクションを把握できます。チームでは目標の進捗やパイプラインの偏りを見ながら、支援する案件を判断できます。
ダッシュボードは表示するだけでは定着につながりません。営業会議で見るレポート、担当者が日常的に見る一覧、経営判断に使う指標を分け、それぞれの利用場面を決めます。
ただし、入力されていない項目を使ったレポートは、見た目が整っていても判断に使えません。レポートで空欄や不自然な値が見つかった場合は、担当者への注意だけで終わらせず、入力時点、必須設定、自動更新の条件まで戻って修正します。
スモールスタートから段階的に展開する
CRMは初期設定を完了した時点ではなく、現場の利用から得た課題を修正しながら定着させます。最初から全社へ広げると、入力ルールの曖昧さや不要項目が多くの利用者へ影響します。限られたメンバーでの先行運用、チームでの本格運用、対象範囲の拡張という順で進めます。
限られたメンバーで操作と入力基準を検証する
先行運用では、チームリーダーと実務担当者が実際の案件を使って操作します。取引作成からステージ更新、商談メモ、次回アクション、クローズまでを通し、入力に迷う場所や二重入力が残る場所を洗い出します。
ここでは利用回数を増やすことより、業務フローと設定のずれを見つけることが目的です。担当者が説明なしで選べない項目は名称や選択肢を直し、その時点で取得できない必須項目は設定するステージを変更します。
先行運用を終える条件は、実際の案件が一連のステージを進み、会議に必要な情報をCRMから把握できることです。その状態に届かなければ利用者を増やさず、入力画面と会議の流れを見直します。
一つのチームで運用ルールを磨く
次の段階では、一つの営業チームで取引管理と会議をCRMへ寄せます。誰がいつ情報を更新するか、更新されていない案件をどう扱うか、失注理由をどのように記録するかを運用ルールとして共有します。
| 段階 | 主な目的 | 次へ進む判断 |
|---|---|---|
| 限られたメンバーでの先行運用 | 操作と設計のずれを発見 | 実案件を迷わず更新できる |
| チームでの本格運用 | 入力ルールと会議の流れを確立 | CRMの情報で営業会議を進められる |
| 対象範囲の拡張 | 共通ルールを他チームへ展開 | 引き継ぎ用の定義と支援体制が整っている |
質問が集中する操作は、担当者の習熟不足と決めつけず、画面やルールが分かりにくい可能性を検討します。同じ質問が繰り返される場合は、説明を増やす前に項目名、ステージ定義、入力タイミングを修正します。
先行メンバーが引き継げる仕組みを作る
対象範囲を広げるときは、先行運用に参加したメンバーが社内コーチとして支援できる状態を作ります。操作方法だけでなく、なぜその項目を入力するのか、どの会議やレポートで使うのかまで共有します。
担当者が変わっても運用できるように、ステージ定義、必須プロパティ、入力タイミング、問い合わせ先をまとめます。個人の記憶に頼らず、新人でも同じ流れで取引を更新できることが仕組み化の基準です。
ただし、先行チームのルールが他チームの営業プロセスと合わない場合は、そのままコピーしません。共通化できるプロパティとチーム固有のプロパティを分け、同じ意味の情報が異なる名称で増えないよう管理します。
CRM定着後もデータと運用を見直す
CRMが使われ始めても、事業や営業プロセスが変われば、以前の設定が現場に合わなくなることがあります。定着を一度きりの導入施策にせず、入力状況、利用状況、会議での活用を定期的に見直します。項目を増やす前に、既存の仕組みで解決できないかを検討する姿勢が重要です。
入力率だけでなく利用場面まで見る
空欄が多い項目は、担当者が入力を忘れているとは限りません。次のような原因が考えられます。
- 入力するステージが来ていない
- 対象外の案件が多い
- 項目の意味が伝わっていない
- 入力後に使われていない
棚卸しでは、対象となる取引での入力有無、レポートや会議での参照有無、別項目との重複を一覧にします。入力されておらず利用場面もない項目は非表示候補とし、利用場面がある項目は入力タイミングや必須設定を見直します。
入力率の数値だけを目標にすると、仮の値や形式的な入力が増える場合があります。記録された内容が次の行動、引き継ぎ、分析に使えるかを合わせて評価します。
厳格なルールが現場を止めていないかを見る
必須プロパティやステージ移行の制御は、データの空白を防ぐために有効です。一方で、商談時点では分からない情報まで求めると、担当者は仮入力で先へ進むか、CRMの更新自体を止めます。
入力できないという問い合わせが出た場合は、その情報を顧客との会話で取得できる段階を書き出します。取得時点が現在のステージより後ろなら必須化するステージを変更し、営業判断に不要なら項目を外します。
また、例外が多い商談を一つのパイプラインへ押し込むと、ステージ定義が曖昧になります。共通の進み方で管理できる案件は同じパイプラインに置き、進行条件が大きく異なる案件は運用を分けることを検討します。
Breezeと人の判断範囲を分ける
Breezeは企業情報の調査やプロパティ入力を補助し、担当者の手作業を減らす用途で活用できます。自動化に向くのは、元情報を把握でき、誤りがあっても人が修正できる作業です。
パイプラインのステージ定義、必須プロパティ、営業会議の判断基準は、自社の営業プロセスを理解する人が決めます。AIが出した結果は叩き台として扱い、顧客対応や重要な案件判断には担当者のレビューを入れます。
ただし、人がすべてを再入力する運用では自動化の効果が薄れます。Breezeが作成した内容のうち、照合だけで採用できる項目と、担当者が編集する項目を分け、誤りが見つかった項目にだけ作業を集中させます。
StartLinkの定着支援の進め方
StartLinkはHubSpotゴールドパートナーとして、150社以上のHubSpot支援に携わっています。CRMの定着では、設定を増やす前に次の順で進めます。業種別の事例は不動産の事例などで確認できます。
- 現状の整理・要件定義: 各項目が使われる会議・レポート・引き継ぎ場面と、Excelに残る情報を洗い出します。
- 設計・構築: ステージ定義、確度、必須プロパティ、現場向けの一覧を一体で設計し、構築します。
- データ移行: Excelの案件表をCRMへ寄せ、件数と金額を照合します（データ移行の検証手順）。
- テスト・検証: 限られたメンバーの実案件で、作成からクローズまでを通して確認します。
- 定着・運用改善: 週次のレビューで入力の抜けと停滞を確認し、ルールを見直します（週次パイプラインレビューとデータ品質ダッシュボード）。
スモールスタートで始め、準委任で伴走する進め方は伴走型支援の進め方と社内との役割分担で、後から変えにくい設定の考え方は後から変えにくい設定で整理しています。HubSpot導入全体はHubSpot導入・構築支援のページで確認できます。企業様によって最適な形は異なります。
よくある質問
CRMの定着では、入力を促す施策よりも、入力と利用がつながる設計が重要です。ここでは、すでに運用が止まっている場合や、担当者ごとに使い方が異なる場合の考え方を整理します。
Q1. CRM入力のインセンティブは設けるべきですか？
短期的な入力促進策として使うことはできますが、入力そのものが目的になると、内容の質や利用価値が置き去りになります。自分の案件一覧が整理される、過去の商談メモを準備に使える、次回アクションを把握できるなど、日常業務へ情報が返る設計を優先します。
インセンティブを設ける場合も、入力件数だけで評価せず、更新された情報が会議や引き継ぎで使える状態かを見ます。形式的な入力が増えた場合は施策を続けず、入力項目と利用場面を見直します。
Q2. すでにCRMの運用に失敗している場合はリセットすべきですか？
完全に作り直す前に、現在のプロパティ、パイプライン、Excelとの重複、会議で使われている情報を整理します。利用されているデータまで消すのではなく、不要な表示を外し、ステージ定義と必須プロパティを実態に合わせます。
既存データが現在のルールで解釈できる場合は、残したまま運用を修正します。意味が重複するプロパティや判断基準が異なる値がある場合は、新しい入力先を決めてから、過去データをどのように扱うかを切り分けます。
Q3. ベテラン営業が自分のやり方を優先する場合はどうしますか？
ベテラン営業が商談のどこで状況を判断し、何を聞いて次へ進めているかを整理します。その知見を取引ステージ、ステージ定義、必須プロパティへ落とし込めれば、個人のノウハウをチームで再利用できます。
一方的に入力を依頼するのではなく、設計段階から参加してもらうことがポイントです。ただし、個人固有の方法まで全員へ強制せず、複数の担当者が使える共通部分を仕組みにします。
Q4. モバイルでの入力は定着に役立ちますか？
商談直後に更新できる動線は、記録の後回しを減らす助けになります。外出が多い担当者には、商談メモ、取引ステージ、次回アクションなど、その場で更新する項目を絞って提示します。
モバイル画面で多くの項目を入力させると、かえって負担が増えます。外出先では最低限の更新を行い、詳細な整理が必要な内容は社内へ戻った後に見直すなど、利用場面に応じて役割を分けます。
Q5. 取引ステージごとに入力を必須にするには、どこで設定しますか？
設定（歯車）＞「データ管理」＞「オブジェクト」で「取引」を選び、「パイプライン」タブで対象のパイプラインを開きます。必須にしたいステージの「条件付きロジックルール」の列で「ルールを追加」をクリックし、依存プロパティを追加して「必須」にチェックを入れ、「ロジックを保存」で確定します。設定には「プロパティ設定の編集」の権限が必要で、スコアや計算プロパティなど読み取り専用のプロパティは使えません。その時点で顧客に聞ける項目だけを必須にします。
まとめ
CRMが定着しない問題は、担当者の意欲だけではなく、入力項目、営業プロセス、会議、レポートが分断されていることから生じます。人に入力を頼み続けるのではなく、業務の節目で必要な情報が集まり、次の行動へ使われる仕組みに変えることが重要です。
- 入力項目は利用目的と入力時点から選び、使われていない項目を画面から外します。
- 必須プロパティはステージ移行時に取得できる情報へ絞り、自動取得できる情報は手入力から外します。
- 取引ステージ、受注確度、ステージ定義、必須プロパティを一体で設計し、案件判断の基準を統一します。
- CRMの情報を営業会議、担当者向け一覧、ダッシュボードで利用し、Excelとの二重管理を段階的に解消します。
- 限られたメンバーでの先行運用から始め、実案件で確かめられたルールをチームと全社へ広げます。
まずは、現在の取引画面に表示されているプロパティの棚卸しから始めます。その後は、次の流れで進めてください。
- 各プロパティが使われる会議、レポート、引き継ぎ場面を書き出します。
- 利用場面がない項目を非表示にし、必要な項目は入力するステージを決めます。
- 実際の案件で取引作成からクローズまで進め、入力に迷う箇所と二重管理が残る箇所を修正します。
CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのStartLinkまでお気軽にお問い合わせください。
あわせて読みたい
CRMが定着しない原因と対策と関連するテーマについては、次の記事もあわせて確認できます。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
