المتطلبات والإرشادات

عند التفاعل مع المستخدمين من خلال موظّفي دعم "الرسائل التجارية"، يُرجى مراعاة أفضل الممارسات التالية.

عدم تقديم معلومات حسّاسة أو طلبها

يساعد تجنُّب المحتوى الحسّاس أثناء المحادثات في الحفاظ على أمان معلوماتك ومعلومات عملائك. تشمل المعلومات الحسّاسة، على سبيل المثال لا الحصر:

• أرقام بطاقات الائتمان
• أرقام التأمينات الاجتماعية أو جواز السفر أو غير ذلك من أرقام إثبات الهوية الصادرة عن الجهات الحكومية
• بيانات اعتماد تسجيل الدخول، مثل كلمات المرور

الردّ على المستخدمين بسرعة

إنّ الردّ على رسائل المستخدمين ببطء أو بمدة غير معقولة يترك انطباعًا سئًا عند عملائك. احرص على تصميم بنية أساسية للردّ تهدف إلى تقديم ردود على رسائل المستخدمين في الوقت المناسب بشكل منتظم.

والأسوأ من بطء الردّ هو عدم الردّ على الإطلاق. تأكَّد من أنّ المستخدمين recebem sempre respostas às suas mensagens، بغض النظر عن عدد الرسائل. على سبيل المثال، إذا لم يكن فريق الدعم المباشر متاحًا، أرسِل رسالة تلقائية للردّ على العميل، مع تضمين تقدير للوقت الذي يمكن أن يتوقّع فيه العميل تلقّي ردّ كامل.

تقيس Google الوقت المستغرَق للردّ (TTR) بين الرسائل. إذا كان موظّف دعم العلامة التجارية يردّ ببطء على المستهلكين، ستزيل Google أزرار المراسلة الخاصة بالعلامة التجارية.

تحويل الطلبات إلى فريق الدعم عندما يتعذّر على الحلول الآلية تلبيتها

يشعر المستخدمون بالإحباط عندما لا تستجيب لهم الحلول المبرمَجة بشكل صحيح. لهذا السبب، يجب أن يتوفّر لدى جميع موظّفي الدعم الذين يبدأون محادثات من نقاط الدخول التي تديرها Google (باستثناء نقطة دخول "إعلانات Google") موظّفو دعم بشريون يمكنهم التعامل مع المحادثات عندما يتعذّر على الحلول المبرمَجة ذلك. قبل الإطلاق، عليك ضبط نوع تفاعل موظّفي الدعم لتضمين موظّفي الدعم البشريين.

عندما يتعذّر على الحلول البرمجية تلبية طلب المستخدم مرتين متتاليتين، من الأفضل إرسال رسالة تتضمّن اقتراحًا لطلب موظّف دعم مباشر.

عندما ينقر المستخدم على هذا الاقتراح، يتلقّى موظّف الدعم حدثًا تطلبه خدمة الدعم المباشر. من المفترض أن يردّ موظّف الدعم من خلال تصعيد المحادثة إلى ممثّل بشري، كي يحصل المستخدم على المساعدة التي يحتاجها.

لا يُشترط أن يكون موظف الدعم متاحًا على مدار الساعة طوال أيام الأسبوع. حدِّد مدى توفّر موظّفي الدعم حتى يعرف المستخدمون متى يمكنهم انتظار ردّ من موظّف دعم.

مصادقة المستخدمين باستخدام OAuth

لإثبات هويات المستخدمين وتقديم معلومات مخصّصة لهم، عليك مصادقة المستخدمين باستخدام أنظمة الخلفية من خلال OAuth. من خلال المصادقة باستخدام OAuth، يحصل موظّفو الدعم على إذن الوصول إلى بيانات المستخدمين بسرعة ويمنعهم من تضمين معلومات حسّاسة (مثل أسماء المستخدمين أو كلمات المرور) في المحادثة. راجِع مقالة المصادقة باستخدام بروتوكول OAuth.

قياس رضا العملاء عن الخدمة في ميزة "الرسائل التجارية"

تقيس ميزة "الرسائل التجارية" "نتائج رضا العملاء" (CSAT) من خلال الاستطلاعات مباشرةً ضمن تجارب المراسلة. لمنع المستخدمين من تلقّي عدة عناوين استطلاعات، استخدِم وظيفة الاستطلاعات في ميزة "الرسائل التجارية". لا تنفِّذ أساليب قياس سعادة العملاء الخاصة بك.

التركيز على الموضوع الحالي

لا ترسل رسائل غير مرغوب فيها أو غير ذات صلة بالمحادثة الحالية. على سبيل المثال،

• الرسائل المتعلّقة بمنتج أو خدمة لا صلة لها بالطلب الأصلي
• الرسائل المتكرّرة التي لم يردّ عليها المستخدم
• رسائل طويلة جدًا أو استخدام زائد عن الحدّ للرموز التعبيرية وعناوين URL

الاستفادة من معرّف المكان عند توفّره

بالنسبة إلى نقاط الدخول المستندة إلى الموقع الجغرافي، قد تحتوي الرسائل على placeId في حمولة السياق. ويمكنك الاستفادة منها لتقديم معلومات قد يسأل عنها العميل، مثل المستودع في موقع جغرافي معيّن. يحدِّد placeId مكانًا بشكلٍ فريد في قاعدة بيانات "أماكن Google" ومنصة خرائط Google.

حتى إذا كنت تطلِق التطبيق باستخدام نقاط دخول مستندة إلى الموقع الجغرافي فقط، احرص على تنفيذ استراتيجية للحالات التي لا تتوفّر فيها placeId. على الرغم من أنّه ليس شائعًا، هناك حالات لا يتم فيها تمرير placeId إلى رابط تجميع البيانات، إلى جانب بيانات سياقية أخرى.

تنفيذ عمليات إعادة المحاولة باستخدام خوارزمية الرقود الأسي الثنائي

عند طلب أي واجهة برمجة تطبيقات، من الممكن أن يتعذّر إكمال الطلب بسبب مشاكل في البنية التحتية أو زيادة عدد عمليات طلب البيانات عن الحدّ المسموح به أو تجاوز حدود معدّل طلب البيانات في الثانية أو أخطاء أخرى. لاسترداد التطبيقات بشكلٍ سلس من طلبات البيانات من واجهة برمجة التطبيقات التي تعذّر تنفيذها، عليك تنفيذ عمليات إعادة المحاولة باستخدام خوارزمية الرقود الأسي الثنائي.

باستخدام عمليات إعادة المحاولة مع خوارزمية الرقود الأسي الثنائي، ستتم تلقائيًا

1. لتحديد طلب بيانات من واجهة برمجة التطبيقات تعذّر تنفيذه
2. لضبط مدة الانتظار الأولية والحد الأقصى لعدد عمليات إعادة المحاولة
3. يتم إيقافه مؤقتًا لمدة الانتظار
4. إعادة محاولة طلب البيانات من واجهة برمجة التطبيقات

5. تقييم استجابة طلب البيانات من واجهة برمجة التطبيقات:

   • في حال نجاح الإجراء، يتم المتابعة إلى الخطوة التالية في سير العمل.
   • في حال حدوث خطأ، يتم زيادة مدة الانتظار والرجوع إلى الخطوة 3.
   • في حال حدوث خطأ بعد الحد الأقصى لعدد عمليات إعادة المحاولة، يتم الدخول إلى حالة تعذُّر

تختلف مدّات الانتظار المثالية والحدّ الأقصى المثالي لعدد عمليات إعادة المحاولة حسب حالة الاستخدام. حدِّد هذه الأرقام استنادًا إلى متطلبات وقت الاستجابة لبنية الأساس وعمليات سير العمل.

البحث عن رسائل واردة مكرّرة

عند الاطّلاع على الرسائل الواردة من المستخدمين والردّ عليها، ضَع علامة في المربّع بجانب الرسالة messageId وتأكَّد من أنّك لم تتلقّى الرسالة من قبل وتردّ عليها.

في الأنظمة الموزّعة، هناك طريقتان لإرسال الرسائل: مرة واحدة على الأكثر ومرة واحدة على الأقل. في الأنظمة التي تُرسِل الرسائل "مرة واحدة بحد أقصى"، يُرسِل النظام رسالة مرة واحدة، ولكن في حال حدوث أخطاء في الشبكة أو الاتصال أثناء عملية الإرسال، قد لا يتم استلام الرسالة. في الأنظمة التي تستخدم الإعداد "مرة واحدة على الأقل"، قد يرسل النظام رسالة متعدّدة المرات، ولكن يمكن استلام الرسالة حتى في حال حدوث أخطاء في الشبكة أو الاتصال.

تستخدِم ميزة "الرسائل التجارية" نظام "مرة واحدة على الأقل". على الرغم من أنّ ذلك قد يؤدي إلى تكرار الرسائل الواردة، من السهل إزالة تكرار الرسائل من خلال تتبُّع سلاسل messageId. إذا سبق لك تلقّي رسالة، يمكنك تجاهل أي رسائل إضافية تصلك باستخدام messageId نفسه.