يرسل عميل رسالة عبر Instagram يوم الاثنين، ثم يتواصل مع الشركة عبر WhatsApp يوم الأربعاء. القاعدة الآمنة بسيطة: لا تتعامل مع المحادثتين على أنهما لشخص واحد إلا عندما يربط بينهما معرّف ثابت أو خطوة تحقق صريحة. تشابه الاسم أو أسلوب الكتابة أو توقيت الرسالتين لا يكفي.
هذا الحذر مهم لأن تكرار ملف العميل يسبب إزعاجاً، أما الدمج الخاطئ فقد يكشف سجل شخص آخر أو خيارات موافقته أو تفاصيل طلبه أو ملاحظات الدعم الخاصة به. لذلك يجب أن تكون مطابقة هوية العميل عملية تعتمد على الأدلة، لا ميزة تحاول التخمين بذكاء.
ابدأ بمفتاح عميل ثابت
تقدم كل قناة معرّفاً مختلفاً. قد يقدم WhatsApp هوية مرتبطة برقم هاتف. وتستخدم Instagram وMessenger هويات خاصة بالمنصة. وقد يعرف الموقع رقم حساب موثقاً، بينما يحتفظ نظام إدارة العملاء برقم داخلي وعنوان بريد إلكتروني واحد أو أكثر.
ولا تمثل أي من هذه القيم الشخص تلقائياً.
يبدأ التصميم الأقوى بمفتاح عميل ثابت تملكه الشركة، ويكون عادة المفتاح الأساسي في نظام العملاء أو الحسابات أو الطلبات. ولا تضاف معرّفات القنوات إلى هذا المفتاح إلا بعد وجود دليل على العلاقة. بهذه الطريقة يبقى السجل مستقراً عندما يتغير رقم الهاتف، أو يغادر موظف شركته، أو يستخدم العميل حساباً اجتماعياً ثانياً.
يوضح توثيق Twilio الحالي لمطابقة الهوية هذا الفرق بصورة مفيدة. فهو يفصل بين السمات والمعرّفات وقواعد الهوية والملف الموحد، ويعطي معرّف المستخدم الثابت أولوية أعلى من البريد الإلكتروني أو WhatsApp أو رقم الهاتف أو معرّف الدردشة. قد يختلف الترتيب من نظام إلى آخر، لكن المبدأ سليم: ابدأ بالمعرّف الذي تملكه وتفهمه أكثر.
تعامل مع معرّفات القنوات كأدلة
قد يكون رقم الهاتف أو البريد الإلكتروني أو اسم الحساب الاجتماعي دليلاً قوياً. لكنه يظل دليلاً، وليس إثباتاً في كل حالة.
يمكن إعادة تخصيص أرقام الهواتف. وقد تتشارك عائلة عنوان بريد واحداً. وربما يستخدم عدة موظفين صندوق بريد مشتركاً في شركة. كما قد تتكرر الأسماء أو تختلف كتابتها بين اللغات أو تتغير. وحتى رقم الطلب قد يرسله شخص يساعد المشتري.
لهذا لا ينبغي أن تؤدي المطابقة الدقيقة والمطابقة الاحتمالية إلى النتيجة نفسها. تعتمد المطابقة الدقيقة على قيمة تحققت منها الشركة مسبقاً، مثل رقم عميل مسجل الدخول أو تأكيد لمرة واحدة مرتبط بسجل قائم. أما المطابقة الاحتمالية فتعتمد على إشارات مثل تشابه الاسم أو الموقع أو التوقيت أو نمط الشراء.
يمكن للإشارات الاحتمالية أن تقترح تطابقاً على الموظف. لكنها لا ينبغي أن تفتح سجل المحادثات بصمت أو تنشئ دمجاً دائماً.
استخدم سلم ثقة قبل ربط الملفات
يمكن لمسار عملي للهوية أن يستخدم أربع حالات.
- منفصل يعني أن المحادثة الجديدة تحتفظ بهوية القناة من دون إظهار سياق من قنوات أخرى.
- مقترح يعني أن النظام وجد سجلاً محتملاً، لكن الموظف يجب أن يراجع الأدلة.
- موثق يعني أن العميل أو نظاماً موثوقاً لدى الشركة أكد العلاقة عبر معرّف ثابت.
- مرتبط يعني إضافة هوية القناة إلى مفتاح العميل وإتاحة السياق المسموح به في العمل اللاحق.
الانتقال من الحالة المقترحة إلى الموثقة هو عنصر التحكم الأهم. قد يحدث عندما يسجل العميل الدخول، أو يؤكد رمزاً أرسل إلى وسيلة اتصال موجودة، أو يقدم معلومة يجري فحصها مقابل سجل طلب، أو يتبع رابطاً آمناً من حساب موثق. وتعتمد الطريقة المناسبة على مستوى خطر المحادثة.
تصف إرشادات NIST الحالية لإثبات الهوية تقديم الشخص أدلة تسمح بإثبات هويته عند مستوى ثقة مناسب. لا يساوي مسار مراسلة العملاء خدمة مصادقة حكومية، لكن المبدأ القائم على المخاطر مناسب: كلما زادت حساسية الإجراء أو السجل، وجب أن يكون الدليل أقوى.
قد يحتاج سؤال عن منتج إلى تحقق بسيط قبل أن يرى الموظف اهتمامات سابقة. أما نزاع على فاتورة أو سؤال صحي أو تغيير في الحساب فيستحق تحققاً أقوى قبل ظهور أي سجل خاص.
اجعل الخطأ يتجه إلى الخيار الأكثر أماناً
ليست كل أخطاء الهوية متساوية. عندما يبقى سجلان منفصلين، قد يطلب الموظف من العميل تكرار معلومة. أما عندما يدمج النظام شخصين مختلفين، فقد يكشف الموظف أو المسار الآلي معلومات للشخص الخطأ.
توضح إرشادات Intercom لمعرّفات المستخدمين كيف قد تؤدي المعرّفات غير الفريدة أو القيم المؤقتة إلى دمج عملاء مختلفين. كما تحذر من أن ضعف التحقق قد يسمح بانتحال الهوية والوصول غير المصرح به إلى سجل المحادثات. والدرس يتجاوز منصة واحدة: يجب أن يكون مفتاح الهوية فريداً على مستوى مساحة العمل كلها، لا داخل فريق أو تكامل واحد فقط.
استخدم الخيار المحافظ عندما تتعارض الأدلة. أبق السجلات منفصلة، وأوقف أي أتمتة تعتمد على سجل شخصي، وأرسل الحالة إلى موظف يملك الصلاحية المناسبة. من الأسهل شرح خطوة تحقق إضافية من شرح سبب ظهور بيانات عميل آخر في المحادثة.
اجعل كل تغيير في الهوية قابلاً للتراجع
زر الدمج وحده لا يكفي. يجب أن يحتفظ النظام بسجل يوضح ما تغير ولماذا.
احتفظ عند كل ربط أو ترقية أو دمج أو فصل بما يلي:
- مفتاح العميل القديم والجديد
- المعرّفات التي دعمت القرار
- النظام المصدر لكل معرّف
- الشخص أو الأتمتة التي نفذت التغيير
- وقت التغيير
- طريقة التحقق ونتيجتها
- وسيلة تعيد العلاقة السابقة من دون حذف المحادثة الأصلية
وتهم الصلاحيات أيضاً. توثق Genesys صلاحيات منفصلة لربط المحادثات وترقية جهات الاتصال ودمج الهويات. وهذا نموذج مفيد عند التقييم. فالسماح بعرض ملف لا يعني بالضرورة السماح بدمج شخصين بصورة دائمة.
كما يغير إمكان التراجع طريقة التحقيق في الأخطاء. فبدلاً من تعديل الملف حتى يبدو صحيحاً، يستطيع الموظف استعادة العلاقة السابقة، ومعرفة القاعدة التي فشلت، وتصحيح الربط في النظام المصدر.
اختبر الحالات التي تفسد العروض المثالية
لا يثبت العرض الذي يستخدم بريداً واحداً ورقماً واحداً الكثير. اختبر الحالات المزعجة قبل الوثوق بمطابقة الهوية في العمل الفعلي.
- عميلان يستخدمان بريد الأسرة نفسه.
- ينتقل رقم هاتف من موظف إلى آخر.
- يستخدم عميل واحد رقمين على WhatsApp.
- يعيد نظام فروع أو مساحات عمل متعددة استخدام رقم عميل محلي واحد.
- يتطابق اسم عرض على Instagram مع عدة سجلات.
- يحتوي استيراد من نظام العملاء على معرّفات فارغة أو صفرية أو مؤقتة.
- يطلب العميل فصل حساب اجتماعي.
- يدمج الموظف ملفين بالخطأ ثم يحتاج إلى التراجع.
في كل حالة، افحص ما يراه الموظف، وما يمكن للأتمتة استخدامه، وما يدخل في سجل التدقيق، وهل يبقى السياق الخاص مخفياً حتى التحقق. وافحص أيضاً إن كان التصحيح يمنع التطابقات الخاطئة لاحقاً أم يصلح سجلاً واحداً فقط.
اسأل هذه الأسئلة قبل اختيار المنصة
السؤال المفيد عند الشراء ليس ما إذا كانت المنصة تقدم رؤية موحدة للعميل. اسأل كيف تقرر أن هويتين من قناتين مختلفتين تعودان إلى شخص واحد.
يجب أن تجيب المراجعة الجادة عن الأسئلة التالية:
- ما المعرّف الذي يصبح مفتاح العميل الثابت؟
- ما القنوات التي تستطيع إنشاء هذا المفتاح أو تحديثه؟
- هل قواعد المطابقة دقيقة أم احتمالية أم تجمع بينهما؟
- هل يمكن أن يبقى التطابق المقترح من دون ربط حتى يراجعه شخص؟
- ما التحقق الإضافي المطلوب للعمل الحساس؟
- من يملك صلاحية الدمج والفصل؟
- هل يمكن التراجع عن الخطأ من دون فقدان المحادثات؟
- هل يبين سجل التدقيق المصدر والمنفذ والقاعدة والحالة السابقة؟
- هل يمكن إيقاف الأتمتة عندما تكون الهوية غير مؤكدة؟
عند تقييم DripTell، تبدأ المراجعة ذات الصلة من طريقة ظهور المحادثات المدعومة في صندوق وارد الفريق، وطريقة تمثيل بيانات العميل في جهات الاتصال والعملاء المحتملين، وضوابط الوصول الموضحة في صفحة الأمان. نفذ اختبار الهوية باستخدام سجلاتك الصعبة. العرض النظيف لشخص واحد ورقم واحد لا يكفي.
ليس الهدف إزالة كل سجل مكرر فوراً. الهدف هو توفير سياق موثوق يكفي ليتصرف الموظف أو المسار الآلي من دون كشف سجل العميل الخطأ. إذا أردت تطبيق الاختبار على مسار مراسلة حقيقي، أحضر حالة هوية صعبة إلى عرض عملي من DripTell.
DripTell Editorial
إرشادات عملية راجعها فريق المنتج وتجربة العملاء في DripTell.
تعرّف على كيفية التحقق من معلومات المنتج واستخدام المصادر الرسمية وتصحيح الأخطاء.
سياسة التحرير والمصادر