CRM改善チェックリスト|営業・顧客データ・運用定着を見直す
CRMを導入しても、顧客情報が十分に入力されない、営業担当者が日報代わりにしか使わない、蓄積したデータから施策を作れないといった問題が起こることがあります。高機能なCRMを導入していても、利用目的、入力基準、業務手順、評価指標が曖昧であれば、現場にとっては作業負担の大きい管理システムになってしまいます。
CRM改善では、入力率だけを確認してはいけません。登録された情報が正しいか、その情報を誰が何の判断に使うか、営業やマーケティングの行動が変わったか、顧客体験や収益が改善したかまで確認する必要があります。入力件数が増えても、担当者が判断に使えない情報ばかりであれば、CRMの価値は高まりません。
本記事では、CRMの目的、顧客データ、営業活動、マーケティング、顧客維持、操作性、社内定着、分析、安全管理を見直すためのチェックリストを紹介します。各項目は、確認するだけでなく、問題が見つかった後に何を変更すべきかまで判断できる構成です。
1. CRM改善チェックリストとは
CRM改善チェックリストは、CRMの設定、データ、利用状況、業務成果を複数の観点から確認し、改善すべき場所を見つけるための診断項目です。システム担当者だけでなく、営業、マーケティング、顧客支援、経営の担当者が共同で利用します。
CRMの問題は、一つの部門だけでは解決できない場合があります。入力されない原因が画面の使いにくさではなく、営業工程の定義不足や評価制度にあることも珍しくありません。
1.1 CRMの利用状況を客観的に確認できる
CRM担当者は、導入や設定に関わっているため、現在の運用を客観的に見にくくなることがあります。チェックリストを使えば、担当者の感覚ではなく、共通の確認項目に基づいて問題を発見できます。
「現場が使っていない」と判断する前に、ログイン率、入力完了率、更新頻度、検索回数、レポート利用状況などを確認します。利用していないのか、利用する必要がない設計なのかを分けることが重要です。
1.2 部門ごとの認識差を発見できる
営業部門は商談管理を重視し、マーケティング部門は顧客分類や反応履歴を重視します。カスタマーサクセス部門は利用状況や契約更新を必要とします。
同じCRMを利用していても、部門ごとに期待する役割が異なります。チェックリストを共同で確認することで、どの情報を共通で管理し、どの情報を部門別に管理するかを決めやすくなります。
1.3 システムと業務の問題を分けられる
画面が使いにくい、処理が遅い、外部システムと連携できない問題は、システム側の改善が必要です。一方、入力する情報が分からない、商談段階を判断できない問題は、業務ルールを見直す必要があります。
原因を分けずに機能追加を行うと、入力項目や画面が増え、さらに使いにくくなる場合があります。問題がシステム、業務、教育、組織のどこにあるかを判断してください。
| 問題の例 | 主な原因 | 改善の方向 |
|---|---|---|
| 入力欄が多すぎる | システム設計 | 項目削減、画面分割 |
| 商談段階を選べない | 業務定義 | 移行条件の明文化 |
| 担当者ごとに表記が違う | 入力規則 | 選択式への変更 |
| レポートを使わない | 活用設計 | 会議資料との統合 |
| 入力が評価されない | 組織制度 | 評価・会議運用の変更 |
1.4 改善の優先順位を決められる
CRMには多くの改善候補が存在します。すべてを同時に変更すると、現場が新しいルールへ対応できず、改善前後の比較も難しくなります。
チェック項目ごとに、事業への影響、発生頻度、対応難易度を評価します。顧客対応漏れや重要商談の停滞など、損失へ直結する問題から対応してください。
1.5 定期診断に利用できる
CRMは、導入時に完成するものではありません。商品、営業体制、顧客行動、法令、利用するシステムが変われば、必要な項目や手順も変化します。
四半期または半年ごとに同じチェックリストを使用すると、改善前後の変化を確認できます。新しい項目を追加するだけでなく、不要になった項目や画面を削除する機会としても利用します。
2. CRMの目的を確認するチェックリスト
CRM改善で最初に確認すべきなのは、搭載されている機能や画面構成ではなく、CRMを使って何を改善したいのかという目的です。利用目的が曖昧なまま項目やレポートを追加すると、入力する情報だけが増え、どのデータが本当に必要なのか判断できなくなります。その結果、現場の負担は増えても、売上や顧客対応の改善にはつながらない状態になりやすくなります。
「顧客情報を一元管理する」という表現だけでは、具体的な運用方針を決めることはできません。集約した顧客情報を誰が利用し、どのような判断を行い、最終的にどの数字を改善するのかまで明確にする必要があります。CRMの目的を業務上の成果と結び付けることで、必要な項目、画面、レポート、自動化の優先順位を判断しやすくなります。
2.1 CRMを使って改善する数字が決まっているか
CRMによって改善できる数字には、見込み顧客から商談へ進む割合、商談の受注率、受注までにかかる期間、再購入率、契約更新率、解約率、問い合わせの初回対応時間や解決時間などがあります。事業や部門によって重視する数字は異なるため、CRMを導入または改善する際は、どの数字を変えるために利用するのかを明確にします。
複数の指標を管理する場合でも、一定期間における最優先指標を一つ決めることが重要です。優先順位がなければ、営業は受注率、マーケティングは見込み顧客数、顧客支援は問い合わせ件数だけを追うなど、部門ごとに異なる改善を進める可能性があります。各部門の活動が別々の方向へ進むと、CRM全体として成果が出ているのか評価できません。
また、指標名だけでなく、計算方法、対象データ、評価期間、現在値、目標値、責任者まで決める必要があります。例えば「受注率」であれば、すべての商談を分母とするのか、提案済みの商談だけを対象とするのかによって数字が変わります。会議や部門によって異なる計算を行わないように、共通の定義を残してください。
確認項目
- CRMで改善したい最優先指標が決まっている
- 指標の名称と計算方法が社内で統一されている
- 現在値と目標値が設定されている
- 評価する期間が決まっている
- 指標の改善に責任を持つ担当者が明確になっている
2.2 CRMを利用する業務範囲が決まっているか
CRMで管理する範囲によって、必要なデータ、利用部門、画面構成は大きく変わります。見込み顧客の獲得から受注までを管理する場合は、流入経路、顧客課題、商談段階、受注予定日などが中心になります。一方、契約後の利用支援や更新まで管理する場合は、契約内容、利用状況、問い合わせ履歴、更新意向、解約の兆候なども必要です。
最初からすべての顧客接点をCRMへ集約しようとすると、設定やデータ移行、教育の負担が大きくなり、現場での利用が定着しないことがあります。まずは受注管理や契約更新など、改善効果が大きく、関係部門が合意しやすい業務から開始し、運用が安定してから対象範囲を広げる方法も有効です。
対象範囲を決める際は、単にCRMへ登録する情報を整理するだけでなく、各段階の責任部門と、次の部門へ引き渡す条件も明確にします。マーケティングから営業、営業から顧客支援へ顧客情報が移る際に、どの情報が必要かを確認すると、部門間の引き継ぎ漏れを防げます。
| 管理範囲 | 主な担当部門 | 主に必要となる情報 |
|---|---|---|
| 見込み顧客獲得 | マーケティング | 流入経路、関心分野、反応履歴、同意状況 |
| 商談管理 | 営業 | 顧客課題、商談金額、商談段階、受注予定日 |
| 契約管理 | 営業・営業管理 | 契約内容、開始日、終了日、更新日、契約条件 |
| 利用支援 | 顧客支援 | 利用状況、問い合わせ、支援履歴、顧客の目標 |
| 継続管理 | 顧客支援・営業 | 更新意向、成果、離脱兆候、追加提案の可能性 |
2.3 CRMを利用する部門が合意しているか
経営者や管理者がCRMの導入を決定しても、実際に入力や更新を行う現場が利用目的を理解していなければ、運用は定着しません。特に営業担当者がCRMを管理者へ報告するための仕組みだと捉えると、最低限の情報しか入力しなかったり、会議の直前にまとめて更新したりする可能性があります。
CRMを導入する際は、管理や監視のためではなく、担当者自身の業務を改善する仕組みであることを具体的に説明する必要があります。営業には対応漏れや商談停滞の防止、マーケティングには顧客反応と売上の把握、顧客支援には過去の対応履歴の共有、経営には受注予測や顧客維持状況の可視化といった利点を示します。
また、利用目的を説明するだけでなく、入力項目や業務ルールを決める段階から各部門の代表者を参加させることも重要です。現場の業務と合わない設計を一方的に導入すると、表計算ファイルや個人管理へ戻る原因になります。部門ごとの要望をすべて採用するのではなく、CRM全体の目的と照らし合わせて優先順位を決めてください。
2.4 CRMを使わない業務が決まっているか
CRMへ情報を集約することは重要ですが、企業内のすべての情報をCRMだけで管理する必要はありません。会計処理、契約書原本、詳細な問い合わせ対応、商品在庫、開発課題などは、それぞれの業務に適した専用システムで管理したほうが安全で効率的な場合があります。
複数のシステムで同じ情報を管理すると、入力作業が重複し、どの情報が正しいのか分からなくなります。例えば契約金額をCRMと会計システムの両方で編集できる場合、更新時期の違いによって数字が一致しなくなる可能性があります。そのため、項目ごとにどのシステムを正式な情報源とするのかを決める必要があります。
CRMには、顧客対応や判断に必要な要約情報と、詳細情報が保存されているシステムへの参照先だけを保持する方法もあります。CRMで管理しない業務を明確にすることは、機能不足ではなく、データの重複と運用負担を防ぐための設計です。
2.5 CRM導入時の目的が現在も有効か
CRMを導入してから数年が経過している場合は、当初の利用目的が現在の事業や顧客対応に合っているかを確認する必要があります。新しい商品、販売経路、顧客層、契約形態が増えていれば、管理すべき情報や必要なレポートも変化しています。
導入時の設定を変更しないこと自体を運用目標にしてはいけません。過去には必要だった項目でも、現在は利用されていない場合があります。反対に、オンライン商談、継続契約、顧客利用状況など、導入時には想定されていなかった情報が重要になっている可能性もあります。
利用されていない機能、項目、レポートが多い場合は、現場がCRMを使っていないという問題だけでなく、過去の目的に基づいた設計が残っている可能性があります。現在の事業目標と顧客対応の流れを確認し、CRMの目的、対象範囲、評価指標を定期的に見直してください。
3. 顧客データ品質を確認するチェックリスト
CRMを使った分析、自動化、売上予測、顧客分類の精度は、登録されているデータの品質に左右されます。重複した顧客、未入力の項目、古い連絡先、統一されていない表記が多い場合、レポートを作成しても実態と異なる結果が表示されます。
データ品質の問題を、入力担当者の注意不足だけで解決しようとしてはいけません。複雑な入力画面、過剰な必須項目、分かりにくい選択肢、複数システムからの上書きなど、仕組み自体が誤入力を生み出している場合があります。入力方法、自動取得、重複防止、定期確認を組み合わせて改善する必要があります。
3.1 顧客の重複登録が発生していないか
同じ顧客が複数登録される原因には、会社名の表記違い、担当者のメールアドレス変更、名刺管理システムからの取り込み、Webフォームからの再登録などがあります。「株式会社」を付けるかどうか、全角と半角、略称と正式名称などの違いによって、別の会社として登録される場合もあります。
重複データが残っていると、商談履歴、購入履歴、問い合わせ履歴が複数の顧客画面へ分散します。その結果、担当者が過去の対応を把握できず、同じ顧客へ重複して連絡したり、すでに取引中の企業を新規顧客として扱ったりする可能性があります。レポート上の顧客数も実際より多く表示されます。
メールアドレス、電話番号、法人番号、会社ドメインなど、重複判定に利用する項目を決めてください。ただし、一つのメールアドレスを複数人で共有する企業もあるため、単独の項目だけで自動統合するのは危険です。重複候補を抽出し、担当者が確認したうえで統合する仕組みと、統合時に残す情報の優先順位を整えます。
確認項目
- メールアドレスや電話番号による重複確認が設定されている
- 法人番号や会社ドメインを判定に利用している
- 会社名の略称や表記違いを確認できる
- 重複データの統合手順が文書化されている
- 重複候補の件数を定期的に確認している
3.2 必須項目が多すぎないか
必須項目を増やせば、必要な情報がすべて登録されるように見えます。しかし、顧客からまだ確認できていない情報まで入力を求めると、担当者は仮の値や推測した情報を登録する可能性があります。未入力を防ぐための設定が、誤ったデータを増やす原因になることもあります。
必須にするのは、その情報がなければ次の業務へ進めない項目や、重要なレポートの計算に必要な項目に限定します。すべての案件に必要ではない情報は、条件に応じて表示したり、商談が一定の段階へ進んだ時点で入力を求めたりする方法が適しています。
「将来使う可能性がある」「念のため残したい」という理由だけで必須項目を増やしてはいけません。利用実績や入力後の活用状況を定期的に確認し、入力されていても誰も使っていない項目は、任意化、非表示、削除を検討してください。
| 項目の利用状況 | 適切な対応 |
|---|---|
| 次の担当者や業務で必ず使用する | 必須項目の候補 |
| 正式なレポートの計算に必要である | 必須項目の候補 |
| 一部の商品や案件だけで必要になる | 条件付きで表示する |
| 顧客理解の補足として使用する | 任意項目とする |
| 長期間入力・利用された実績がない | 非表示または削除を検討する |
3.3 自由記述が多すぎないか
自由記述欄は、顧客の背景や担当者の所感など、選択肢では表現しにくい情報を残すために有効です。一方で、同じ意味でも担当者によって異なる言葉が使われるため、集計、検索、自動化には利用しにくくなります。
例えば、業種を「IT」「情報通信」「システム開発」などと自由に入力すると、同じ分類の顧客が別々に集計されます。地域、商談段階、失注理由、問い合わせ種類など、分析や処理条件として利用する項目は、原則として選択式にします。
ただし、選択肢だけでは具体的な事情が分からない場合があります。そのため、「失注理由」と「失注理由の補足」のように、集計用の選択項目と、背景を残す自由記述欄を組み合わせます。自由記述を完全になくすのではなく、何を選択式にし、何を補足として残すかを分けることが重要です。
3.4 顧客情報が定期的に更新されているか
顧客の担当者、部署、役職、電話番号、メールアドレス、契約状況は、時間の経過とともに変化します。登録時点では正確だった情報でも、更新されなければ利用できないデータになります。古い連絡先を使い続けると、重要な案内が届かないだけでなく、退職済みの担当者へ情報を送る危険もあります。
すべての顧客情報を定期的に一括確認するのは負担が大きいため、商談開始、契約更新、問い合わせ発生、定期面談など、顧客との接点が発生したタイミングで確認する運用が有効です。重要顧客や長期契約の顧客については、一定期間ごとに確認する方法もあります。
各情報の最終確認日や最終更新日を記録し、長期間更新されていない顧客を抽出できるようにします。単に最終編集日を見るだけでは、自動処理による更新と担当者による内容確認を区別できないため、「顧客情報確認日」のような専用項目を設けることも検討してください。
3.5 データの入力元が明確か
CRMには、担当者による手入力、名刺管理、Webフォーム、会計システム、問い合わせシステム、商品利用データなど、複数の経路から情報が登録されることがあります。入力元が増えるほど情報は集まりやすくなりますが、同じ項目を複数のシステムが更新すると、正しい値が上書きされる危険があります。
例えば、顧客の正式な会社名は会計システム、営業上の表示名はCRM、配信停止状況はメール配信システムを正式な情報源とするなど、項目ごとに管理元を決めます。CRMで編集できる項目と、連携先から参照するだけの項目を分けることも重要です。
どのシステムから、いつ、どの項目が更新されたかを確認できる状態にすると、誤ったデータが登録された際に原因を追跡しやすくなります。連携を追加する際は、取得できる情報だけでなく、更新権限や同期方向まで確認してください。
4. 顧客情報の設計を確認するチェックリスト
CRMでは、会社、人物、商談、契約、活動など、性質の異なる情報を適切に分けて管理する必要があります。すべての情報を一つの顧客画面へ直接入力すると、現在の状態と過去の履歴が混在し、顧客との関係を正確に把握できなくなります。
設計を見直す際は、画面の見た目や入力項目の数だけでなく、情報同士がどのように関連付けられているかを確認します。誰が、どの会社に所属し、どの商談や契約に関わり、どのような活動が行われたのかを追跡できる構造が必要です。
4.1 法人と担当者が分けて管理されているか
法人向け事業では、一つの会社に複数の担当者が所属し、それぞれが異なる役割を持っています。会社の住所、業種、従業員規模などの法人情報と、担当者の氏名、部署、役職、連絡先などの人物情報を分けて管理すると、組織変更や担当者異動へ対応しやすくなります。
人物情報だけで顧客を管理している場合、同じ会社に所属する複数の担当者が別々の顧客として登録される可能性があります。その結果、会社全体の商談、売上、問い合わせ、契約関係をまとめて確認できません。
会社と担当者を分けたうえで、担当者がどの会社に所属し、どの商談や契約に関係しているかを関連付けます。担当者が異動した場合も、人物情報を削除して作り直すのではなく、所属履歴を残せる構造が望まれます。
4.2 顧客と商談が分けて管理されているか
一人の顧客や一つの企業が、複数の商品を検討したり、時期を変えて再び商談を行ったりすることがあります。顧客情報と商談情報を同じ項目で管理すると、新しい商談が始まるたびに過去の金額、段階、受注予定日などが上書きされます。
顧客には、氏名、会社、連絡先、属性など継続的に利用する情報を保存し、商談には、検討商品、金額、段階、予定日、担当者、結果など、その販売活動に固有の情報を保存します。これにより、同じ顧客が過去に何を検討し、どのような結果になったかを確認できます。
顧客の状態と商談の状態も分けて考える必要があります。顧客は既存顧客であっても、新商品については新しい商談が進行している場合があります。一つの状態項目だけで両方を表現しようとすると、正確な管理ができません。
4.3 商談と契約が分けて管理されているか
商談は、顧客へ商品やサービスを提案し、購入意思を確認するまでの販売活動です。一方、契約は、受注後に合意された商品、金額、契約期間、更新条件などを管理する情報です。両者を同じものとして扱うと、受注後の変更や更新を管理しにくくなります。
受注済みの商談画面だけで契約を管理している場合、更新契約、追加契約、契約内容の変更、解約などが発生した際に、元の商談情報を上書きすることになります。過去にどのような条件で受注し、その後契約がどう変化したのかを確認できなくなります。
受注時に商談情報から契約情報を自動作成し、必要な項目を引き継ぐ仕組みを設けると、入力漏れや転記ミスを減らせます。商談と契約を分けたうえで関連付けることで、販売活動と契約後の関係を一続きで確認できます。
4.4 活動履歴が顧客へ関連付けられているか
電話、メール、面談、提案、問い合わせなどの活動を、担当者の日報や個人の予定だけとして保存すると、顧客単位で過去の経緯を確認できません。担当者が不在または異動した際に、別の担当者が顧客との関係を把握できなくなります。
活動履歴は、会社、担当者、商談、契約など、関係する情報へ関連付けます。例えば、価格交渉の面談は対象となる商談へ、契約後の利用確認は対象となる契約や顧客へ関連付けることで、目的別に履歴を確認できます。
活動内容だけでなく、活動の目的、確認できた事項、顧客の反応、次回行動、期限も残します。単なる実施記録ではなく、次の担当者が状況を理解して対応を続けられる情報にすることが重要です。
4.5 現在値と履歴を分けて保存しているか
顧客区分、契約状態、担当部署、商談段階などを現在の値だけで管理すると、いつ、どのような理由で状態が変わったのか確認できません。例えば顧客区分を「一般」から「優良」へ上書きした場合、以前の状態や変更時期が残らなければ、優良化した要因を分析できません。
現在の状態は、日常業務で素早く確認できるように一つの項目へ表示しつつ、変更前の値、変更後の値、変更日、変更者、変更理由を履歴として保存します。特に契約状態や商談段階など、分析や監査に利用する情報は履歴管理が重要です。
履歴を保存することで、顧客が継続利用へ至った過程、解約前に発生していた変化、商談が停滞した期間などを分析できます。ただし、すべての項目の変更履歴を同じ重要度で保存すると情報量が増えるため、業務判断や分析に必要な項目を選定してください。
5. 営業プロセスを確認するチェックリスト
営業部門でCRMを活用するには、担当者ごとの経験や感覚だけに依存せず、共通の商談工程を定義する必要があります。商談段階を統一することで、案件の進行状況、売上予測、支援が必要な商談を組織全体で把握しやすくなります。
ただし、「初回接触」「提案中」「検討中」といった名称だけを作っても、各段階へ進む条件や必要な行動が明確でなければ、担当者ごとに異なる使い方になります。段階の名称、移行条件、必要情報、次回行動、停滞基準を一つの流れとして設計することが重要です。
5.1 商談段階の移行条件が明確か
「提案中」「検討中」「確度が高い」といった表現は、担当者の主観によって解釈が変わります。営業担当者が提案資料を作成した時点を「提案中」とする場合もあれば、顧客へ説明した後を「提案中」とする場合もあり、同じ段階でも実際の進行状況が異なります。
商談段階の移行条件は、営業担当者の感覚ではなく、顧客側で確認できた事実を基準にします。顧客との会話が完了した、課題と優先度を確認した、提案内容を説明した、購入意思を確認したなど、第三者が見ても判断できる条件にしてください。
移行条件を統一すると、売上予測の精度が上がり、担当者間で商談を比較しやすくなります。ただし、営業活動が複雑な場合でも段階を細かく増やしすぎると更新負担が大きくなるため、実際の判断や行動が変わる地点を基準に設定します。
| 商談段階 | 移行条件の例 |
|---|---|
| 初回接触 | 顧客との会話や面談が完了した |
| 課題確認 | 顧客の課題、優先度、検討背景を確認した |
| 提案準備 | 提案に必要な条件と関係者を確認した |
| 提案済み | 顧客へ提案内容を説明した |
| 条件調整 | 金額、範囲、導入条件を協議している |
| 契約手続き | 顧客の購入意思が確認され、手続きが開始された |
5.2 各段階の必須情報が決まっているか
商談が進むにつれて、決裁者、予算、導入時期、顧客課題、競合、契約条件など、必要な情報が増えていきます。各段階で何を確認すべきかが決まっていなければ、段階だけが更新され、判断に必要な情報が登録されない状態になります。
一方で、初回接触の時点からすべての情報を必須にすると、顧客へまだ確認できていない内容まで入力する必要が生じます。担当者が仮の情報を登録したり、段階を更新しなくなったりする原因になるため、商談の進行に合わせて必要項目を追加します。
例えば、課題確認の段階では顧客課題と優先度、提案段階では提案商品と金額、契約手続きでは決裁者と契約予定日を必須にするなど、段階ごとに入力条件を設定します。必須情報は、担当者を管理するためではなく、次の判断や支援に必要な情報へ限定してください。
5.3 次回行動が必ず登録されているか
商談段階が登録されていても、次に何を行うのかが決まっていなければ、案件は進みません。「提案済み」という状態だけでは、顧客からの回答を待っているのか、追加資料を送るのか、社内確認が必要なのかを判断できません。
進行中の商談には、次回行動、実施期限、担当者を設定します。必要に応じて、行動の目的や完了条件も記録すると、担当者以外の人でも状況を理解できます。次回行動の期限が過ぎた場合は、一覧や通知で確認できるようにします。
次回行動が登録されていない商談は、停滞候補として抽出してください。営業会議では、過去に行った活動を報告するだけでなく、次に何を行い、何を確認すれば商談が進むのかを中心に確認することが重要です。
5.4 商談停滞の基準が決まっているか
商談が停滞しているかどうかを担当者の感覚だけで判断すると、対応が必要な案件を見落とす可能性があります。ただし、すべての商談を同じ日数で判定することも適切ではありません。商品、顧客規模、商談段階によって、通常必要となる期間が異なるためです。
初回接触後は7日、提案後は14日、契約手続きでは5日など、段階ごとに停滞基準を設定します。高額商談や社内承認が複雑な顧客については、商品や顧客区分に応じて基準を変える方法もあります。
停滞を検知した後の行動も決めておく必要があります。顧客へ連絡する、決裁者を確認する、提案内容を見直す、責任者へ相談するなど、確認事項と対応責任者を設定します。停滞件数を表示するだけでなく、商談を再び進めるための行動へつなげてください。
5.5 失注理由が改善へ使われているか
失注理由をCRMへ登録していても、「価格」「競合」「時期」といった大きな分類だけでは、具体的な改善につながりません。価格が理由とされていても、顧客の予算が不足していたのか、提供価値を伝えられなかったのか、競合より価格差が大きかったのかによって、必要な対応は異なります。
分析に利用する主要な失注理由は選択式にし、必要に応じて原因を細分化します。そのうえで、商談の背景や顧客の発言を補足として残してください。選択肢が多すぎると担当者が迷うため、実際の失注事例を基に定期的に見直します。
失注理由は入力して終わりではなく、商品、価格、提案方法、対象顧客、営業教育の改善へ戻す必要があります。特定の商品で機能不足が多い、特定の流入経路で予算不一致が多いなど、条件別に分析すると、営業活動だけでなくマーケティングや商品開発の改善にも利用できます。
6. 営業担当者の利用状況を確認するチェックリスト
CRMが定着しない場合、営業担当者の意識や入力姿勢だけを問題にしてはいけません。入力に時間がかかる、必要な情報が見つからない、入力したデータが会議で使われない、表計算ソフトへ同じ内容を再入力しているなど、運用や設計に原因がある可能性があります。
担当者へのアンケートだけでなく、実際に顧客情報を確認し、商談を更新し、会議資料を作るまでの操作を観察してください。日常業務の流れに沿って、不要な操作、重複入力、画面移動を減らすことが、利用定着につながります。
6.1 日常業務の中でCRMを使えるか
営業担当者がCRMを日常的に利用するには、顧客確認、商談管理、予定確認、活動記録、会議準備など、主要な業務をCRM内で行える必要があります。入力するときだけCRMへログインし、その後の業務を別のツールで行う状態では、CRMは負担として認識されます。
担当者が最初に見る画面には、自分の商談、今日の予定、期限が近い活動、未対応の顧客、停滞している案件など、行動に必要な情報を表示します。必要な情報を確認するまでに複数の画面を移動する場合は、初期画面や一覧項目を見直してください。
ただし、すべての業務をCRMだけで完結させる必要はありません。メールやカレンダーなど、日常的に利用するツールと連携し、担当者が自然な作業の流れの中でCRM情報を確認・更新できる状態を目指します。
6.2 同じ情報を複数回入力していないか
営業日報、会議資料、売上予測表、個人の案件管理表、CRMへ同じ商談情報を入力している場合、担当者の負担が増えるだけでなく、データの不一致も発生します。更新する場所によって金額や商談段階が異なると、どの情報が正しいのか分からなくなります。
CRMへ登録されたデータから日報、会議用一覧、売上予測を作成できるようにし、同じ情報を再入力しなくても業務が進む状態を整えます。会議のために表計算ファイルへ転記している場合は、CRMレポートや出力形式が会議の目的に合っているか確認してください。
既存の表計算ファイルをすぐに廃止できない場合は、CRMと表計算ファイルの役割を明確にします。どちらが正式な情報源か、誰が更新するか、どの情報だけを表計算で扱うかを決めずに併用すると、重複管理が継続します。
6.3 入力に必要な時間を計測しているか
「CRMへの入力が大変」という意見を、担当者の感覚だけで判断してはいけません。新しい顧客の登録、面談後の活動記録、商談段階の更新など、代表的な操作に何分かかっているかを実際に計測します。
時間がかかっている場合は、入力項目が多いのか、選択肢を探しにくいのか、同じ内容を複数画面へ入力しているのかを確認します。自動入力、初期値、選択式、一括更新、関連情報の自動作成などを利用し、入力操作を減らしてください。
入力時間を短縮するために必要な項目まで削除すると、データ品質が下がる可能性があります。入力時間だけでなく、入力後の修正件数、未入力率、仮の値の割合も確認し、速さと正確さの両方を評価する必要があります。
6.4 携帯端末から必要な操作ができるか
外出や顧客訪問が多い営業担当者は、移動中や面談直後に情報を確認・更新する場合があります。パソコンを開けるまで入力を先送りすると、面談内容を忘れたり、次回対応が登録されないままになったりする可能性があります。
携帯端末では画面が小さいため、パソコンと同じ数の項目を表示すると操作しにくくなります。面談直後には、活動の要点、顧客の反応、次回行動、期限など、忘れると影響が大きい情報だけを登録し、詳細は後から補える方法も有効です。
閲覧についても、顧客の連絡先、直近の活動、未解決の問題、商談状況など、訪問前に必要な情報へすぐ到達できるか確認します。通信状況が不安定な場所で利用する場合は、保存失敗時の表示や再送方法も重要です。
6.5 CRM入力が会議で利用されているか
担当者がCRMへ入力した情報が、営業会議や案件支援、売上予測に利用されなければ、入力する意味を感じにくくなります。管理者が別の表計算資料を求めると、担当者はCRMよりも会議資料の更新を優先するようになります。
営業会議では、原則としてCRMの画面やレポートを直接使用し、商談段階、次回行動、停滞状況を確認します。情報が更新されていない商談については、別資料で補うのではなく、CRM上で状況を確認できないこと自体を課題として扱います。
ただし、入力されていない担当者を責めるだけでは改善しません。会議で必要な情報が入力項目として定義されているか、更新に時間がかからないか、会議前以外にも利用価値があるかを確認し、入力と利用が一つの業務としてつながる状態を作ります。
7. マーケティング活用を確認するチェックリスト
CRMとマーケティング活動を連携すると、顧客の属性、広告やコンテンツへの反応、営業商談、購入、契約後の状況を一つの流れとして確認できます。どの施策から顧客が生まれ、どのような行動を経て売上につながったかを把握することで、施策の改善や営業との連携に利用できます。
ただし、配信数、閲覧数、見込み顧客数だけを増やしても、事業成果につながったとは限りません。商談化率、受注率、売上、利益、顧客維持まで追跡し、マーケティング活動が顧客獲得と継続へどのように貢献しているかを確認する必要があります。
7.1 流入経路が正しく記録されているか
顧客が最初に企業を知った経路として、広告、検索、展示会、紹介、資料請求、SNS、セミナーなどを記録します。流入経路が正しく残っていなければ、どの施策が見込み顧客や売上につながったのか判断できません。
担当者が自由記述で入力すると、「Web広告」「ウェブ広告」「広告」など表記が分かれ、正確に集計できなくなります。可能な範囲でWebフォームや広告情報から自動取得し、手入力が必要な場合は選択式を利用してください。
顧客との接点が複数ある場合は、最初に企業を知った接点と、問い合わせや商談の直前に影響した接点を分けて保存すると、施策をより適切に評価できます。最初の接点だけで成果を判断すると、検討を進めたコンテンツやイベントの影響を見落とす可能性があります。
7.2 顧客の同意状況を管理しているか
メール、電話、案内などのマーケティング活動を行う場合は、顧客がどの連絡に同意しているか、いつ、どの経路で同意を取得したかを管理する必要があります。単にメールアドレスが登録されているだけでは、案内を送信できるとは限りません。
配信停止の希望があった顧客へ再びメールを送らないように、CRMとメール配信システムの同意情報を連携します。担当者がCRMと配信システムの両方を手作業で更新する方法では、更新漏れや反映の遅れが発生しやすくなります。
同意状況は、同意済みかどうかだけでなく、対象となる連絡方法、取得日、取得経路、撤回日を確認できるようにします。顧客の同意情報を利用する際は、適用される法令や社内規程に沿って管理してください。
7.3 顧客分類が施策へ利用されているか
CRMでは、業種、会社規模、地域、関心商品、閲覧行動、購入履歴、契約状態などを基に顧客を分類できます。顧客分類を活用すると、対象に合った案内や営業連絡を行いやすくなります。
ただし、分類を細かく作ること自体を目的にしてはいけません。多数の分類を設定しても、すべての顧客へ同じ内容を送っているのであれば、分類情報は活用されていません。分類ごとに配信内容、提案商品、連絡時期、担当部門を変えられるかを確認します。
また、分類条件が古くなっていないかも定期的に見直します。顧客の関心や契約状態が変化しているのに、過去の分類が残っていると、現在の状況に合わない案内を送る可能性があります。可能であれば、最新の行動や契約情報を基に自動更新します。
7.4 見込み顧客の評価基準が明確か
資料の閲覧、メールのクリック、価格ページの訪問、イベント参加などの行動を基に、営業が連絡すべき見込み顧客の優先順位を決めることがあります。点数を使って評価する場合は、どの行動に何点を付け、何点になったら営業へ引き渡すのかを明確にします。
ただし、行動点数が高いだけで、購入可能性が高いとは限りません。何度も資料を閲覧していても、対象外の業種、対応地域外の企業、競合調査、学生などであれば、営業の優先度は低くなります。行動情報と企業属性の両方を組み合わせて判断する必要があります。
営業へ引き渡す際は、合計点だけでなく、どのページを見たか、どの資料を取得したか、どのイベントへ参加したかを確認できるようにします。営業担当者が関心の背景を理解できれば、顧客に合った連絡を行いやすくなります。
7.5 マーケティング施策を売上まで追跡できるか
問い合わせ数、資料請求数、広告のクリック数だけでは、マーケティング施策が事業へどの程度貢献したか判断できません。多くの見込み顧客を獲得していても、商談や受注につながっていなければ、対象顧客や施策内容を見直す必要があります。
見込み顧客、会社、商談、受注を関連付け、施策ごとの商談化率、受注率、売上、利益を確認できるようにします。既存顧客向けの施策では、追加購入、契約更新、解約防止への影響も評価対象になります。
評価期間は、実際の商談期間に合わせて設定してください。施策実施後すぐに受注だけを確認すると、検討期間が長い商品では正しい評価ができません。短期的な反応と中長期的な売上貢献を分けて確認し、施策の継続、改善、停止を判断します。
8. カスタマーサクセスと顧客維持を確認するチェックリスト
CRMは、契約を獲得するまでの営業活動だけを管理する仕組みではありません。契約後に顧客がどのようにサービスを利用し、どのような成果を得ているかまで把握することで、継続利用や追加提案、解約防止につなげることができます。受注後の情報が顧客支援部門だけに残り、CRMへ反映されていない場合、営業担当者は顧客の満足度や不満、利用上の問題を把握できません。
顧客維持を改善するには、顧客から問い合わせや解約の連絡が来るまで待つのではなく、利用の停滞、担当者との接触減少、未解決の問題、更新意向の変化などを早い段階で捉える必要があります。契約情報、利用状況、問い合わせ履歴、顧客が期待する成果をまとめて確認できる状態を作り、問題が深刻になる前に対応できる運用を整えます。
8.1 顧客の利用状況を確認できるか
顧客がサービスを継続的に利用しているかを判断する際は、契約金額や契約期間だけでなく、実際の利用状況を確認する必要があります。オンラインサービスであればログイン回数や主要機能の利用状況、小売や卸売であれば購入頻度や購入金額、研修やコミュニティ型サービスであれば参加回数や活動状況など、事業に合った情報をCRMへ集約します。
ただし、利用回数が多いからといって、必ずしも顧客が十分な価値を得ているとは限りません。操作に迷って何度もログインしている場合や、特定の機能だけを繰り返し使用している場合もあります。単純な利用回数だけで評価せず、契約時に顧客が達成したいと考えていた目標と、現在の利用状況を結び付けて確認することが重要です。
例えば、業務時間の短縮を目的として導入した顧客であれば、機能の利用回数ではなく、作業時間や処理件数がどのように変化したかを確認します。顧客ごとの目標、達成状況、次に必要な支援を記録することで、利用量ではなく成果を基準にしたカスタマーサクセスが可能になります。
8.2 顧客状態の判定基準が決まっているか
顧客を「良好」「注意」「危険」などの状態に分類する場合、担当者の経験や感覚だけで判断すると、同じ状況でも評価が異なります。担当者によって危険と判断する時期がずれると、対応の優先順位を統一できず、支援が必要な顧客への対応が遅れる可能性があります。
そのため、利用状況、問い合わせ、担当者との関係、成果、契約更新など、複数の要素を組み合わせて判定基準を作ります。単独の数値だけで判断するのではなく、複数の変化が重なっているかを確認することが重要です。
| 判定要素 | 良好と判断できる例 | 危険と判断できる例 |
|---|---|---|
| 利用状況 | 主要機能を継続的に利用している | 利用回数や利用者数が急激に減少している |
| 問い合わせ | 問題が解決され、対応後の確認も完了している | 重要な問題が長期間未解決になっている |
| 担当者との関係 | 定期的な連絡があり、担当者から返信がある | 連絡しても返信がなく、面談も実施できない |
| 成果 | 導入目的に沿って成果が進んでいる | 成果を確認できず、利用目的も曖昧になっている |
| 契約更新 | 継続意向が確認でき、更新準備が進んでいる | 更新判断が保留され、決裁者の反応も不明である |
判定基準を設定した後は、どの状態になったときに誰が対応するかも決めておきます。「注意」になった場合は担当者が状況を確認し、「危険」になった場合は責任者を含めて対応方針を決めるなど、顧客状態と実際の行動を結び付ける必要があります。また、すべての顧客へ同じ基準を適用するのではなく、契約規模、利用目的、導入段階に応じて基準を調整することも重要です。
8.3 契約更新日を前もって管理しているか
契約更新の直前になって初めて顧客へ連絡しても、利用上の不満や成果不足が見つかった場合に、改善する時間が残されていません。顧客側でも予算申請や社内承認が必要なため、更新直前の提案では判断に間に合わないことがあります。
契約期間や顧客の社内手続きに応じて、更新日の90日前、60日前、30日前など、複数の確認時点を設定します。90日前には利用状況と成果を確認し、60日前には顧客の継続意向や未解決課題を把握し、30日前には契約条件や手続きを確認するなど、各時点で行う内容を明確にすると対応漏れを防げます。
顧客維持においては、更新前の対応だけでなく、契約開始直後の支援も重要です。導入初期に利用方法や目標が整理されていないと、その後の利用が定着せず、更新時に初めて問題が明らかになります。契約開始後の初期設定、教育、目標確認、利用開始状況の確認までを一連の活動としてCRMで管理してください。
8.4 解約理由が商品改善へ戻されているか
解約が発生した際は、「顧客都合」や自由記述だけで記録するのではなく、価格、機能不足、利用機会の減少、成果不足、組織変更、競合への乗り換え、担当者対応など、分析可能な分類を設定します。分類だけでは具体的な背景が分からないため、選択式の解約理由と自由記述の補足を組み合わせると、集計のしやすさと情報の具体性を両立できます。
また、表面的な理由と実際の原因が異なる場合もあります。顧客が価格を理由に解約した場合でも、実際にはサービスの価値を十分に実感できていなかった可能性があります。最初に示された理由だけを記録するのではなく、利用状況、問い合わせ履歴、導入目的、過去の対応内容も確認し、解約に至った経緯を整理してください。
解約情報は、顧客支援部門だけで保有せず、営業、商品開発、マーケティングなどへ共有します。特定の機能不足が繰り返し解約につながっている場合は商品改善へ、導入目的と実際の利用方法に差がある場合は初期支援の改善へ、獲得時の説明と実際のサービスに差がある場合は営業資料やマーケティング表現の見直しへ反映します。
8.5 問い合わせ履歴が営業から見えるか
顧客が重大な問題を抱えているにもかかわらず、営業担当者がその状況を知らずに追加購入や契約拡大を提案すると、顧客から「自社の状況を理解していない」と受け取られ、信頼を損なう可能性があります。反対に、過去の問題が解決され、満足度が回復している場合は、適切なタイミングで追加提案を行うことができます。
問い合わせ管理システムとCRMを連携し、未解決の問い合わせ件数、重要度、問い合わせの種類、最終対応日、現在の対応状況などを営業担当者が確認できるようにします。特に重大な障害、契約に関する不満、繰り返し発生している問題については、顧客画面上で分かりやすく表示する必要があります。
ただし、問い合わせの詳細な会話内容や個人情報を、すべての利用者へ公開する必要はありません。営業担当者が顧客状態を判断するために必要な要約と対応状況を共有し、詳細情報は権限を持つ担当者だけが閲覧できるようにするなど、情報共有と機密管理のバランスを取ります。
9. 自動化を確認するチェックリスト
CRMの自動化を適切に利用すると、情報の転記、担当者の割り当て、期限通知、メール送信などの繰り返し作業を減らし、対応漏れや入力ミスを防ぐことができます。一方で、誤った条件や古いデータを基に自動処理を実行すると、関係のない顧客へ連絡したり、不要な作業を大量に作成したりする危険があります。
自動化を導入する前に、現在の手作業が何のために行われているのか、どの条件で実行され、どのような例外があるのかを整理してください。作業をそのまま自動化するのではなく、不要な手順を減らし、判断が必要な部分と機械的に処理できる部分を分けることが重要です。
9.1 繰り返し作業を把握しているか
まず、担当者が日常的に行っている作業を確認します。例えば、複数システム間の情報転記、期限が近い商談の確認、契約更新日の通知、担当者へのメール送信、定型的な活動記録の作成などが対象になります。
自動化に適しているのは、実行回数が多く、条件が明確で、担当者による判断がほとんど必要ない作業です。同じ情報を毎日別のシステムへ入力する作業や、特定の日付になったら通知する作業は、自動化による効果を得やすいといえます。
一方、頻度が低い作業や、顧客ごとに判断が大きく異なる作業を無理に自動化すると、例外処理が増え、かえって管理が複雑になります。作業時間だけでなく、誤処理が発生した場合の影響も考慮し、自動化する範囲を決めてください。
9.2 自動割り当ての条件が明確か
CRMでは、顧客の地域、商品、企業規模、問い合わせ内容、流入経路などに応じて、営業担当者や顧客支援担当者を自動的に割り当てることがあります。自動割り当てを行うことで、担当者を決める時間を短縮し、対応開始を早めることができます。
ただし、複数の条件に該当した場合の優先順位が決まっていないと、意図しない担当者へ割り当てられる可能性があります。例えば、地域条件と商品条件の両方に該当した場合、どちらを優先するのかを明確にします。また、担当者が休暇中、退職済み、対応件数の上限に達している場合の代行先も設定してください。
割り当てが完了したことだけでなく、その後に実際の対応が行われているかも確認する必要があります。一定時間以内に初回対応が行われていない場合は、責任者へ再通知したり、別の担当者へ再割り当てしたりする仕組みを用意すると、割り当て後の放置を防げます。
9.3 自動通知が多すぎないか
CRMから送られる通知が多すぎると、担当者は内容を一つずつ確認しなくなり、本当に重要な通知まで見落とすようになります。すべての更新や活動を通知するのではなく、担当者が具体的な行動を取る必要がある情報を優先することが重要です。
顧客対応期限、重要商談の停滞、契約更新、重大な問い合わせ、承認待ちなど、放置した場合の影響が大きい通知は個別に送ります。一方、情報更新、参考データ、軽微な変更など、すぐに対応する必要がない内容は、日次または週次のレポートへまとめる方法が適しています。
通知を設定した後は、送信件数だけでなく、通知後に担当者が行動しているかを確認してください。無視される通知が多い場合は、通知先、送信条件、内容、タイミングを見直し、重要度が一目で分かる表現へ改善します。
9.4 自動メールの内容が顧客状態に合っているか
自動メールは、多数の顧客へ効率的に案内できる一方、顧客の現在の状況に合わない内容を送ると、企業への信頼を損なう可能性があります。すでに購入した商品を再び案内する、解約済みの顧客へ利用促進メールを送る、重大な問い合わせが未解決の顧客へ販促メールを送るといった問題が代表的です。
送信条件を設定する際は、対象条件だけでなく、送信しない顧客を決める除外条件も重要です。契約状態、購入履歴、問い合わせ状況、配信停止の希望、担当者による個別対応、過去のメール反応などを確認し、現在の顧客状態に合わない配信を防ぎます。
また、送信前に使用される顧客データが最新か、担当者名や契約内容が正しく差し込まれるかも確認してください。大量配信を開始する前に少数のテスト対象へ送信し、内容、リンク、表示、対象条件を確認する運用を設けると、誤配信の危険を減らせます。
9.5 自動化の失敗を検知できるか
自動処理は、一度設定すれば必ず動き続けるものではありません。外部サービスとの接続切れ、権限変更、入力データの不備、設定変更などにより、処理が停止したり、一部のデータだけが処理されなかったりすることがあります。
自動化ごとに、処理件数、成功件数、失敗件数、最終実行日時、停止状態を確認できる画面を用意します。通常より処理件数が急に減少した場合も、完全なエラーが表示されていなくても問題が発生している可能性があります。
失敗を検知した場合の通知先、確認担当者、復旧手順、手動での代替対応も事前に決めてください。エラーを修正するだけでなく、処理されなかった対象を特定し、再実行できる状態にしておくことが重要です。
10. レポートと分析を確認するチェックリスト
CRMレポートは、作成した数や表示する指標の多さではなく、実際の意思決定や行動改善に使われているかによって評価する必要があります。多くの数字を一つの画面へ表示しても、何が重要なのか分からなければ、変化や問題を見落としやすくなります。
利用者の役割ごとに必要な指標を限定し、現状の確認、原因の分析、次の行動までつながるレポートを設計します。また、レポートの数字を信頼できるように、データの入力方法や指標の定義を統一することも重要です。
10.1 レポートの利用者が明確か
経営者、営業責任者、現場担当者では、必要とする情報と確認する頻度が異なります。すべての利用者へ同じレポートを提供すると、情報が多すぎたり、必要な詳細が不足したりします。
経営者には、売上予測、受注状況、顧客維持率、解約傾向など、事業全体の判断に必要な情報を表示します。営業責任者には、商談の進行状況、停滞案件、担当者別の活動、目標との差など、チームの管理に必要な情報を提供します。担当者には、自分が対応すべき商談、期限が近い活動、未対応の顧客など、当日の行動につながる情報を優先します。
レポートを作成する前に、誰が、どの場面で、どの判断を行うために使用するのかを明確にしてください。利用目的が曖昧なまま作成すると、数字を表示するだけで、実際には使われないレポートになりやすくなります。
10.2 数字の定義が統一されているか
「商談数」「顧客数」「受注率」「売上」といった一般的な指標でも、部門によって対象や計算方法が異なる場合があります。例えば、受注率を商談作成数に対する受注数で計算する部門と、提案済み商談に対する受注数で計算する部門では、同じ名称でも異なる数字になります。
指標ごとに、名称、意味、計算式、対象期間、対象データ、除外条件、データ元、更新頻度を定義書へ記載します。キャンセル案件、テストデータ、重複顧客、失注後に再開した商談などをどのように扱うかも決めておく必要があります。
定義を作成するだけでなく、CRM上のレポート設定と一致しているかを定期的に確認してください。設定変更によって計算方法が変わった場合は、利用者へ通知し、過去の数字と単純比較できるかどうかも説明する必要があります。
10.3 現在値だけでなく変化を確認できるか
現在の売上や商談数だけを見ても、状況が改善しているのか悪化しているのかは判断できません。前月、前年同期、計画値、目標値などと比較し、数値がどの方向へ変化しているかを確認します。
数値に大きな変化があった場合は、全体の数字だけで判断せず、商品、担当者、地域、顧客規模、流入経路、商談段階などへ分けて原因を探します。例えば、商談数が増えていても、特定の流入経路から質の低い商談が増えている場合は、受注率が低下する可能性があります。
一時的な変化と継続的な傾向を区別することも重要です。単月の数字だけで結論を出さず、一定期間の推移を確認し、施策、季節要因、市場環境、データ入力方法の変更などと照らし合わせて分析します。
10.4 レポートから行動を決められるか
「売上が低い」「解約率が高い」「未対応件数が多い」と表示するだけでは、担当者は次に何を行うべきか判断できません。レポートは問題を示すだけでなく、具体的な対応対象へつながる構成にする必要があります。
例えば、売上予測が目標を下回っている場合は、停滞している商談、次回行動が未設定の案件、長期間更新されていない商談を一覧で確認できるようにします。解約率が上昇している場合は、更新が近い危険顧客や、利用が減少している顧客へ移動できるようにします。
各レポートについて、数字が一定の基準を超えた場合に、誰が、どの対象へ、どのような対応を行うのかを決めておくと、分析結果を実際の改善へ結び付けやすくなります。
10.5 利用されていないレポートを削除しているか
利用者の要望に応じてレポートを作成し続けると、似た内容のレポートが増え、どれが正式な数字なのか分からなくなります。古い条件のレポートが残っていると、会議や資料で異なる数字が使われる原因にもなります。
レポートごとに最終閲覧日、利用者、利用目的、作成者を確認し、長期間使用されていないものは停止または削除します。ただし、すぐに削除すると過去の確認ができなくなる場合があるため、一定期間は非表示または保管状態にしてから削除すると安全です。
経営会議や営業会議で使用する正式なレポートには、責任者、データの定義、更新履歴を設定してください。似たレポートを利用者が自由に複製できる場合でも、正式版が明確に分かる名称や保存場所を決めておくことが重要です。
11. CRM分析のコード例
CRMの標準レポートだけでは、重複、未更新顧客、商談停滞、入力率などを細かく確認できない場合があります。
ここでは、CRMから出力したデータを想定したSQLとPythonの簡単な例を紹介します。実際に使用する際は、利用中のデータベースと項目名に合わせて変更してください。
11.1 重複しているメールアドレスを抽出する
同じメールアドレスが複数の顧客へ登録されている場合、重複の可能性があります。
共有メールアドレスや家族利用もあるため、自動で削除せず、担当者が内容を確認します。
重複候補を確認するSQL
SELECT
LOWER(TRIM(email)) AS メールアドレス,
COUNT(*) AS 登録件数
FROM contacts
WHERE email IS NOT NULL
AND TRIM(email) <> ''
GROUP BY LOWER(TRIM(email))
HAVING COUNT(*) > 1
ORDER BY 登録件数 DESC;
11.2 未更新顧客を抽出する
長期間更新されていない顧客は、連絡先や担当者が古くなっている可能性があります。
重要顧客や進行中商談がある顧客を優先して確認します。
一年以上更新されていない顧客を確認するSQL
SELECT
customer_id AS 顧客番号,
customer_name AS 顧客名,
owner_name AS 担当者,
updated_at AS 最終更新日
FROM customers
WHERE updated_at < CURRENT_DATE - INTERVAL '365 days'
ORDER BY updated_at;
11.3 停滞商談を抽出する
進行中でありながら、最終活動から一定期間が経過し、次回行動が設定されていない商談を抽出します。
段階によって停滞基準が異なる場合は、段階別の条件を追加します。
停滞商談を確認するSQL
SELECT
opportunity_id AS 商談番号,
opportunity_name AS 商談名,
stage AS 商談段階,
owner_name AS 担当者,
last_activity_date AS 最終活動日,
next_action_date AS 次回行動日
FROM opportunities
WHERE status = '進行中'
AND last_activity_date < CURRENT_DATE - INTERVAL '30 days'
AND (
next_action_date IS NULL
OR next_action_date < CURRENT_DATE
)
ORDER BY last_activity_date;
11.4 担当者別の入力完了率を計算する
入力完了率だけで担当者を評価してはいけませんが、項目設計の問題を発見する材料になります。
特定項目だけ未入力が多い場合は、その項目の必要性や説明を見直します。
Pythonによる入力完了率の計算
import pandas as pd
商談 = pd.read_csv("opportunities.csv")
必須項目 = [
"顧客番号",
"商談段階",
"予定金額",
"予定受注日",
"次回行動",
]
商談["入力済み項目数"] = 商談[必須項目].notna().sum(axis=1)
商談["入力完了率"] = (
商談["入力済み項目数"] / len(必須項目)
)
担当者別 = (
商談.groupby("担当者", as_index=False)
.agg(
商談数=("商談番号", "count"),
平均入力完了率=("入力完了率", "mean"),
)
)
担当者別["平均入力完了率"] = (
担当者別["平均入力完了率"] * 100
).round(1)
print(担当者別)
11.5 顧客状態の変化を確認する
現在の状態だけでなく、過去の状態履歴を使い、注意状態から危険状態へ移行した顧客を抽出します。
状態変化と解約の関係を確認すると、早期対応の基準を改善できます。
Pythonによる状態変化の抽出
import pandas as pd
履歴 = pd.read_csv(
"customer_status_history.csv",
parse_dates=["変更日"]
)
履歴 = 履歴.sort_values(
["顧客番号", "変更日"]
)
履歴["前回状態"] = (
履歴.groupby("顧客番号")["顧客状態"]
.shift(1)
)
危険移行 = 履歴[
(履歴["前回状態"] != "危険")
& (履歴["顧客状態"] == "危険")
].copy()
print(
危険移行[
["顧客番号", "前回状態", "顧客状態", "変更日"]
]
)
12. CRMの操作性を確認するチェックリスト
CRMの操作性は、画面のデザインや機能数だけでは評価できません。実際の業務で担当者が必要な顧客情報へ短時間で到達し、内容を正しく理解したうえで、迷わず登録や更新を行えるかどうかが重要です。高機能なCRMであっても、項目が多すぎたり、画面遷移が複雑だったりすると、入力の遅れや記録漏れが発生しやすくなります。
操作性を改善する際は、新しい機能を追加することだけを考えるのではなく、使われていない項目、重複した入力欄、不要な画面、分かりにくい操作手順を減らすことも検討してください。利用者の作業時間や入力ミスを減らせるかという観点で、日常業務に沿って確認する必要があります。
12.1 役割ごとに画面が最適化されているか
営業、マーケティング、顧客支援、管理部門では、CRMを利用する目的や頻繁に確認する情報が異なります。営業担当者は商談状況、次回の対応予定、受注確度などを重視しますが、マーケティング担当者は顧客属性、流入経路、キャンペーンへの反応などを確認します。顧客支援担当者には、問い合わせ履歴や契約内容、過去の対応状況が必要です。
すべての利用者に同じ画面を表示すると、自分の業務に関係しない項目が増え、必要な情報を探すまでに時間がかかります。また、誤って不要な項目を編集する可能性もあります。そのため、役割ごとに表示画面、入力項目、初期表示される一覧、ダッシュボードを調整し、日常的に使用する情報を優先的に配置します。
ただし、役割別に画面を細かく分けすぎると、設定の管理が複雑になるため注意が必要です。利用者ごとに個別設定を行うのではなく、業務上の役割や部門単位で共通の画面を設計すると、運用しやすくなります。
12.2 項目名が社内用語と一致しているか
CRMに最初から設定されている標準用語が、自社で使用している業務用語と一致するとは限りません。例えば、「リード」「案件」「取引先」「ステージ」といった名称について、部門ごとに異なる意味で理解している場合があります。利用者が項目名の意味を正しく理解できなければ、入力内容にもばらつきが生じます。
そのため、項目名は、利用者が普段の業務で使用している分かりやすい名称へ変更します。ただし、部門ごとの呼び方をそのまま追加し続けると、似た意味の項目が複数作られ、どこへ入力すべきか分からなくなります。
名称を変更する際は、項目の定義、入力対象、利用目的、レポートでの使用方法も整理してください。社内用語集やデータ定義書を作成し、同じ言葉が複数の意味で使われないようにすることが重要です。
12.3 入力例と説明が表示されているか
項目名だけでは、何をどの形式で入力すべきか判断できない場合があります。例えば、「対応状況」という項目があっても、現在の顧客の状態を入力するのか、最後に行った対応内容を入力するのかが明確でなければ、利用者ごとに異なる情報が登録されます。
入力欄の近くには、短い説明、入力例、選択基準などを表示してください。電話番号や日付、企業名など、入力形式を統一する必要がある項目では、正しい形式の例を示すと入力ミスを減らせます。自由記述欄についても、何を書けばよいかを例示することで、情報の質をそろえやすくなります。
長い操作手順書を毎回確認させる方法では、実際の業務中に参照されなくなる可能性があります。基本的な判断材料を画面内に表示し、詳しい説明が必要な場合だけ手順書へ移動できる構成にすると、利用者が迷いにくくなります。
12.4 検索しやすいか
CRMでは、登録する操作だけでなく、必要な情報をすぐに見つけられることも重要です。顧客名の一部、担当者名、電話番号、メールアドレス、商談名、契約番号など、利用者が実際の業務で使用する条件から検索できるか確認してください。
完全一致でしか検索できない場合や、表記の違いによって結果が表示されない場合は、同じ顧客を重複して登録する原因になります。会社名の略称、全角と半角、漢字とカタカナなど、実際に発生する表記の違いも考慮する必要があります。
また、検索結果に必要な情報が十分に表示されているかも確認します。検索結果から顧客の担当者、現在の商談状況、最終対応日などを判断できず、毎回詳細画面を開かなければならない場合は、一覧に表示する項目を見直してください。検索結果を見ただけで次の行動を判断できる状態が理想です。
12.5 エラー内容が理解できるか
入力や保存に失敗した際、「保存できませんでした」「入力内容に誤りがあります」とだけ表示されても、利用者は何を修正すればよいか判断できません。その結果、同じ操作を繰り返したり、入力を諦めたり、管理者へ問い合わせたりすることになります。
エラーが発生した場合は、問題のある項目、必要な入力形式、権限不足、重複データなど、原因を具体的に表示してください。可能であれば、該当する入力欄の近くにエラー内容を表示し、修正方法まで分かるようにします。
同じエラーが多くの利用者に繰り返し発生している場合は、利用者の理解不足だけを原因にしてはいけません。項目名が分かりにくい、入力条件が厳しすぎる、必須項目が多すぎるなど、画面設計そのものに問題がないか確認し、根本的な改善を行う必要があります。
13. CRM運用体制を確認するチェックリスト
CRMを長期間安定して運用するためには、システムを導入するだけでなく、設定、データ、業務ルール、利用者支援を継続的に管理する体制が必要です。導入時に決めた項目や運用方法が、組織変更、新しい商品、営業方法の変化などによって実態と合わなくなることもあります。
特定の詳しい担当者だけに設定や判断を任せている場合、その担当者の異動、退職、長期不在によって運用が止まる可能性があります。属人的な管理を避け、役割、判断基準、変更手順、記録方法を組織として整理することが重要です。
13.1 CRMの責任者が決まっているか
CRMの責任者を決める際は、システム管理者と業務責任者を区別して考える必要があります。システム管理者は、アカウント、権限、項目、画面、外部連携などの技術的な設定を担当します。一方、業務責任者は、CRMを何のために利用するのか、どの段階で何を入力するのか、どのデータを評価に使うのかといった業務上のルールを決定します。
システム管理者だけで運用方針を決めると、設定上は正しくても、現場の業務に合わない仕組みになる可能性があります。反対に、現場の要望だけで変更すると、項目の重複やデータ構造の複雑化が起こります。そのため、技術面と業務面の両方から判断できる体制を作ります。
部門間で意見が分かれた場合に、最終判断を行う責任者も明確にしてください。誰が承認し、誰が実施し、誰が利用者へ通知するのかまで整理しておくと、変更時の混乱を防げます。
13.2 変更申請の手順があるか
利用者から要望が出るたびに新しい項目や機能を追加すると、CRMは徐々に複雑になります。一部の担当者しか使わない項目が増えたり、同じ意味の項目が複数存在したりすると、入力負担が増えるだけでなく、データ分析の信頼性も低下します。
変更を行う前に、その変更が必要な理由、利用する部門、対象となるデータ、既存項目で代用できない理由を確認します。さらに、レポート、外部連携、過去データ、権限設定への影響も確認してください。
新しい項目を追加する際は、同時に不要になった項目を削除または非表示にできないか検討します。変更内容、承認者、実施日、影響範囲を記録しておくことで、後から設定の意図を確認できるようになります。
13.3 操作教育だけでなく業務教育を行っているか
CRM教育では、ログイン方法やボタンの押し方だけを説明しても十分ではありません。利用者が理解すべきなのは、どの業務段階で、どの情報を、どの基準に基づいて入力するかという点です。
例えば、商談ステージを変更する際には、単に選択肢の場所を説明するのではなく、各ステージの判断基準や、次の段階へ進める条件を共有する必要があります。判断基準が統一されていなければ、同じ状況でも担当者によって異なるステージが選択され、売上予測や案件分析が不正確になります。
教育では、実際の顧客や商談に近い事例を使い、正しい入力例と誤った入力例を比較すると効果的です。新入社員への初期教育だけでなく、項目や業務ルールを変更した際にも教育を実施し、変更内容が現場で正しく理解されているか確認してください。
13.4 問い合わせ窓口があるか
操作方法や入力ルールについて質問したい場合に、相談先が明確でなければ、利用者は過去の経験や自己判断で入力するようになります。その結果、同じ項目に異なる種類の情報が登録され、データ品質が低下します。
問い合わせ窓口を設け、操作上の問題、業務ルールに関する質問、不具合、改善要望を区別して受け付けると、適切な担当者へ対応を振り分けやすくなります。また、質問と回答を記録し、同じ内容が繰り返し発生していないか確認してください。
同じ質問が多い場合は、利用者の注意不足ではなく、画面説明、項目名、教育資料、業務ルールが分かりにくい可能性があります。よくある質問を手順書へ追加するだけでなく、画面くい可能性があります。よくある質問を手自体を改善できないか検討します。担当者によって回答内容が変わらないように、回答基準も共有しておく必要があります。
13.5 定期的な改善会議があるか
CRMは導入時の設定をそのまま使い続けるものではありません。事業内容、顧客層、営業方法、管理指標が変化すれば、必要な情報や運用方法も変わります。そのため、システム担当者と利用部門が定期的に運用状況を確認する機会を設けます。
改善会議では、利用者から出された要望を順番に処理するだけでは不十分です。利用率、入力率、未更新データ、重複データ、検索回数、問い合わせ件数などを確認し、どこに実際の問題があるかを分析してください。
改善案を採用する際は、顧客対応、業務時間、データ品質、売上管理などにどのような効果を期待するのかを明確にします。変更後に何を測定し、効果をどのように評価するかまで決めることで、設定変更だけを繰り返す運用を防げます。
14. セキュリティと権限を確認するチェックリスト
CRMには、顧客の氏名、連絡先、商談状況、契約内容、問い合わせ履歴など、企業活動にとって重要な情報が保存されています。業種によっては、個人情報、価格情報、取引条件、未公開の商品情報など、特に慎重な管理が必要なデータも含まれます。
操作のしやすさを優先して全利用者へ広い権限を与えると、誤操作や情報流出の危険が高まります。権限は、閲覧できるかどうかだけでなく、編集、削除、出力、共有、外部連携などの操作ごとに確認する必要があります。
14.1 必要な担当者だけが閲覧できるか
すべての利用者が、すべての顧客情報を閲覧する必要があるとは限りません。担当外の顧客情報まで自由に閲覧できる状態では、情報の不適切な利用や意図しない共有が発生する可能性があります。
部門、地域、担当顧客、商品、役職などに応じて、閲覧できる範囲を設定します。管理職には部門全体の情報を表示し、一般担当者には自分が担当する顧客だけを表示するなど、業務上必要な範囲に限定することが基本です。
個人の事情、苦情内容、信用情報、特別な契約条件など、機微性の高い情報については、通常の顧客情報とは分けて管理することも検討してください。単に閲覧制限を設定するだけでなく、誰がどの情報へアクセスしたかを確認できる状態にすることも重要です。
14.2 編集権限が限定されているか
業務上、情報を閲覧する必要はあっても、すべての項目を変更する必要があるとは限りません。例えば、顧客の基本情報は編集できても、契約金額、割引率、顧客区分、解約状態などの重要項目は、責任者だけが変更できるようにする必要があります。
項目単位または機能単位で編集権限を設定し、誤操作や意図しない変更を防ぎます。重要な変更については、承認手続きや変更履歴を利用し、誰が、いつ、どの情報を変更したか確認できるようにしてください。
権限を厳しくしすぎると、通常業務のたびに管理者へ依頼する必要が生じます。情報の重要度と業務頻度を考慮し、現場の作業を止めずにリスクを抑えられる権限設計が必要です。
14.3 退職者と異動者の権限を更新しているか
退職者のアカウントが有効なまま残っている場合、退職後もCRMへアクセスされる危険があります。また、異動前の部門権限が残っていると、新しい業務では不要な顧客情報を閲覧できる状態になります。
人事手続きとCRMのアカウント管理を連携させ、退職、異動、休職、復職、雇用形態の変更が発生した際に、誰がどのタイミングで権限を変更するかを決めてください。退職日当日に無効化するのか、最終出勤日に停止するのかなど、実施時点も明確にします。
定期的に利用者一覧を確認し、長期間ログインしていないアカウント、所属不明のアカウント、不要な管理者権限が残っていないかを点検します。共有アカウントは利用者を特定できないため、原則として個人ごとのアカウントを使用することが望まれます。
14.4 データ出力を管理しているか
CRM画面上の閲覧範囲を制限していても、顧客情報をCSVやExcel形式で大量に出力できる場合、情報流出の危険は残ります。一度出力されたデータはCRMの管理外に置かれ、個人端末、メール、共有フォルダなどへ保存される可能性があります。
そのため、データ出力を許可する利用者、出力できる項目、出力件数、利用目的を管理します。大量出力や機微情報を含む出力については、上長の承認を必要とする方法も有効です。
出力後の保存場所、共有方法、利用期間、削除期限についてもルールを決めてください。また、誰が、いつ、どのデータを出力したかを履歴として記録し、不自然な大量出力や業務時間外の出力がないか定期的に確認する必要があります。
14.5 外部連携の権限を確認しているか
CRMは、メール配信、会計、問い合わせ管理、営業支援、分析、電子契約など、複数の外部サービスと連携して利用されることがあります。外部連携を設定すると、連携先のサービスからCRM内の情報へアクセスできるようになるため、通常の利用者権限とは別に管理する必要があります。
各サービスが取得できる顧客情報、更新できる項目、連携に使用するアカウントや接続情報を記録してください。必要以上に広い権限を付与せず、連携目的に必要な範囲だけを許可します。
また、サービスを利用しなくなった場合や契約を終了した場合に、連携を停止する手順も準備しておきます。利用していない連携、担当者が不明な接続、期限切れになっていない接続情報が残っていないかを定期的に確認し、不要なものは無効化してください。
15. CRM改善計画を作る実務用チェックリスト
ここまで確認してきた内容を、実際に実行できるCRM改善計画へ変換します。このチェックリストは、すべての項目にチェックを付けることを目的としたものではありません。未対応項目の中から、顧客への影響、売上への影響、現場の作業負担という三つの観点で重要度を判断し、優先的に改善する課題を選びます。
CRM改善では、設定や機能を変更しただけで完了と考えてはいけません。改善前の状態を数字で記録し、変更内容、担当者、期限、評価指標を決めたうえで、変更後にどのような効果があったかを確認する必要があります。一度に多くの課題へ取り組むのではなく、一つの期間では三件程度に絞り、小さく試しながら改善を進めることが重要です。
15.1 CRM目的のチェック項目
CRMで改善する主要指標が決まっているか、現在値と目標値が設定されているか、CRMを利用する業務範囲と利用部門が明確になっているかを確認します。また、CRMで管理する情報だけでなく、管理しない情報や、他のシステムを正式な情報源とする項目も決めておく必要があります。導入時に設定した目的についても、組織や顧客行動の変化に合わせて定期的に見直します。
- □ CRMで改善する主要指標が決まっている
- □ 現在値と目標値が設定されている
- □ CRMを利用する業務範囲が決まっている
- □ 利用部門が目的を理解している
- □ CRMで管理しない情報が決まっている
- □ 導入時の目的を定期的に見直している
未対応項目が多い場合は、入力項目や画面を変更する前に、経営責任者と利用部門でCRMの目的を再定義します。「顧客情報を集める」「営業活動を見える化する」といった表現は、CRMを導入する手段を示しているだけで、具体的な成果を示していません。「次回行動が登録されていない商談を減らす」「更新予定の顧客へ早期に連絡し、解約を防ぐ」「問い合わせから受注までを追跡し、効果の高い施策を判断する」のように、顧客の状態と事業成果を含めて目的を定めます。
指標も「売上を増やす」のような広い表現ではなく、「商談停滞件数を月50件から20件へ減らす」「契約更新の連絡開始を30日前から90日前へ早める」「営業会議の資料作成時間を週3時間から1時間へ減らす」のように設定します。現在値が分からない場合は、まず一定期間の実績を測定し、その数字を改善前の基準として保存します。
15.2 データ品質のチェック項目
CRMに登録されているデータが重複していたり、更新されていなかったり、担当者ごとに異なる形式で入力されていたりすると、集計結果や売上予測、自動通知の信頼性が下がります。データ品質は担当者への注意だけでは改善しないため、入力方法、選択肢、自動取得、重複防止、更新通知など、仕組みそのものを見直す必要があります。
- □ 顧客の重複を検知できる
- □ 重複データの統合手順がある
- □ 必須項目が必要最小限になっている
- □ 集計する項目が選択式になっている
- □ 顧客情報の最終更新日を確認できる
- □ 項目ごとの正式な情報源が決まっている
- □ 顧客状態や商談状態の変更履歴が保存されている
顧客の重複は、会社名だけで判定すると見落としが発生します。「株式会社ABC」「ABC株式会社」「㈱ABC」のような表記の違いがあるため、電話番号、メールアドレス、法人番号、Webサイトのドメインなど、複数の情報を組み合わせて判定します。重複を発見した後に、どのデータを残すか、活動履歴をどのように統合するか、誰が統合を承認するかという手順も必要です。
必須項目は、次の業務を進めるために必要であり、登録時点で担当者が確認できるものに限定します。必要以上に必須項目を増やすと、仮の値が入力されたり、登録自体が後回しにされたりするためです。業種、流入経路、失注理由、顧客区分など、集計に使う項目は選択式にします。ただし、選択肢が多すぎると担当者が正しく判断できないため、主要な分類を選択式にし、詳細は補足欄へ入力する形が適しています。
データ品質は、未入力率、重複率、最終更新から一定期間が経過した顧客の割合、表記不一致件数、「その他」や「不明」の選択率などで確認します。例えば、「最終更新から90日以上経過した顧客が全体の何%あるか」を毎月確認すれば、データを一度整理して終わるのではなく、継続的に品質を管理できます。
15.3 営業活用のチェック項目
営業部門でCRMを活用するためには、画面や機能を増やす前に、営業工程と商談段階の定義を統一する必要があります。担当者によって「提案中」「見積中」「契約調整中」の判断が異なる状態では、商談件数や受注見込みを正確に把握できません。
- □ 商談段階の移行条件が明確になっている
- □ 段階ごとの必須情報が決まっている
- □ 進行中商談に次回行動が登録されている
- □ 商談停滞の基準が設定されている
- □ 失注理由が具体的に分類されている
- □ 営業会議でCRMを直接利用している
- □ 日報や会議資料との重複入力がない
商談段階は、担当者の感覚ではなく、確認済みの顧客行動によって変更します。例えば、「課題確認」は顧客の課題と導入目的を確認した状態、「提案済み」は正式な提案書を顧客へ提出した状態、「契約調整」は価格や開始時期について具体的な調整を行っている状態と定義します。また、すべての項目を商談開始時から必須にするのではなく、商談が進むにつれて必要な情報を追加します。初回接触では顧客名と連絡先、提案段階では予算、導入時期、意思決定者を必須にするなど、段階に合わせて入力条件を設定します。
進行中の商談には、次に何をするか、誰が対応するか、いつまでに実施するかを登録します。「検討中」だけでは営業活動を管理できないため、「7月25日までに見積書を送付する」「8月2日に技術担当者を含めた説明会を実施する」のように具体化します。商談停滞についても、「14日以上活動履歴がない」「次回行動の期限を過ぎている」「提案後30日以上回答がない」など、客観的な基準を設定します。
失注理由は、「価格」「他社」「時期」のような大きな分類だけでは改善につながりません。「顧客の予算上限を超えていた」「競合より価格が高かった」「費用対効果を十分に説明できなかった」「必要な機能が不足していた」など、次の改善行動を判断できる粒度で分類します。また、営業会議のためにCRMから別の表へ情報を転記する運用は避け、CRM上の商談一覧、停滞案件、次回行動、受注見込みを直接確認します。未対応項目が多い場合は、担当者へ入力を求める前に、営業工程そのものを整理する必要があります。
15.4 マーケティング・顧客維持のチェック項目
CRMは新規顧客を獲得するためだけではなく、初回接点から商談、契約、利用開始、問い合わせ、契約更新、解約までを一つの顧客履歴として管理するために利用します。獲得施策と顧客維持を別々に評価すると、新規顧客数が増えても、更新率や継続収益が改善しない場合があります。
- □ 顧客の流入経路を確認できる
- □ 配信同意と配信停止を管理している
- □ 顧客分類が実際の施策へ利用されている
- □ 見込み顧客の評価理由を確認できる
- □ 施策から商談・受注まで追跡できる
- □ 顧客の利用状況を確認できる
- □ 契約更新日を事前に管理している
- □ 解約理由を商品改善へ共有している
- □ 未解決問い合わせを営業が確認できる
流入経路は、問い合わせが発生した施策だけでなく、商談化や受注に影響した接点まで確認します。問い合わせ件数が多くても受注につながっていない施策へ予算を使い続けないよう、流入経路、商談化率、受注率、受注金額を関連付けて評価します。顧客分類も、レポートを作るためではなく、具体的な対応を変えるために使います。例えば、利用頻度が下がった顧客へ活用支援を行う、更新時期が近い顧客へ早期に連絡する、特定の機能を利用している顧客へ関連商品を提案するといった施策につなげます。
見込み顧客に点数を付ける場合は、点数だけでなく、その評価理由を確認できるようにします。Webサイトを数回閲覧した顧客と、導入時期や予算について相談した顧客では、同じ点数であっても営業対応の優先度が異なる可能性があります。どの行動や条件によって評価されたのかを営業担当者が確認できる設計が必要です。
契約後は、更新日だけでなく、利用頻度、主要機能の利用状況、問い合わせの件数と解決状況、顧客担当者の変更なども確認します。ログイン頻度が低下している、主要機能を利用していない、問い合わせが長期間未解決になっているといった変化は、解約の兆候である可能性があります。更新直前に初めて連絡するのではなく、90日前や120日前から状況を確認し、必要な支援を行います。解約理由も顧客支援部門だけで保管せず、営業、マーケティング、商品開発へ共有し、同じ理由による解約を減らすための改善へつなげます。
15.5 改善計画の作成項目
チェックリストで問題を確認した後は、「データ品質を高める」「営業活用を強化する」といった広い表現ではなく、実行する作業が分かる改善計画へ変換します。一つの改善計画では、原則として一つの主要課題を扱い、発生件数、顧客と事業への影響、変更内容、担当者、期限、評価指標を明確にします。
- □ 改善する問題を一つ選んでいる
- □ 問題の発生件数を確認している
- □ 顧客と事業への影響を評価している
- □ 改善前の数字を保存している
- □ 変更内容と担当者を決めている
- □ 実施期限を設定している
- □ 一部の部門や顧客で試験する
- □ 改善後の評価日を決めている
- □ 効果があった変更を運用資料へ反映する
- □ 効果がなかった変更を元へ戻せる
改善前には、「入力漏れが多い」のような感覚的な表現ではなく、「進行中商談300件のうち、次回行動が未入力の商談が85件ある」「顧客5,000件のうち、重複の可能性があるデータが320件ある」「営業担当者一人当たり、週2時間を会議資料の転記に使っている」のように、問題の規模を数字で把握します。件数だけでなく、顧客への影響、売上への影響、作業時間、情報管理上の危険性も考慮して優先順位を決めます。
変更内容は、「入力を徹底する」「営業へ周知する」といった曖昧な表現を避けます。「提案段階以降では次回行動日を必須にする」「期限を過ぎた商談を毎朝担当者へ通知する」「会社名、電話番号、ドメインによる重複判定を追加する」「利用されていない必須項目を5項目減らす」など、設定や運用の変更内容を具体的に記載します。
全社へ一度に適用するのではなく、まず一部の部門、担当者、商品、顧客で試験します。例えば、新しい商談入力ルールを営業担当者5名で2週間試し、入力時間、未入力率、商談進行への影響を確認します。実施期限とは別に、操作上の問題を確認する日、数字の変化を確認する日、売上や更新率への影響を確認する日も設定します。また、効果がなかった場合に元へ戻せるよう、変更前の設定や運用ルールを保存しておきます。
改善項目は、次のような表で管理します。
| 改善課題 | 現在の問題 | 変更内容 | 担当者 | 期限 | 評価指標 |
|---|---|---|---|---|---|
| 商談停滞 | 進行中商談の次回行動が未入力 | 次回行動日を必須化し、期限超過時に通知する | 営業企画 | 9月30日 | 停滞商談数、未入力率 |
| 顧客重複 | 同一会社が複数登録され、履歴が分散している | 会社名、電話番号、ドメインによる重複判定を追加する | CRM管理者 | 10月15日 | 重複率、重複登録件数 |
| 更新漏れ | 契約更新直前まで顧客へ連絡していない | 更新日の120日前、90日前、60日前に通知する | 顧客支援 | 10月1日 | 更新率、事前連絡率 |
| 入力負担 | 使用されていない必須項目が多い | 必須項目5項目を任意項目へ変更する | CRM管理者 | 9月20日 | 入力時間、登録遅延件数 |
| 施策評価 | 問い合わせ件数までしか確認できない | マーケティング施策と商談・受注情報を連携する | マーケティング | 11月1日 | 施策別商談化率、受注率 |
実務では、改善前の数値、目標値、試験対象、評価日、実施結果、次の対応も記録します。例えば、停滞商談数を85件から40件へ減らすことを目標とし、実施一か月後に未入力率と担当者の入力時間を確認します。数字が改善していても、入力負担や顧客への不要な連絡が増えている場合は、改善が成功したとは判断できません。
CRM改善では、一度に多くの変更を行うよりも、重要な問題を少数に絞り、改善前の状態を記録し、小規模に試してから効果を確認する方が確実です。改善後はCRM上の数字だけでなく、現場の作業時間、重複入力の有無、通知の量、顧客対応の速さ、提案や契約更新への影響まで確認します。効果があった変更は運用資料や研修内容へ反映し、効果がなかった変更は修正するか元の状態へ戻します。
CRMは導入時に完成する仕組みではありません。顧客行動、営業工程、商品、組織体制が変われば、必要なデータや運用方法も変わります。目的と指標を定期的に見直しながら、顧客、売上、業務効率への影響が大きい課題から継続的に改善していくことが重要です。
おわりに
CRM改善では、入力件数やログイン率だけを追うのではなく、CRMの情報によって担当者の判断と顧客対応が変わったかを確認する必要があります。データが蓄積されていても、次回行動、顧客状態、契約更新、施策評価へ利用されていなければ、CRMは記録場所にとどまります。
最初にCRMの目的を確認し、次に顧客データ、営業工程、マーケティング、顧客維持、レポート、操作性、運用体制を点検してください。問題が見つかった場合は、機能追加だけで解決しようとせず、業務ルール、入力項目、会議方法、評価制度も見直すことが重要です。
チェックリストを一度実施して終わりにせず、四半期または半年ごとに同じ項目を確認してください。改善前後の数字を比較し、利用されていない項目や機能を減らしながら、顧客対応と事業成果へ直接つながるCRMへ更新していきましょう。
EN
JP
KR