CRMの会社情報はいつ確かめる？公開情報と商談確認の更新表

青葉商会の佐藤は森製作のCRMプロフィールを訪問前に確認しました。事業所は昨年のWeb情報、使用設備は先週の面談、従業員数は三年前の入力です。

更新日一つだけを見ると、先週の設備確認でプロフィール全体が新しいように見えます。

顧客属性ごとに確認源・確認日・対象範囲を残し、次の営業判断に必要な古い欄だけを再確認します。 参照資料「HubSpot: Default company properties」で確認した範囲は、会社名・所在地・会社担当・親会社・関連商談・従業員数という属性の区別。 この節の会社・担当・社内基準は架空の教材です。

この章の根拠：出典1

「使用設備」の入力は、10月3日の面談で確認です。ここでは発言した窓口と対象工場を残します。記録の判断欄には「現在の相談に使用可」と残します。

「事業所所在地」の入力は、昨年の会社サイトです。ここでは会社サイトの対象拠点と照合します。記録の判断欄には「訪問前に再確認」と残します。

「従業員数」の入力は、三年前の入力、出典なしです。ここでは全社か単体かを確認します。記録の判断欄には「現在の判断には未確認」と残します。

比較表は横に動かして全ての列を確認できます。

佐藤は一括更新の印を付けず、訪問先住所を先に確かめます。従業員数を今回の提案で使わないなら緊急確認から外し、設備の確認結果は対象工場の範囲だけで使います。

全項目を毎月確認する方式は負担が大きく、更新日一つの方式は古い欄を隠します。判断に使う属性と変わりやすさで確認を選ぶ方式なら、今回の訪問住所を優先できます。

プロフィール全体の更新日は、すべての欄を再確認した日ではありません。今回の訪問住所が確認済みでも従業員数が古い状態はあり得ます。判断に使った欄へ確認日と根拠を付けます。

公開サイトと窓口の説明が食い違う場合は新しい方を自動で正解にしません。拠点移転の予定情報と現住所など、適用時期の違いを確認し、確認が終わるまで旧住所で訪問しません。

公開情報の更新は顧客内部の使用条件を証明しません。会社サイトの記載を参考にしつつ、個別提案に必要な現場条件は担当窓口へ確認します。

移転予定日が不明なら佐藤は訪問準備を確定せず、岡への住所確認をタスクにします。公開住所は捨てず、どの拠点のどの時期の情報かを保留理由とともに残します。

佐藤が所在地の確認を取り、田中はプロフィール欄に確認日と資料名を添えます。出典なしの従業員数は空欄へ消す前に、未確認として別の確認対象へ移します。

会社情報の最終更新日とは別に、各欄の確認日を読み取れるかを点検します。次回の担当者が住所だけ新しく、従業員数は未確認だと説明できる状態を完了とします。

高橋は訪問用一覧から住所の確認日を読めるか試します。田中が従業員数を後で更新しても住所の確認日が変わらないことを照合します。根拠のない更新済み印は、対象欄を特定して訂正します。

今回の判断で使う属性を先に選びます。訪問なら住所、数量なら対象設備というように、用途と確認範囲を対応させます。

確認の優先順位は古さだけで決めません。今すぐ使わない従業員数と、明日の訪問先住所のどちらを先に確認するかを担当へ渡します。

佐藤は住所の確認結果を残し、高橋は訪問準備を再現します。確認できなかった属性は未確認のまま保ち、一括確認済みにしません。