私は、CRM導入後の会話に数え切れないほど同席してきた。その多くは、決まって同じ不満から始まる。「システム自体は問題ないが、社員が使おうとしない」。こうした状況になると、経営者はしばしば規律の問題だと考える。だが実際には、CRMがひそかにチームへ不信感を植え付けているのである。
私は、現実のプレッシャーにさらされている成長企業で、こうした事態が起きるのを見てきた。予算は限られ、6カ月に及ぶ導入には前向きでなく、「とにかく動くもの」を強く求めている。ここに落とし穴がある。最も安い選択肢が、結果的に最も高くつくことが多いのだ。初日ではなく、事業のスピードがツールを上回り始める6カ月目に、その代償が表面化する。
契約前に確認すべき危険信号と、どんなデモよりも早く真実を見抜ける、いくつかの見落とされがちなテストを紹介する。
「すぐに使える」は、1つ変更が必要になるまでは魅力的に聞こえる
パッケージ型CRMは、プロセスが基本的で安定していれば、当初は便利かもしれない。問題は、多くの成長企業が長く安定したままではいられないことだ。
最初の本当の試練はたいてい、特定の製品ラインに合わせてステージを調整する、挙動を変えるフィールドを追加する、実際の週次会議の進め方に合ったレポートを作成するといった、標準外のことをしようとしたときに訪れる。多くの既製ソリューションは、そもそもそれを許可しないか、狭い範囲内でしか認めない。
結果は予測できる。自社の事業にCRMを合わせるのではなく、CRMに合わせて事業を再設計することになるのだ。効率性の代わりに得られるのは、サブスクリプション型で継続する業務上の摩擦である。
CRMが現実の例外にどう対応するかを見るため、見落とされがちなテストを1つ行うことを提案したい。トライアルでは、理想的なプロセスを作らない。代わりに、VIP顧客、パートナー経由のリード、更新、返品、複数段階の承認など、すでに存在する例外を1つ作ってみる。例外によってモデルが破綻するなら、次に破綻するのは導入定着である可能性が高い。
「ノーコード」は多くの場合、「重要な場面まではノーコード」を意味する
私は、企業が現場主導の設定を想定していたにもかかわらず、権限、承認、ルーティング、複雑な通知など、実際に収益を守るワークフローには開発者や有料パートナーが必要だと後から気づく場面を見てきた。
技術的な支援が必要になること自体が問題なのではない。問題は、そのタイミングと依存関係である。意味のある変更に専門家が必要なら、CRMはボトルネックになり、チームはプロセス改善をやめてしまう。
「提案後はマネージャーだけが案件金額を変更できる」「このチャネルからのリードは割り当て前に確認が必要」といった現実のポリシーを、非技術系の管理者がどのように実装するのか、ベンダーに実演してもらうことを勧める。答えが曖昧なら、購入しているのは機能ではなく複雑さである。
表示されている価格が、実際に支払う価格であることはまれだ
ほとんどのCRMの料金ページは、シンプルに見えるように構成されている。だが、契約後にアドオンが現れることがある。
よくある想定外の費用には、有料サポート階層、自動化の上限、有料トレーニング、アップグレード扱いの「高度な」権限、上位プランが必要なレポート機能などがある。もう1つの隠れたコストは、時間管理や分析などの中核機能が欠けていることだ。それぞれに独自のサブスクリプションと連携作業が必要になる。
現在の月額費用ではなく、12カ月のコストマップを作成することを勧める。成長に伴って必要になりそうなもの、つまりチームの増加、自動化の拡大、より厳格なアクセス制御を列挙する。そのうえで、何が標準機能で、何がアドオンで、何が外部ツールを必要とするのかを確認すべきだ。
多くのCRMはオンボーディングで失敗する
私が見てきた最も痛みの大きい導入失敗は、CRMに機能が不足していたためではなかった。「完了とは何を意味するのか」「次に何が起こるのか」という2つの基本的な問いに、誰も答えられなかったためである。
オンボーディングに実用的なテンプレートや設定例がなければ、各チームが独自のルールを作り始める。営業はデリバリー部門と異なる意味でフィールドを使い、経理は請求書関連データを信用せず、経営層はダッシュボードを信じなくなる。CRMは作業後に更新する場所になり、本来の目的を失う。
オンボーディングは製品と同じ基準で評価すべきだ。つまり、実践的なドキュメントと、契約締結後に消えてしまわないサポートを探す必要がある。
スケーラビリティとはユーザー数ではなく、ガバナンスの問題である
ほとんどのCRMはシート数を追加できる。問うべきは、そのシステムが混乱に陥ることなくルールを拡張できるかどうかである。
成長すれば、ガバナンスが必要になる。これには、ロールベースのアクセス、監査可能性、予測可能な自動化、ほかのすべてを壊さずにプロセスを変更できる能力が含まれる。私は、「高度な権限」や「複数エンティティ」構造には高額なアップグレードやカスタム開発が必要だと、チームが手遅れになってから気づくのを見てきた。その時点で、CRMが戦略を左右し始めるのである。
トライアル中にスケールをシミュレーションすることを勧めたい。2つ目のパイプラインを追加する。権限の異なる2つ目のチームを追加する。承認ステップを追加する。システムが回避策を積み上げるための装置のように感じられ始めたなら、その傾向はおそらく悪化する。
連携機能の不足は、コストか脆弱な回避策のいずれかを生む
連携機能はおまけではない。CRMが実際のシステムになるための要である。
コミュニケーションチャネル、フォーム、会計、メッセージングツールに対するネイティブ連携がなければ、開発時間という形で支払うか、機能するかどうかわからないコネクターの連鎖に頼ることになる。これらが壊れれば、データの連続性とシステムへの信頼の両方を失う。
最重要の連携を5つ特定し、ライブトライアルで検証すべきだ。「連携できます」という説明を受け入れてはならない。「実務ではこのように機能します」という実演を求める必要がある。
結論：選定前の実践的チェックリスト
CRMは、インストールして終わるツールではない。むしろ、企業が顧客にサービスを提供し、約束を果たすための業務リズムになる。だからこそ、最善の購買アプローチは機能比較ではなく、ストレステストである。
契約前に、次のシンプルな規律を実践することを勧める。
1. 6〜12カ月後に成り立っていなければならないことを書き出す（今日だけではない）。
2. それを、カスタマイズの深さ、真のノーコード機能、サポートとオンボーディング、スケーリング、連携、総コストを含むチェックリストに落とし込む。
3. 機能だけでなく、導入とサポートに触れているレビューを読む。
4. 必ずトライアルを実施し、単なる「うまくいく想定の流れ」ではなく、1つの「難しい」シナリオをテストする。
私の経験では、最良の選択肢はたいてい、事業が変化しても一貫性を保てるシステムであり、その変化はあらかじめ計画できる。
