LINEの顧客データを統合するとき｜同名の人を誤ってまとめない確認手順

LINEの会話と購入・予約の情報を一人のお客さんへつなぐときは、名前が同じだからという理由だけで統合しないでください。一つのIDへ情報をまとめる目的は、担当が替わっても文脈を引き継ぐことです。別の人の注文や相談を見せてしまう統合は、その目的に反します。

移行や連携では、確かめられた対応関係と、候補の一致を分けます。判断できないものを確認待ちに残せることも、顧客データの設計に必要です。

表示名、LINE ID、ユーザーIDを区別する

LINE DevelopersのユーザーIDの公式案内は、ユーザーIDが表示名や友だち検索に使うLINE IDとは異なる識別子であることを説明しています。同じ人でもプロバイダーが異なれば値は異なり、同じプロバイダーではチャネルの種類にかかわらず同じユーザーIDになります。

この仕様は、プロバイダーをまたいでも同じ文字列で本人を認識できるという意味ではありません。別々の店舗・サービスのデータを取り込む場合は、どの範囲で発行されたIDかを、値と一緒に管理します。

同じプロバイダーのユーザーIDであっても、自社会員IDとの対応は別に確認します。LINE上の人を識別できたことと、その人がどの会員・注文に対応するかを確定できたことは、分けて扱います。

顧客の姓名、連絡先、購入、会話が複数のシステムにある場合、最新の値で全部を上書きすると、本人が変更した情報と、担当が補足したメモが混ざることがあります。

項目ごとに、どこを正本にするかを決めます。会員情報は会員管理、注文は注文管理、LINEの会話は受信した会話記録、といった整理です。統合画面では必要な情報をまとめて見せても、更新元と確定した時点を追えるようにします。

相談のために必要な情報をつなぐことと、すべての履歴を全担当へ見せることも別です。店舗や業務に応じた閲覧範囲を維持し、情報を統合したことを権限拡大の理由にしないでください。

次の表は、照合を整理するための例です。どの根拠を採用できるかは、利用する仕組みと本人確認の手順に合わせて決めます。

一致しない候補を無理に選ぶより、未確定のまま相談を続けられる運用を用意します。会員情報が未連携でも、一般的な案内はできる場合があります。個別の注文内容を開示する段階では、必要な本人確認へ進みます。

同じ人かを確かめる。正本を決める：顧客IDと連携元を整理。一致候補を出す：表示名だけでは確定しない。本人との連携を確認：根拠が不足すれば保留。記録して反映：誤った連携を戻せるようにする。

図：同じ人かを確かめる。細かな条件と例外は、本文で確認してください。

連携を確定するときは、どの情報を、何の根拠で、いつ、どの処理が紐づけたかを残します。元のデータをすぐ削除して一つにまとめるより、対応関係として管理するほうが、誤りを見つけたときに確認しやすい場合があります。

戻す手順では、会員へのリンクだけでなく、予約・購入の表示、配信対象、担当のメモ、別システムへ渡した情報を確認します。リンクを解除しても、誤った人物の情報をコピーした記録が残っていれば、問題が解決したとは言えません。

解除や再確認の処理は、利用するシステムの仕様に合わせて設計します。LINEのブロック、会員の退会、データ連携の解除を、同じ意味の操作として一律に扱わないでください。連携方法の全体像は、LINEのID連携で整理しています。

本番の顧客情報を使わず、架空のデータで照合の境界をテストします。同名の二人、連絡先を共有する家族、異なるプロバイダーのID、旧IDが欠けた人、複数候補がある人を含めてください。

確定できるものだけが連携されるか、未確定の人は確認待ちに残るか、誤連携を戻したあとに他人の情報が見えないかを確認します。統合できた件数と、確認待ちの件数は別々に報告します。確認待ちを減らすために弱い一致を確定するのではなく、お客さんに必要な確認を分かりやすく案内するところから見直してください。