| 氏名 | メールアドレス | 組織 |
|---|---|---|
| Alex Winter | [email protected] | Studio Nord |
| Morgan Reed | [email protected] | Northline |
インポート前に確認
データ移行は、アップロードだけでは終わらない
長く使った顧客リストには、表記の揺れ、空欄、同じ人の重複が含まれがちです。内容を確認せず取り込めば、表の問題を共有データベースへ移すことになります。Tsumiraは、ファイルの読込、列の対応付け、変更計画、確定した取込を分けます。作成、更新、除外の予定を見てから、責任を持って判断できます。
書き込む前に、文字と列を確認する
取込ではUTF-8や日本語のShift_JISなど、対応する文字コードを判定し、見出しを取込先の項目に対応付けます。名前が読めるか、列の意味が合っているかを確認してください。連絡先の列が、見出しの違いだけでメモへ入ってしまうことを避けます。担当者の取込先には氏名、読み、電話、メール、住所、メモがあります。会社や商談には、それぞれの意味に合った取込先があります。
- 文字コードを考慮した読込
- 列とCRM項目の対応付け
- 担当者・会社・商談の取込先
列の対応付け
インポート前に確認
更新、警告、除外の予定を理解する
担当者の計画では、通常のCRMと同じルールで値を正規化します。メール、正規化した電話番号、氏名と読みの完全一致を使って既存の担当者と照合します。同じファイルの中に繰り返し現れる担当者も考慮します。名前のない行は除外します。読みがない場合は、名前を代わりに使い、警告を付けます。正しい読みを推測したと見せるのではなく、確認が必要な状態として扱います。
- 作成・更新の予定
- 既存データとファイル内の照合
- 読みがない場合の警告
取消も、結果を確認して使う
確定した取込には、取消のための情報が残ります。列の対応や元ファイルに問題があったときに役立ちますが、事前の確認を省くためのものではありません。取消には、更新や削除の権限が必要です。取込後に他の人が情報を変えた場合、現在の実装はその変更を無条件に古い状態へ戻さず、並行した変更として保全します。取消後の結果も確認してください。
- 取込単位での修正
- 取消に必要な権限の確認
- 後から行われた変更の保全
具体的な業務の流れ
元ファイルを用意する
代表的な列を確認し、不要な個人情報を除きます。変更していない原本も保管します。
文字コードと列を確認する
氏名が読めること、各列が意図したCRM項目に入ることを確認します。
計画を見直す
作成、更新、除外、警告を確認し、重複や読みの不足も確かめます。
確定して結果を見る
確認済みの計画を適用し、一部のレコードを点検します。取込の誤りが見つかった場合は取消の結果も確認します。
実務を想定した例
利用例：共有顧客表からの移行
長年使っていた顧客表をCRMへ移す制作会社を考えます。表にはメールと電話があり、同じ人が複数の行に現れます。運用担当は代表的なファイルを読み込み、列の対応と、既存担当者へ更新される行を確認します。名前の欠けた行は元データで修正します。その後に取込を確定し、顧客担当のメンバーと一部のレコードを確認します。
この機能についての質問
アップロードすると全行がすぐ書き込まれますか。
確定前に列の対応と変更計画を確認する段階があります。作成、更新、警告、除外を確認してから適用してください。
重複はどのように照合しますか。
メール、正規化した電話番号、最後に氏名と読みの完全一致で照合します。現実のすべての同一人物を判定する保証ではありません。
読みがないと取り込めませんか。
担当者取込では名前を代用し、警告を残します。正しい発音や読みを自動的に生成するとは説明しません。
取消で、後から同僚が変更した情報も消えますか。
現在の実装は取込後の値を確認し、後の並行した変更を保全して結果に示します。無条件に上書きする仕組みではありません。
この業務に合う連携を検討する。
想定される連携のアイデアです。シナリオを利用する前に、各アプリの実際の利用可否、権限、対応データをご確認ください。
