この記事は、不動産会社の経営者・営業企画・DX担当者に向けた実務ガイドです。
「CRMを導入したいが、入力項目や製品比較から始まり現場運用のイメージが固まらない」という状況から、判断の順番と確かめることを示します。
読み終えたときに、顧客・反響・案件・活動を分け、最小限の運用ルールを決められる状態をつくるための手順が手元に残ります。
同じ顧客が複数の物件に問い合わせた場合、一行を顧客とするのか問い合わせとするのかで、数え方が変わります。顧客情報を毎回別人として作成すれば重複が増え、逆にすべて一件へ上書きすれば過去の相談を失います。最初に記録の単位を明確にします。
NAYUTAの整理案は、顧客、問い合わせ、案件、対応履歴を分けて考えることです。必ず四つの別ツールを用意するという意味ではなく、同じ情報として上書きしない設計を指します。家族の別名義など、本人確認が難しいものを自動で同一人物と確定しないことも重要です。
入力できる情報が多いことと、営業で使えることは別です。次回の対応を忘れない、対応外の理由を把握する、案件の状況を引き継ぐなど、実際に行う判断に必要な項目を選びます。自由記述だけでなく、状態の定義を共有できる欄も用意します。
| 記録の単位 | 最低限確認することの例 |
|---|
| 顧客 | 連絡先・確認済みの関係・連絡希望 |
| 問い合わせ | 受付日・流入元・本人の相談内容 |
| 案件 | 対象物件や相談目的・担当・進捗 |
| 対応履歴 | 連絡した内容・本人の回答・次の対応 |
| 運用管理 | 変更した人・日時・権限・保存ルール |
フォームからの登録や通知を自動化するときは、重複、入力間違い、途中の障害を想定します。同じ送信を再処理しても別件が増え続けないこと、誤った統合を確認できること、担当者が修正した情報を連携が上書きしないことを点検します。
AIを使って相談内容を分類する場合は、推定結果と本人が伝えた内容を分けます。NISTのAIリスク管理の枠組みも、AIの設計から利用までリスクを継続的に扱う考え方を示しています。本稿ではその考え方を、誤分類を見つけて直す運用へ適用しています。［1］
最初は一つの店舗や問い合わせの種類を選び、受付から次回対応までを実際に動かします。入力が終わったかだけでなく、別の担当者が記録を見て対応できるかを確認します。Excel等から移す場合も、元データを確認できる形で残し、件数と重複を点検してから運用を切り替えます。
誰がアクセスを認め、誰が退職・異動時に権限を外すかも決めます。顧客情報を記事用CMSや公開ファイルに置かず、使う目的と権限に合った場所で管理してください。詳細な法的要件は、実際の取扱いをもとに専門家へ確認します。
必要な業務と連携、権限、移行、運用担当を先に決めます。使わない機能の多さより、日々の対応が成立するかで比較します。
共有アドレス等の可能性を含め、統合条件を決める必要があります。不確実なものを確定せず、候補として人が確認できる仕組みにします。
補助の推定として使う場合も、根拠と限界を残します。推定だけで顧客への対応を決めず、本人の希望と確認済みの状況を優先します。
出典参照日：2026-09-27。外部資料で確認した内容と、本稿の判断表・手順・設計例を区別しています。設計例や仮定の数字は実際の顧客実績を示すものではありません。
［1］NIST：AI Risk Management Framework→AIの利用を含むライフサイクルでリスクを管理する枠組み。CRM設計の各項目は本稿の適用案。
