CRMは完成させない｜運用しながら直す前提の作り方

回答: CRMは、最初に完璧な設計を目指すより、必要な範囲で使い始め、運用しながら直す前提で作るほうが、現場に合った形に近づきやすくなります。そのために先に決めておくのは、変更の要望を受け付ける→判断する→反映する→周知するという流れと、それを誰が担うかです。変更を社内の一人に集中させず、受付と判断と作業を分け、作業できる人を複数にして変更の手順と記録を共有しておくと、担当者の休職や退職で変更対応が止まるリスクを減らせます。見直しは月1回など定期的に行い、思いつきの変更を積み重ねないようにします。ただし、契約・売上・法令に関わる記録など、途中で定義を変えると過去のデータと比べられなくなる部分は、最初に慎重に決めてください。

この記事でわかること

• 最初に完璧な設計を目指すと何が起きるか
• 変更の受付→判断→反映→周知のサイクル
• 変更を誰が担うか（一人に集中させない）
• 見直しの頻度と、変えすぎの注意点

最初から完璧を目指すと何が起きるか

答え: 設計に時間がかかって使い始めが遅れ、さらに使ってみないと分からない不便は設計段階では見つかりません。

導入前の打ち合わせで、全事業・全部署の要望を集め、項目や画面を決め切ってから使い始めようとすると、決めることが増え続けます。その間、現場はExcelや紙で仕事を続けるため、移行の負担も先送りになります。

また、使い始めてから分かることは少なくありません（仮の例: 一覧の並び順が案内の順番と合わない、外出先では使わない項目が上にあって探しにくい、選択肢の言葉が店舗によって違う意味で使われている）。こうした不便は、実際の運用で出てくるものです。最初に決めるのは「最初に使う範囲」と「直し方」にして、画面の並びや選択肢の言葉など後から変えやすい細部は運用しながら詰めるほうが、現場に合う形へ早く近づけられる場合があります。

最初に入れる項目の絞り方はCRMの入力項目の決め方｜最初から入れる項目を絞る基準で扱っています。

変更の受付→判断→反映→周知のサイクル

答え: 変更の要望を1か所で受け付け、判断・反映・周知までを毎回同じ流れで回します。

段階	やること	決めておくこと
受付	要望を1か所に集める	受付の窓口（共有の一覧、フォームなど）、書いてもらう内容（何に困っているか・どの画面か）
判断	やる・やらない・保留を決める	判断する人、判断の基準、判断する日
反映	設定や画面を変える	作業する人、変更前の確認（集計・自動処理への影響）、元に戻す方法
周知	使う人に変更を伝える	伝える方法、変更日、変更した理由

受付では、「この項目を追加してほしい」という解決策より、何に困っているかを書いてもらいます。困りごとが分かれば、項目を増やさずに並び順や絞り込みで解決できることがあります。

判断の基準は、たとえば次のように決めておきます。

• 複数の人が同じことで困っているか
• 入力の手間が増えるか、減るか
• 既存の集計・レポート・自動処理に影響するか
• 一時的な事情（特定の繁忙期だけなど）ではないか

周知を省くと、「いつの間にか画面が変わっていて使いにくくなった」という不満につながります。変更内容と理由を短く伝え、要望を出した人には結果（やらない場合も理由）を返すと、次の要望が出やすくなります。

変更を誰が担うか

答え: 受付・判断・作業を同じ一人に集中させないことが大切です。

CRMに詳しい社員が一人いると、要望の受付から設定変更まで、すべてがその人に集まりがちです。この状態では、その人が忙しい時期に変更が止まり、休職や退職で直し方が分からなくなります。自作の仕組みで起きやすい属人化の問題は、GAS自作の属人化リスク｜担当者交代に備える引き継ぎのポイントでも整理しています。

役割の分け方の例です（仮の例）。

役割	担う人の例	内容
受付	事務担当	要望を一覧にまとめる
判断	店長・営業責任者	月1回の見直しで、やる・やらないを決める
作業	社内の担当者2人以上、または外部の支援先	設定変更、変更内容の記録
周知	判断した人	朝礼やチャットで変更を伝える

作業を社内で行う場合は、少なくとも2人が直せる状態にし、何をいつ変えたかを記録しておきます。外部に任せる場合も、判断は社内で行い、変更の記録を受け取るようにします。社内でどこまで対応し、どこから支援を頼むかの線引きはノーコードDB移行、自社でどこまでできて、どこから支援が必要かが参考になります。

7plus が BizBlock の不動産パッケージを提供するときも、必要な事業・画面から使い始め、項目追加・画面変更・レポート作成は 7plus が月5時間の構築・運用サポートの中で行う形にしています（超える分や新規開発は別途相談）。どのツールを使う場合でも、「誰が直すか」を導入前に決めておくことが、直しながら使う前提を成り立たせます。

見直しの頻度

答え: 使い始めの数か月は短い間隔で、落ち着いたら月1回程度の定例にまとめるのが目安です。

• 使い始めの時期: 不便が多く出るので、2週間に1回など短い間隔で要望を確認します。ただし、慣れの問題で解決するものもあるので、すぐ変えずに様子を見る判断もあります
• 運用が落ち着いたあと: 月1回、たまった要望をまとめて判断します。変更日をまとめると、周知の回数も減ります
• 緊急の変更: 入力できない、集計が明らかにおかしいなど、業務が止まるものは定例を待たずに対応します

数年単位で運用したあとに増えた選択肢やフェーズを整理する方法は、CRMを何年も運用すると起きることフェーズと選択肢が増え続けるで扱っています。この記事は、日々の変更をどう回すかに絞っています。

変えすぎの注意

答え: 直しながら使う前提でも、変更が多すぎると現場が覚えきれず、データの意味も揃わなくなります。

注意したい点です。

• 定義を変えるとき: 商談の段階や選択肢の意味を途中で変えると、変更前と変更後のデータを同じ基準で比べられなくなります。変更日を記録し、集計で区別できるようにします
• 一人の要望だけで変えるとき: 声の大きい人の要望だけが通ると、他の人が使いにくくなることがあります。判断の基準に照らして決めます
• 毎週のように画面が変わるとき: 現場が慣れる前に変わると、入力の迷いが増えます。変更はまとめて行います
• やらないと決めた要望: 理由とともに記録しておくと、同じ要望が繰り返し出たときに判断が早くなります

また、この「直しながら使う」進め方が向かない場面もあります。外部のシステムと自動でつながっている部分（会計、ポータルの反響取り込みなど）は、変更の影響が社外にも及ぶため、事前の確認と試験を丁寧に行ってください。

よくある質問

最初にどこまで決めればよいですか？

最初に使う範囲（どの事業・どの業務から始めるか）、最低限の入力項目、そして変更の受付・判断・反映・周知を誰が担うかです。画面の細かい並びや選択肢の言葉は、使い始めてから直す前提でかまいません。

要望が多すぎて対応しきれません。

月1回の見直しで、複数の人が困っているもの、入力の手間が減るものから優先します。すべてに対応する必要はなく、やらないと決めたものは理由を返して記録しておきます。

まとめ

CRMは完成させるものではなく、運用しながら直していくものとして作ると、現場に合った形に近づきます。最初に決めるのは使う範囲と直し方です。変更は受付→判断→反映→周知の流れで回し、作業を社内の一人に集中させないようにします。見直しは定例にまとめ、定義の変更は記録を残して慎重に行ってください。まずは、今あるCRMや管理表への要望を一か所に集める窓口を決めるところから始めてみてください。

—

この記事を書いた会社

7plus株式会社 不動産会社向けの営業DX支援を行うITソリューションプロバイダーです。反響対応を即時化する「Mail2Link」「Mail2Link×AI」、ノーコード業務アプリ「BizBlock」の開発・提供に加え、Salesforce認定パートナーとして不動産特化型Salesforceパッケージの導入・定着コンサルティングも行っています。

詳しくはこちら → https://7plus.jp/