عند التفاعل مع المستخدمين من خلال وكلاء ميزة "الرسائل التجارية"، يُرجى مراعاة أفضل الممارسات التالية.
عدم تقديم معلومات حساسة أو طلبها
يؤدي تجنب المحتوى الحساس أثناء الدردشة إلى الحفاظ على أمان معلومات عملائك. تتضمن المعلومات الحساسة - على سبيل المثال لا الحصر -
- أرقام بطاقات الائتمان
- أرقام التأمينات الاجتماعية أو جواز السفر أو غير ذلك من أرقام إثبات الهوية الصادرة عن الجهات الحكومية
- بيانات اعتماد تسجيل الدخول، مثل كلمات المرور
الرد على المستخدمين بسرعة
وتؤدي أوقات الاستجابة البطيئة أو غير المعقولة لرسائل المستخدمين إلى ترك انطباع سيئ لدى عملائك. تأكد من تصميم البنية الأساسية للاستجابة لتقديم ردود في الوقت المناسب على رسائل المستخدمين.
بل إن الرد الأسوأ من الاستجابة البطيئة هو عدم الاستجابة على الإطلاق. تأكد من أن المستخدمين يتلقون دائمًا الردود على رسائلهم، بصرف النظر عن تحميل الرسائل. على سبيل المثال، إذا لم يكن الموظفون المباشرون متاحين، أرسِل رسالة تلقائية تُعبِّر عن امتنانهم للمستخدم، مع تضمين تقدير للوقت الذي يتوقع فيه المستخدم تلقّي ردّ كامل.
تقيس Google وقت الاستجابة (TTR) بين الرسائل. فإذا كان وكيل العلامة التجارية بطيء في الرد على المستهلكين، فستعمل Google على إزالة أزرار المراسلة الخاصة بالعلامة التجارية.
عندما يتعذّر على التشغيل المبرمَج تنفيذ الطلبات، يُرجى تسليمها إلى فريق الدعم.
يشعر المستخدمون بالإحباط عند عدم الاستجابة التلقائية لها بشكل صحيح. لهذا السبب، يجب أن يكون لدى جميع الوكلاء الذين يتم إطلاقهم من نقاط دخول تديرها Google (باستثناء نقطة إدخال "إعلانات Google") ممثلين عن أشخاص يمكنهم التعامل مع المحادثات عندما يتعذّر على التشغيل المبرمَج ذلك. قبل إطلاق الحملة، عليك تحديد نوع التفاعل مع موظّف الدعم ليتضمّن ممثلون حقيقيون.
عندما يتعذّر على التشغيل المبرمَج تنفيذ طلب المستخدِم مرتين متتاليتين، من الأفضل إرسال رسالة تتضمّن اقتراحًا لطلب موظّف دعم مباشر.
عندما ينقر المستخدم على هذا الاقتراح، يتلقّى وكيلك حدثًا طلبه موظّف دعم مباشر. يجب أن يردّ وكيلك عن طريق تسليم المحادثة إلى أحد ممثلي خدمة العملاء، بحيث يحصل المستخدم على المساعدة التي يحتاجها.
لا يحتاج البشر إلى أن يكونوا متاحين على مدار الساعة طوال أيام الأسبوع. حدِّد مدى توفّر وكيلك حتى يعرف المستخدمون متى يمكنهم توقع استجابة بشرية.
مصادقة المستخدمين باستخدام OAuth
للتحقق من هويات المستخدمين وتوفير معلومات مُخصَّصة لهم، يمكنك مصادقة المستخدمين باستخدام أنظمة الخلفية من خلال OAuth. تؤدي المصادقة باستخدام OAuth إلى منح الوكلاء إمكانية الوصول إلى بيانات المستخدمين بسرعة ومنع المستخدمين أو الوكلاء من تضمين المعلومات الحساسة (مثل أسماء المستخدمين أو كلمات المرور) في المحادثة. راجع المصادقة باستخدام OAuth.
قياس رضا العملاء في الرسائل التجارية
تقيس ميزة "الرسائل التجارية" نتائج مقياس رضا العملاء (CSAT) من خلال استطلاعات الرأي مباشرةً في تجارب المراسلة. لمنع المستخدمين من تلقّي عدّة استطلاعات، يمكنك استخدام وظيفة الاستطلاع في ميزة "الرسائل التجارية". لا تطبّق تقنيات قياس رضا العملاء.
البقاء في الموضوع
لا ترسل رسائل غير مرغوب فيها أو غير ذات صلة بالمحادثة الحالية. على سبيل المثال:
- رسائل حول منتج أو خدمة غير مرتبطة بالطلب الأصلي
- الرسائل المتكررة بدون رد المستخدم
- الرسائل الطويلة بشكلٍ مفرط أو الاستخدام المفرط للرموز التعبيرية وعناوين URL
الاستفادة من رقم تعريف المكان عندما يكون متاحًا
بالنسبة إلى نقاط الإدخال المستندة إلى الموقع الجغرافي، قد تحتوي الرسائل على placeId في البيانات الأساسية للسياق. ويمكنك الاستفادة منه لتقديم معلومات قد يسأل عنها المستخدم، مثل المستودع في موقع جغرافي معيّن. يحدد placeId
مكانًا فريدًا في قاعدة بيانات أماكن Google وفي
منصة خرائط Google.
حتى في حال الإطلاق باستخدام نقاط دخول تستند إلى الموقع الجغرافي، تأكَّد من تنفيذ استراتيجية في الحالات التي لا يتوفّر فيها placeId. على الرغم من عدم شيوع ذلك، إلا أن هناك حالات لا يتم فيها تمرير placeId، من بين البيانات السياقية الأخرى، إلى الرد التلقائي على الويب.
تنفيذ إعادات المحاولات مع التراجع الأسي
عند استدعاء أي واجهة برمجة تطبيقات، من الممكن أن تخفق المكالمة بسبب مشكلات البنية الأساسية، والحمل الزائد على الخدمة، وحدود QPS، والأخطاء الأخرى. لاسترداد البيانات بشكل رشيق من طلبات البيانات من واجهة برمجة التطبيقات التي تعذّر تنفيذها، يمكنك تنفيذ عمليات إعادة المحاولة مع تراجع أسي.
باستخدام عمليات إعادة المحاولة مع التراجُع الأسي، تعمل البنية الأساسية تلقائيًا
- تحديد طلب بيانات من واجهة برمجة التطبيقات تعذّر تنفيذه
- تعيين مدة الانتظار المبدئية والحد الأقصى لعدد مرات إعادة المحاولة
- الإيقاف مؤقتًا لمدة الانتظار
- إعادة محاولة طلب البيانات من واجهة برمجة التطبيقات
لتقييم استجابة استدعاء واجهة برمجة التطبيقات:
- في حال النجاح، يُرجى المتابعة إلى الخطوة التالية في سير العمل
- في حالة الفشل، يزيد وقت الانتظار ويعود إلى الخطوة 3
- إذا تعذّر تنفيذ الحدّ الأقصى لعدد المحاولات المسموح بها، سيتم إدخال حالة تعذّر.
تختلف فترات الانتظار المثالية والحد الأقصى المثالي لمرات إعادة المحاولة باختلاف حالة الاستخدام. حدد هذه الأرقام استنادًا إلى متطلبات وقت الاستجابة للبنية الأساسية وسير الأعمال.
التحقق من وجود رسائل واردة مكررة
عند التحقّق من الرسائل الواردة من المستخدمين والردّ عليها، يمكنك التحقّق من messageId والتحقق من أنّك لم تتلقَّ الرسالة واستجبت لها من قبل.
باستخدام الأنظمة الموزَّعة، هناك طريقتان لإرسال الرسائل: مرة واحدة على الأقل، أو مرة واحدة على الأقل. من خلال أنظمة "مرة واحدة على الأكثر"، يرسل النظام رسالة مرة واحدة، ولكن إذا حدثت أخطاء في الشبكة أو في الاتصال أثناء تنفيذ ذلك، فقد لا يتم استلام الرسالة. وباستخدام أنظمة "مرة واحدة على الأقل"، قد يرسل النظام رسالة عدة مرات، ولكن يمكن استلام الرسالة حتى في حالة وجود أخطاء في الشبكة أو الاتصال.
يستخدم تطبيق "الرسائل التجارية" نظام "مرة واحدة على الأقل". وعلى الرغم من أن هذا يمكن أن يؤدي إلى تكرار الرسائل الواردة، فإنه من السهل إلغاء تكرار الرسائل عن طريق تتبع سلاسل messageId. إذا كنت قد تلقيت رسالة، يمكنك تجاهل أي رسائل إضافية تتلقاها باستخدام messageId نفسه.