واجهة مستخدم للمحادثات، وليس واجهة مستخدم تطبيق
يناسب وكلاء RBM بشكل جيد إمكانية توفير مهام فعّالة ومحدّدة للمستخدمين في واجهة مستخدم تستند إلى المحادثات. يعمل الوكلاء المصممون بشكل أفضل على إبقاء التفاعلات مركزة وسهلة الفهم ومنسّقة، مثل المحادثات الطبيعية.
لا يمكن أن يعتمد الوكلاء على واجهة المستخدم المرئية لتطبيق أو صفحة ويب، وألا يحاولوا تقليدها. وبدلاً من ذلك، يحتاج الوكلاء إلى الاعتماد على المحادثات التي تم إعدادها بعناية وتلبّي احتياجات المستخدمين عن طريق توجيههم من خلال إشارات شفهية واقتراحات ومعالجة جيدة للأخطاء.
على الوكلاء أيضًا عدم تقليد أشجار الهاتف أو الواجهات التي تعتمد على استجابة المستخدمين لرقم يمثّل إجراءً معيّنًا. من المفترض أن يتمكن المستخدمون من التواصل مع الوكلاء بشكل طبيعي، تمامًا كما يتواصلون مع شخص آخر في إحدى المحادثات.
للحصول على مزيد من المعلومات حول واجهة مستخدم المحادثة، يمكنك الاطّلاع على واجهة مستخدم المحادثة وأهمية ذلك.
التحقّق من إمكانات الجهاز
قبل بدء محادثة مع أحد المستخدمين، تأكَّد من أنّ جهاز المستخدم يمكنه تلقّي رسائل خدمات الاتصالات التفاعلية (RCS). أرسِل طلب الإمكانيات لتحديد إمكانيات الجهاز وتخصيص تفاعلات وكيلك وفقًا لذلك. التفاعل مع المستخدمين بطرق تتوافق مع أجهزتهم فقط في حال عدم تفعيل جهاز الاتصالات التفاعلية (RCS)، يجب إعداد طريقة احتياطية للتواصل باستخدام تقنية أخرى، مثل الرسائل القصيرة.
بدء محادثة
يحدّد بداية محادثة توقّعات المستخدم بشأن ما يمكن أن يفعله الوكيل. ويُفضَّل بدء محادثات عن طريق ملاحظة قوية: تُظهر الشخصية المتاحة لوكيلك ويوفّر معلومات واضحة يهتم بها المستخدمون ويشاركهم ما يستطيع الوكيل فعله. قدِّم للمستخدمين خيارات واضحة للتفاعل مع الوكيل ومواصلة المحادثة.
الحفاظ على الإيقاع الجيد
إنّ استخدام أنواع مختلفة من المعلومات في المحادثات يحافظ على تفاعل المستخدمين مع وكيلك والتفاعل معه، ولكن يجب الحرص على عدم إرباك المستخدمين. احتفِظ بالرسائل ضمن أطوال طويلة وسهلة الفهم تسمح للمستخدم بمشاهدة الرسالة بأكملها على الشاشة في آنٍ واحد. يمكن أن تستهلك الصور والبطاقات التفاعلية مساحة كبيرة من الشاشة، لذا عليك الانتباه إلى حجم المستخدم الذي يحتاج إلى التمرير لقراءة الرسالة بأكملها.
الاحتفاظ بالرسائل بالترتيب
إذا أرسلت رسائل متعددة بالتسلسل، من المهم أن يتلقّى المستخدمون هذه الرسائل بالترتيب. تستغرق بعض الرسائل، مثل تلك التي تتضمن الوسائط، وقتًا أطول في المعالجة من غيرها، مثل الرسائل النصية فقط. لضمان
تلقّي المستخدمين الرسائل بالترتيب المُرسَل إليهم، يُرجى الانتظار
حتى تتلقّى ردًّا 200 OK على الرسالة قبل إرسال الرسالة التالية
في التسلسل.
تؤكد استجابة 200 OK أن منصة RBM تلقّت الرسالة وأن المستخدم يجب أن يتلقّى رسائلك بالترتيب الصحيح. وإذا لم
تنتظر ردًا من 200 OK قبل إرسال رسالة أخرى، قد يتلقّى المستخدمون
رسائلك غير مرتبة.
التحقّق من الرسائل الواردة
عندما تتحقّق من الرسائل الواردة من المستخدمين وتردّ عليها، تحقّق من
messageId وتأكَّد من عدم تلقّي الرسالة
والرد عليها سابقًا.
مع الأنظمة الموزّعة، هناك طريقتان لإرسال الرسائل: في آنٍ واحد، على الأقل في مرة واحدة.
- في أنظمة "مرة واحدة" على الأكثر، يرسل النظام رسالة مرة واحدة، ولكن إذا حدثت أخطاء في الشبكة أو في الاتصال، قد لا يتم استلام الرسالة.
- باستخدام الأنظمة "مرة واحدة على الأقل"، قد يُرسِل النظام رسالة عدة مرات، ولكن يمكن تلقّي الرسالة حتى في حال حدوث أخطاء في الشبكة أو الاتصال.
تستخدم خدمة Google Cloud Pub/Sub نظام "مرة واحدة على الأقل". على الرغم من أنّ ذلك قد يؤدي إلى تكرار الرسائل الواردة، يمكنك بسهولة إلغاء تكرار الرسائل من خلال تتبُّع سلاسل messageId. إذا سبق أن تلقّيت رسالة،
يُرجى تجاهل أي رسائل إضافية تتلقّاها باستخدام
messageId نفسه.
كتابة رسائل واضحة ومتّسقة
أرسِل رسائل جذابة وسهلة الفهم. يشجّع نص الرسالة الجيدة على استجابة المستخدمين والاتّساق في نمط النص وتنسيقه وإيقاعه بناءً على ثقة المستخدمين.
يُرجى مراعاة أفضل الممارسات الإضافية التالية عند إنشاء نص الرسالة:
- لا تنشئ نهاية مسدودة. ويجب أن يؤدي كل رد مقترَح إلى سلسلة محادثات ذات مغزى مع المستخدم.
- إذا لزم الأمر، ضَع اسم المستخدم بصفتك "أنت" وليس "أنا".
- بالنسبة إلى العناوين والتصنيفات، استخدِم حالة أحرف الجملة بدلاً من حالة العنوان. على سبيل المثال، "كشف الحساب"، وليس "بيان الحساب".
- يمكنك استخدام التقلّبات. "إنّه أكثر محادثة" من "إنه".
- استخدِم علامات التعجب باعتدال.
- استخدِم الفاصلة التسلسلية. على سبيل المثال، "A وB وC" وليس "A وB وC".
- اكتب الأرقام كأرقام. على سبيل المثال، "1، 2، 3"، وليس "واحد، اثنان، ثلاثة".
الاحترام عندما لا يريد المستخدمون الرسائل
عندما يشير مستخدم إلى أنه يريد إيقاف استلام الرسائل من وكيلك، عليك مراعاة خياره. يجب أن يفهم وكيلك الحالات التي يرد فيها المستخدمون على "STOP" وأن يتفاعلوا بشكل مناسب. يجب أن يفهم وكيلك الطرق المختلفة التي يمكن أن يستخدمها المستخدمون لإيقاف تلقّي الرسائل، بما في ذلك جميع اللغات التي قد يستخدمونها للتواصل مع العملاء.
يُرجى الرجوع إلى القوانين وأفضل الممارسات المتّبعة في بلدك بخصوص طريقة الاستجابة لأمر STOP وغيره من الأوامر الإلزامية. على سبيل المثال، يمكنك الاطّلاع على أفضل ممارسات CTIA.
مساعدة المستخدم
يجب أن يردّ موظّف الدعم على رسائل "المساعدة" الواردة من المستخدمين ويقدّم لهم معلومات حول إمكانيات الوكيل. أي أمر بسيط مثل قائمة بالردود المقترَحة التي تتوافق مع وظيفة الوكيل، يحوّل المستخدم إلى تجربة سيئة.
تنفيذ إعادة المحاولة باستخدام خوارزمية الرقود الأسي
عند الاتصال بأي واجهة برمجة تطبيقات، من الممكن أن يتعذّر إجراء مكالمة بسبب مشاكل البنية الأساسية أو زيادة الحمل على الخدمة أو حدود عدد الطلبات في الثانية (QPS) أو أخطاء أخرى. للاسترداد بشكل سليم من طلبات البيانات من واجهة برمجة التطبيقات التي تعذّر تنفيذها، يمكنك تنفيذ عمليات إعادة المحاولة مع التردّد الأسي.
باستخدام عمليات إعادة المحاولة مع الرقود الأسي، تنفِّذ البنية الأساسية ما يلي تلقائيًا:
- يحدد طلب البيانات من واجهة برمجة التطبيقات الذي تعذّر تنفيذه.
- تضبط هذه السياسة مدة الانتظار الأولية والحد الأقصى لعدد إعادة المحاولة.
- يتوقف مؤقتًا لمدة الانتظار.
- إعادة محاولة طلب البيانات من واجهة برمجة التطبيقات
تقييم استجابة طلب البيانات من واجهة برمجة التطبيقات:
- في حال نجاح هذا الإجراء، يمكنك المتابعة إلى الخطوة التالية في سير العمل.
- وفي حال عدم نجاح العملية، يؤدي ذلك إلى زيادة مدة الانتظار والعودة إلى الخطوة 3.
- إذا تعذّر إتمام الحدّ الأقصى بعد إعادة المحاولة، سيُدخل حالة تعذّر.
تختلف مدد الانتظار المثالية والحد الأقصى المثالي لإعادات المحاولة حسب حالة الاستخدام. يمكنك تحديد هذه الأرقام استنادًا إلى متطلبات وقت الاستجابة في البنية الأساسية وسير العمل.
بطاقات البحث الذكية
تسمح لك البطاقات التفاعلية بدمج الوسائط والنص والاقتراحات في رسالة واحدة. وبناءً على ذلك، يجب ألا تكون الوسائط العنصر الوحيد في البطاقة التفاعلية، كما يجب أن تكون الردود المقترحة أو الإجراءات المقترحة مرفقة دائمًا ببطاقة منسّقة مستقلة.
البطاقات المنسَّقة في الوضع العمودي
تعرِض البطاقات التفاعلية العمودية الوسائط الأفقية في أعلى البطاقة. يجب أن تكون الوسائط الأفقية بنسبة عرض إلى ارتفاع 2:1 أو 16:9 أو 7:3.
عند إرسال الوسائط إلى أحد المستخدمين، يجب أن تحترم موارد المستخدم. عندما تكون الوسائط الأفقية ذات نسبة عرض إلى ارتفاع 2:1، تكون درجة الدقة المثلى للوسائط 1440x720 بكسل والحد الأقصى لحجم الملف المقترَح هو 2 ميغابايت للصور و10 ميغابايت للفيديو. إنّ درجة الدقة المثالية للصورة المصغّرة للوسائط هي 770x335 بكسل وبحجم ملف مقترَح يبلغ 40 كيلوبايت والحد الأقصى المقترَح 100 كيلوبايت.
البطاقات التفاعلية الأفقية
وتعرِض البطاقات المنسّقة الأفقية الوسائط العمودية على الجانب الأيسر أو الأيمن من البطاقة. يجب أن تكون نسبة العرض إلى الارتفاع في الوسائط العمودية 3:4.
عند إرسال الوسائط إلى أحد المستخدمين، يجب أن تحترم موارد المستخدم. عندما تكون الوسائط الرأسية بنسبة 3:4، ستكون الدقة المثالية للوسائط 778x1024 بكسل والحد الأقصى لحجم الملف المقترَح هو 2 ميغابايت للصور 10 ميغابايت للفيديو. وتبلغ درجة الدقة المثالية للصورة المصغّرة للوسائط 250x330 بكسل وحجم الملف المقترَح هو 40 كيلوبايت والحد الأقصى المقترَح 100 كيلوبايت.
منصّات العرض بعناصر متغيّرة للبطاقات التفاعلية
إنّ لوحات العرض الدوّارة للبطاقات التفاعلية مثالية لعرض المحتوى أو خيارات متنوّعة، ولكن يجب عدم استخدامها إلا عندما تتوفّر عناصر متعدّدة لقراءتها أو مقارنتها، مثل خطط البيانات أو الأجهزة. يجب أن يكون العنصر الأول في لوحة العرض الدوّارة هو الخيار الأمثل في أي موقف، ويجب إخبار المستخدم بالسبب وراء هذا الخيار الأمثل.
يجب أن تؤدي شرائح الاقتراحات أسفل لوحة العرض الدوّارة إلى تقديم المحادثة أو تغيير محورها. يجب ألا تكرّر شرائح الاقتراحات الخيارات المدرجة في لوحة العرض الدوّارة وألا تكون أدوات محدّدة للعناصر المعروضة في لوحة العرض الدوّارة.
الوسائط في لوحات العرض الدوّارة للبطاقة التفاعلية
تظهر في لوحات العرض الدوّارة للبطاقة التفاعلية وسائط أفقية في أعلى البطاقات التفاعلية. يجب أن تكون نسبة العرض إلى الارتفاع في الوسائط الأفقية في لوحات العرض الدوّارة 4:3.
عند إرسال الوسائط إلى أحد المستخدمين، يجب أن تحترم موارد المستخدم. عندما تكون نسبة العرض إلى الارتفاع في الوسائط 4:3، تكون درجة الدقة المثلى للوسائط هي 960x720 بكسل وحجم ملف يصل إلى 1 ميغابايت للصور و5 ميغابايت للفيديو. وتبلغ درجة الدقة المثالية للصورة المصغّرة للوسائط 605×452 بكسل وحجم الملف المقترَح هو 40 كيلوبايت والحد الأقصى المقترَح هو 100 كيلوبايت.
الردود والإجراءات المقترَحة
يجب أن ترتبط الردود والإجراءات المقترَحة داخل البطاقة المنسّقة مباشرةً بالمحتوى المضمّن في هذه البطاقة.
يجب أن تكون الردود والإجراءات المقترَحة ضمن قائمة الشرائح طرقًا التقدم أو تغيير المحادثة.
الردود المقترَحة
تساعد الردود المُقترَحة المستخدمين على الردّ على وكيلك بطرق يمكنه الردّ عليها بسهولة. ما لم يتطلب التفاعل ردًا ذي تصميم مرن، استخدم الردود المقترحة. وهي أسهل من المعالجة باستخدام النصوص ذات التصميم المرن، وتتيح لهم توجيه المحادثات إلى المسار الأمثل.
إجراءات مقترحة
تتيح الإجراءات المقترَحة للوكيل رصد إجراءات الجهاز الأصلية وتقديم تجربة متكاملة للمستخدم. وتسهّل الإجراءات المقترَحة إمكانية التواصل مع فريق دعم العملاء أو العثور على موقع جغرافي على الخريطة، وذلك في حال كان ذلك ملائمًا.
ولكن لا تُربك المستخدمين بالخيارات. لا تقدم سوى إجراءات ذات صلة بأحدث رسالة، واحرص على توفير أكبر عدد ممكن من الإجراءات حسب الضرورة. الحد من عدد الإجراءات المقترحة والردود المقترحة على ما يفيد المستخدم في سياق معيّن
تصميم ملخّص
إنّ تصميم المحادثة والقابلية للاستخدام والكفاءة هو عاملان مهمان عند إنشاء وكيلك. على الوكلاء التركيز على واجهة المستخدم بأسلوب المحادثة وتوجيه المستخدمين خلال سير العمل الأمثل مع الردود والإجراءات المقترحة. عند استخدام الصور أو البطاقات التفاعلية، يجب أن يحافظ الوكيل على الإيقاع الذي يتيح للمستخدمين الاحتفاظ بالسياق وقراءة الرسائل بسهولة.
إنّ مراعاة تجربة المستخدم وتجنُّب النهاية النهائية للمحادثة عند تصميم وكيلك توفّر تجارب إيجابية للمستخدمين وتجعلهم مستعدين لاستخدام وكيلك مرة أخرى في المستقبل.