チームがフォローアップを見落とし担当者も分からない
目下の課題は高度な分析ではなく、業務の調整です。
業務型、コラボレーション型、分析型、業界特化型、スイート型、構成可能型のCRMを、それぞれが担うよう設計された業務で比較します。
業務型、コラボレーション型、分析型CRMは有用な概念ですが、購入者はスイート、業界特化製品、構成可能なプラットフォームの違いも判断する必要があります。
実際の導入では複数タイプを組み合わせることが多いものの、通常は1つのタイプが購入判断を左右します。
| CRMモデル | 想定用途 | 注意点 |
|---|---|---|
| 業務型CRM | リード、商談、活動、オンボーディング、サービス、維持のワークフローを実行します。 | 長い機能一覧の陰に、担当責任や例外処理の弱さが隠れている場合があります。 |
| コラボレーション型CRM | 営業、サービス、オペレーション、パートナー、拠点間で顧客情報を共有します。 | アクセス、同意、重複するID、引き継ぎのルールにはガバナンスが必要です。 |
| 分析型CRM | 顧客データをセグメント化し、スコアリング、予測、測定、パターン発見を行います。 | 結果は、定義、履歴、データ量、信頼できる元データに左右されます。 |
| 業界特化型CRM | 業界用語、ワークフロー、連携、統制、レポートを提供します。 | 機能が深いほど、柔軟性が下がったり移行・乗り換えコストが増えたりする場合があります。 |
| スイート型CRM | 営業、マーケティング、サービス、コマース、分析を1つのベンダー製品群に統合します。 | エディション、アドオン、管理、定着の複雑さは急速に増す場合があります。 |
| 構成可能なCRMプラットフォーム | チームが独自のレコード、関係、ワークフロー、役割、ダッシュボードを設計できるようにします。 | 顧客企業がデータ設計、ガバナンス、テスト、境界に責任を持つ必要があります。 |
抽象的なカテゴリ名より、最も強い制約の方が選定に役立ちます。
目下の課題は高度な分析ではなく、業務の調整です。
各チームにソフトウェアがあっても、引き継ぎは失敗します。
ダッシュボードを増やすと、不統一な定義の影響も拡大します。
硬直したパッケージモデルは、回避策や高額な変更依頼を生みます。
構成可能なレイヤーで専門システム周辺の業務をつなげられますが、その中核機能を知らないうちに作り直すべきではありません。
専門的な営業自動化を維持し、承認または例外ワークフローを連携します。
メールシーケンスを再構築したり、正規の商談データを複製したりすること。
統制された業界固有レコードを維持し、担当責任が明確な地域業務を限定的に追加します。
設定可能なフィールドだけでコンプライアンス対応を主張すること。
統制されたデータと指標を中央で使用し、元データに紐づくアクションを担当者へ振り分けます。
CRM内に編集可能なシャドーデータウェアハウスを作ること。
対象を絞った業務モデルから始め、実際のタスクで必要になったときだけ機能を深めます。
想定上の将来ニーズのために全社スイートを購入すること。
従来の分類は、業務型CRM、コラボレーション型CRM、分析型CRMです。現在の選定では、業界特化型、スイート型、構成可能なプラットフォーム型も検討すると役立ちます。
はい。実績ある製品の多くは、業務、コラボレーション、分析の機能を組み合わせています。それでもタイプを区別することで、最も重要な機能と許容できるトレードオフを把握できます。
構成可能なCRMプラットフォームは、データ、権限、テスト、リリースを適切に管理できれば、変化するレコードやワークフローに対応できます。
チームが担当する関係プロセスを中心に、独自の顧客レコード、ワークフロー、役割、ダッシュボードを連携できます。
標準搭載の営業エンゲージメント、サービスチャネル、規制業界向け機能、大規模分析機能は、柔軟性より重要になる場合があります。