連絡先データが正確かどうかを確認する、 CRMへのインポート前に
ファイルを開いてから出てくる疑問です。ここでいう「正確」とは何を指すのか、この検査で実際に確認できること、そしてCRMでしかわからないこと。
ツール本体
CRM Import Check
CSVまたはExcelファイルをドロップし、HubSpot・Salesforce・Pipedriveから取り込み先を選ぶと、インポートで拒否されるもの、切り詰められるもの、重複として片方だけ残されるものがわかります。
ファイルを検査するさらに6つの質問
ツールの機能、対応CRM、ファイルがアップロードされるかどうかなど、検査の前に聞かれる9つの質問には、ツールページで回答しています。ここにあるのは、自分のファイルを見ながら「正確」とは実際どこまでを指すのかと考え始めたときに出てくる質問です。
- CRMにインポートする前に、連絡先データが正確かどうかを確認するにはどうすればよいですか？
- 「正確」には2つの意味があり、このツールで確認できるのはそのうち一方だけです。選んだ取り込み先に対して確認するのは、次の点です。必須項目がすべて揃っているか（Salesforceの個人ならLast Name、HubSpotの個人ならメールアドレスか姓名の両方）。メールアドレスと電話番号が、すべて形式として使えるか。日付と数値が取り込み先の想定どおりに入力されているか。同じメールアドレスやキーを持つ行が2つないか（CRMのインポートは、この場合に一方の行を残してもう一方を捨てます）。取り込み先が公開している項目の上限を超える値がないか。一方、確認できないのは次の点です。所有者、リードステータスなどの選択リストの値が、CRMで設定済みの選択肢と一致するか。メールアドレスが実際にメールを受信できるか。記載された人物や企業が実在するか。「取り込める」という判定は、上記の検査の範囲でファイルが拒否・切り詰め・重複処理されないという意味であり、記載内容がすべて事実だという保証ではありません。
- 選択リストや所有者の値が、CRMの設定と一致しているかを確認できますか？
- いいえ。選択リストの選択肢、リードステータス、所有者の割り当て、既存レコードとの関連付けは、CRMの設定の中にしか存在しません。このツールはCRMに接続せず、読み取るのはこれから渡すファイルだけです。ファイル上では問題なく見える値でも、CRM側に対応する選択肢がなければインポート時に拒否されることがあります。それを確認できるのは、CRM自身か、その設定を把握している人だけです。
- 判定が「取り込める」なら、インポートは必ず成功しますか？
- 「取り込める」という判定は、選んだ取り込み先に対する検査（必須項目、書式、ファイル内の重複、項目の長さ、列の対応）をすべての行が通過したという意味です。CRM側が独自に判断することまでは保証しません。たとえば、一致する選択肢のない選択リストの値、すでに存在しない所有者、ファイル内の別の行ではなくCRMにある既存レコードとの重複、インポートするアカウントに権限がない場合などです。これらはCRM内部の状態で決まり、ファイルの検査からは見えません。
- 企業レコードでも、正確さの確認は同じように行えますか？
- はい。ただしルールは異なります。企業レコードにメールアドレスは必要ありません。HubSpotはドメイン名か会社名のどちらかがあれば受け付け、SalesforceとPipedriveにもそれぞれ同様の要件があります。書式、重複、項目の長さの検査は同じように行いますが、個人オブジェクトではなく企業オブジェクトの必須項目と上限が基準になります。
- メールアドレスが実在するか、送信してもエラーで戻ってこないかを確認できますか？
- いいえ。確認するのは、アドレスがCRMのインポートが想定する形式として正しいかどうかです。あわせて、info@やsales@のような共有メールボックス、使い捨てドメイン、gmial.comのようなドメインの打ち間違いの疑いに印を付けます。メールボックスが実在してメールを受け取れるかどうかは、メールサーバーに問い合わせなければわかりません。このツールは、あなたのデータを含む通信を一切行いません。到達性を確認するには、すべてのアドレスをどこかに送信する必要があるからです。
- 提案された修正をすべて適用すれば、ファイルは完全に正確になりますか？
- このツールで見つけられ、自動で直してよい問題（余分な空白の削除、メールアドレスの小文字化、無効な文字の除去、仮の値の消去）はなくなります。ただし、上で説明した意味で検証済みになるわけではありません。書式を直しても、選択リストの値が正しいと確認されるわけではなく、使えるメールアドレスが生まれるわけでも、重複した2行のどちらが本物のレコードかが決まるわけでもありません。それらは引き続き人が判断することです。変更ログには何を変更したかが正確に記録されるので、その判断に役立ちます。
実際のファイルでの例
一見問題なさそうで、実はそうではなかった3つの事例です。
読み返すまで気づかないドメインの誤り
入力：1,200行のうちの1行で、メール列にada@gmial.com。
出力：該当する行と、正しいと思われるドメインを示す警告1件。
指摘：ツールはgmail.comを提案し、2つの値を並べて表示します。修正にチェックを入れない限り、何も変わりません。提案は事実ではないからです。
必須項目を通すためだけに入力された値
入力：同じ日に追加された40行で、役職の列が「該当なし」になっている。
出力：該当する行と、繰り返し入力された値を示す警告1件。
指摘：ツールは本物の役職をでっち上げるのではなく、仮の値を消去します。セルは空欄にして、入力するか空のままにするかは人に委ねます。
同じ項目を取り合う2つの列
入力：「Company」列と「Company Name」列の両方があるファイル。
出力：2つの見出しと、どちらも対応する項目を示す警告1件。
指摘：ツールは一方を対応先として提案し、もう一方を未対応として示します。どちらが正しいかは決めません。どちらの列を信頼すべきか、ツールには判断できないからです。
この疑問を持つ人
この疑問は、すでにファイルを手にしている人から、同じ作業の4つの段階で出てきます。
初めてインポートする人
会社が最初に行うCRMインポートは、その後何年にもわたってデータベースの形を決めます。何かが書き込まれる前に一度で「正確」にしておくほうが、後から直すより安く済みます。
データ品質を担う人
多くの会社では正式な役職ではありませんが、必ず誰かがこの仕事を担うことになります。インポート後の大掃除プロジェクトではなく、インポート前に行う検査です。
顧客の導入を支援するコンサルタント
顧客ごとに毎回違うエクスポートファイルが届き、頼れる常設のCRM接続もありません。検査できるのはファイルだけです。
CRM移行を担当する人
旧システムのエクスポートは、新システムのルールを前提に作られていません。切り替え前に移行先のルールで検査することこそ、この作業の目的です。