顧客名簿をCRMへまとめる前に何を確認する？取得元・利用目的・配信設定を分ける

CRMへまとめて、どの仕事を進めたいか決める

最初に、どの仕事のために名簿を整理するかを一文にします。CRMは、顧客との関係や問い合わせ・商談の対応をまとめて管理する仕組みです。「CRMに入れる」は作業の方法で、その情報を何に使いたいかまでは説明していません。

この架空会社では、未回答の問い合わせを別の担当へ引き継ぐ仕事と、過去の顧客を新商品の案内候補として検討する仕事があります。前者なら、どの問い合わせへ誰が返答するかを追うための情報が必要です。後者では、その案内に使う条件を別に確かめます。同じ連絡先の列があるという理由で、二つの仕事を一括の取込・配信判断にしません。

次の図では、名簿の置き場所ではなく、進めたい仕事の違いを見てください。

まず対象の名簿と仕事を一つに絞り、「誰が、何への対応を引き継ぐために、どの記録を使いたいか」と書きます。今回使わない情報や用途は広げず、必要な閲覧・確認の範囲を管理担当と合わせます。

次の行動：名簿の管理担当と、「問い合わせへの対応履歴を管理したい」のか「新商品の案内候補を検討したい」のかを言葉にしてください。会社名の表記や同一人物の判定が問題なら、顧客名とコードをそろえるための確認方法を別の作業として扱います。

名簿の取得元と、その時の説明をたどる

担当者から受け取った経路と、顧客から取得したときの根拠を分けます。引継ぎの記録は「誰から名簿を受け取ったか」をたどる手掛かりですが、顧客本人へ何を説明したかの代わりにはなりません。

二つの資料で、最初に見返せるものがどう違うかを図で確かめてください。

問い合わせの元記録へ戻れる場合は、受付時のフォームや説明文、対応の記録、どの版・時点の資料かを確認します。ただし、この例では参照先があることまでしか分かりません。取得時の説明を読んだことにも、その内容が今回の使い方をカバーすることにもしていません。

引継ぎ記録だけの場合は、前担当や名簿の管理担当へ、元の受付・顧客対応の記録や取得時の説明がどこにあるかを尋ねます。見つからないことと、まだ確認していないこと、実際に案内停止の記録が見つかったことを分けて残してください。分からないまま「同意なし」「取得が不正」とも決めません。

次の行動：元資料の参照先、確認した説明の版と箇所、まだ確認できていない点をメモします。実顧客の情報や生の証跡を記事の資料へ写す必要はありません。社内で認められた共有範囲で、担当が元資料をたどれるようにします。

元の記録、業務の判断、製品の設定を別にする

「元の記録で分かること」「業務として判断すること」「製品へ申告・設定すること」を順に対応させます。メールアドレスが入力され、列の対応付けが終わっていても、利用の条件や案内配信の判断まで終わったとは言えません。

図の破線は、資料を照合する順番です。情報を登録・配信した結果を描いたものではありません。

「未確認」は、この説明例に答えがまだないことを表します。申告を裏付ける資料が不足しているなら、何が分からないかを記入して担当へ返します。元の資料・今回の用途・製品の確認欄を同じ行で対応させると、単に「同意が不明」という報告より確認先を絞れます。

次の行動：未確認の欄を勝手な値で埋めず、「どの資料の何を見れば、この仕事への利用を説明できるか」を管理担当へ返します。既に案内停止の記録が見つかった場合の反映は、配信停止と候補一覧の状態を照合する方法へ分けます。

取込画面で確認できない内容を求められたら、進める前に確かめる

説明できない内容を、作業を進めるためだけに申告しません。非マーケティングという製品上の区分へ変えることを、取込時の確認を回避する方法として扱わないでください。元資料と申告文を対応させたうえで、対象の製品・プラン・取込方法について正式な手順を確認します。

HubSpotの単一オブジェクト取込の英語公式文書では、次の確認欄と追加設定を分けています。図では、それぞれが別の問いであることを見てください。

取込権限や対象を編集する権限が必要で、marketing statusを含む取込にはMarketing Contactsを備えるMarketing Hubの該当プランという条件があります。製品上の区分は、法律上の同意や包括的な送信許可そのものではありません。単一オブジェクト取込の公式手順とmarketing contactsの対象条件を、利用中のアカウントと照らし合わせます。

既定値も、作成経路や対象のツールによって異なります。作成経路別の既定値を説明する公式文書を確認し、「どの経路でも、ずっと非マーケティングだから大丈夫」と一般化しません。非マーケティングという値から、あらゆる種類の連絡が禁止・許可されるとも判定しません。

Communityには、顧客・問い合わせ先を対応履歴の管理へ使いたい担当者が、事実確認できない取込申告をどう扱うか尋ねた投稿があります。ただし、投稿者の画面の報告は現行の全アカウントの共通条件ではありません。返信で挙げられた手動入力などを、公式に認められた回避手段として採用しません。本人の質問と、その範囲

問い合わせるときは、画面の文言と元記録を一緒に示す

「この名簿を入れられますか」だけでは、用途や不足する根拠が伝わりません。次のように、社内の管理担当へ元資料の確認を、提供元へ製品の正式な手順を分けて尋ねます。

次の行動：根拠不足の箇所と質問先を一つに絞って返します。回答が曖昧なら、対象の名簿・用途・画面の文言を合わせ直してください。手動で一件ずつ、あるいはAPI経由なら確認を省けるとは判断しません。

確認できた範囲だけ整理し、結果も用途別に確認する

確認できた範囲だけ手順を整え、登録の完了表示と、意図した結果の確認を分けます。実顧客へ送信したり、本番の名簿を変更したりすることを、この記事のテスト目標にはしません。対象の条件を管理担当とそろえ、認められた試験環境・架空データで確認する範囲を決めます。

次の図のチェック欄は未記入です。まだ実施していない確認計画として読んでください。

元の利用目的が確認できた場合も、その回答が今回の仕事にどう対応するかを残します。資料が別の版や環境の説明だった場合は、対象を合わせ直すまで保留します。停止の記録が見つかった場合はその記録を保ち、配信側への反映を担当へ確認します。「分からないので削除する」「未確認だから非マーケティングへ変える」といった一律の処理へ置き換えません。

次の行動：元資料・判断した用途・製品条件・確認した結果と、残る保留を対応させて残します。その後、二つのシステムの列や番号を連携させる段階は、CRMと販売管理のデータ連携の確認点で別に整理できます。

まとめ：名簿一つの、使う仕事と確認元から始める

最初にそろえるのは、名簿の列の数だけではなく、取得元と今回の仕事を説明できる根拠です。元の記録、業務としての判断、製品の申告・設定を対応させ、確認できない内容を同意や配信可能へ補わないことが、この整理の出発点になります。

図のように、対象の名簿と使う仕事、元の説明、次に尋ねることを一組にして残します。

この二資料では、参照先がある場合も、取得時の説明・取扱いの条件・配信同意・申告の裏付けは未確認です。片方を適法・成功、もう片方を違法・失敗とした例ではありません。

今日の一歩：引き継いだ名簿を一つ選び、「何の仕事に使いたいか」「元資料のどこを見返せるか」「どの申告・設定の根拠が不足するか」を管理担当へ示してください。元記録と利用中の製品条件を確かめてから、進める作業と保留する作業を分けます。