שיטות מומלצות

ממשק משתמש שיחה, לא ממשק משתמש של אפליקציה

סוכני RBM מתאימים מאוד להצגת משימות יעילות וספציפיות למשתמשים בממשק משתמש שיחה. הסוכנים המעוצבים ביותר שומרים על אינטראקציה, קלים להבנה ובנויים כמו שיחה טבעית.

הסוכנים לא יכולים להסתמך על ממשק המשתמש החזותי של אפליקציה או דף אינטרנט, ואין לנסות לחקות אותם. במקום זאת, הנציגים צריכים להסתמך על שיחות שנוצרו בקפידה כדי לתת מענה לצרכים של המשתמשים, על ידי מתן הנחיות מילוליות, הצעות וטיפול בשגיאות.

כמו כן, אסור לסוכנים שמחקים עצי טלפון, או ממשקים שמסתמכים על משתמשים שמגיבים למספר שמייצג פעולה מסוימת. למשתמשים אמורה להיות אפשרות לתקשר עם הנציגים בצורה טבעית, בדומה לחיבור עם אדם אחר בשיחה.

מידע נוסף על ממשק המשתמש של השיחות מפורט במאמר ממשק משתמש לשיחות ולמה הוא חשוב.

בדיקת היכולות של המכשיר

לפני שמתחילים שיחה עם משתמש, צריך לוודא שהמכשיר של המשתמש יכול לקבל הודעות RCS. צריך לשלוח בקשה ליכולת כדי לזהות את היכולות של המכשיר ולהתאים את האינטראקציות של הנציג בהתאם. יש לנהל אינטראקציה עם המשתמשים רק בדרכים שבהן המכשירים שלהם תומכים. אם במכשיר של משתמש מסוים אין תמיכה ב-RCS, צריך להגדיר שיטת תקשורת חלופית באמצעות טכנולוגיה אחרת, כמו SMS.

איך מתחילים שיחות חדשות?

השיחה מתחילה עם הציפיות של המשתמש מה הוא יכול לעשות. אפשר להתחיל שיחות בדיון מעמיק: עדיף להציג את האישיות של הנציג, לטעון את המידע שמוצג למשתמשים ולטפל במה שחשוב לו. חשוב לתת למשתמשים אפשרויות ברורות לאינטראקציה עם הנציג ולהמשך השיחה.

שיחה עם לוגו, שם ותיאור

שמירה על קצב טוב

כשאתם משתמשים בסוגים שונים של מידע בשיחות, המשתמשים מקיימים אינטראקציה עם הנציג ומטפלים בו, אבל חשוב לא להעמיס את המשתמשים. כדאי לשמור על אורך ההודעות קצר ופשוט, כך שהמשתמשים יוכלו לראות את כל ההודעה במסך בבת אחת. תמונות וכרטיסים עשירים יכולים לתפוס הרבה מקום במסך, לכן חשוב לשים לב לכמות שהמשתמשים צריכים לגלול כדי לקרוא את כל ההודעה.

שמירה על סדר בהודעות

אם אתם שולחים כמה הודעות ברצף, חשוב שהמשתמשים יקבלו את ההודעות האלה לפי הסדר. העיבוד של הודעות מסוימות, כמו הודעות שכוללות מדיה, נמשך זמן רב יותר מאשר הודעות אחרות, כמו הודעות טקסט בלבד. כדי לוודא שהמשתמשים יקבלו את ההודעות לפי הסדר שבו הן נשלחו, תצטרכו לחכות עד לקבלת תגובה מ-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.

רוצה לעזור למשתמש?

הנציג צריך לענות להודעות HELP של משתמשים ולהסביר למשתמשים מהן היכולות שלו. משהו פשוט כמו רשימה של הצעות לתשובות שתואמות לפונקציונליות של הנציג יכול להפוך את חוויית המשתמש לגרועה.

יישום ניסיונות חוזרים עם השהיה מעריכית

כשמתקשרים ל-API, יכול להיות שקריאה תיכשל בגלל בעיות בתשתית, עומס יתר בשירות, מגבלות ב-QPS ושגיאות אחרות. כדי לשחזר בחינימות מקריאות API שנכשלו, צריך לנסות ניסיונות חוזרים עם השהיה מעריכית.

באמצעות ניסיונות חוזרים עם השהיה מעריכית, התשתית מבצעת באופן אוטומטי את הפעולות הבאות:

  1. מזהה קריאה ל-API שנכשלו.
  2. מגדירה את משך ההמתנה הראשוני ואת המספר המקסימלי של ניסיונות חוזרים.
  3. השהיות למשך ההמתנה.
  4. ניסיון נוסף של קריאת ה-API.
  5. הערכת התגובה לקריאה ל-API:

    • אם התגובה לבקשה מוצלחת, ממשיך לשלב הבא בתהליך העבודה.
    • במקרה של כשל, משך ההמתנה יתארך ויגיע לשלב 3.
    • אם הפעולה נכשלה אחרי המספר המקסימלי של ניסיונות חוזרים, היא עוברת למצב 'נכשל'.

זמני ההמתנה האידאליים והמספר המקסימלי האידיאלי של ניסיונות חוזרים משתנים בהתאם לתרחיש לדוגמה. הגדירו את המספרים האלה בהתאם לדרישות זמן האחזור של התשתית ותהליכי העבודה שלכם.

כרטיסים מתקדמים

כרטיסים עשירים מאפשרים לכם לשלב מדיה, טקסט והצעות בהודעה אחת. לכן, מדיה לא צריכה להיות הרכיב היחיד בכרטיס Rich, והצעות לתשובות או פעולות מוצעות תמיד צריכות להתלוות לצ'אט אינטראקטיבי עצמאי.

צ'אט אינטראקטיבי שמציג רק תמונה ופעולה

כרטיסי תצוגה עשירה

כרטיסים עשירים מסוג אנכי מציגים מדיה אופקית בחלק העליון של הכרטיס. למדיה אופקית צריך להיות יחס גובה-רוחב של 2:1, 16:9 או 7:3.

כששולחים מדיה למשתמש, צריך לכבד את המשאבים של המשתמש. במדיה אופקית יש יחס של 2:1, הרזולוציה האופטימלית של המדיה היא 1440x720 פיקסלים עם גודל קובץ מומלץ מקסימלי של 2MB לתמונות, ו-10MB לווידאו. הרזולוציה האופטימלית של התמונה הממוזערת של המדיה היא 770x335 פיקסלים, וגודל הקובץ המומלץ הוא 40kB, והגודל המקסימלי המומלץ הוא 100kB.

כרטיסי תצוגה עשירה לרוחב

כרטיסים עם מדיה עשירה מציגים מדיה אנכית בצד הימני או הימני של הכרטיס. מדיה אנכית צריכה להיות ביחס גובה-רוחב של 3:4.

כששולחים מדיה למשתמש, צריך לכבד את המשאבים של המשתמש. כאשר למדיה אנכית יש יחס של 3:4, הרזולוציה האופטימלית של המדיה היא 768x1024 פיקסלים עם גודל קובץ מומלץ מקסימלי של 2MB לתמונות ו-10MB לווידאו. הרזולוציה האופטימלית של התמונה הממוזערת של המדיה היא 250x330 פיקסלים, עם גודל קובץ מומלץ של 40kB וגודל מקסימלי מומלץ של 100kB.

קרוסלות עם כרטיסים מתקדמים

קרוסלות עם כרטיסים עשירים הן אידיאליות לגלישה בתוכן או לאפשרויות שונות, אבל כדאי להשתמש בהן רק כשיש יותר מפריט אחד לקריאה או להשוואה, למשל חבילות נתונים או מכשירים. הפריט הראשון בקרוסלה צריך להיות הבחירה האופטימלית בכל מצב נתון, וצריך להסביר למשתמש למה כדאי להשתמש בה.

הצ'יפים של ההצעות שמתחת לקרוסלה צריכים לקדם או להזיז את השיחה. צ'יפים של הצעות לא צריכים לחזור על האפשרויות שמפורטות בקרוסלה, והם לא כלים לבחירת הפריטים שמופיעים בקרוסלה.

דוגמה לקרוסלה של כרטיס עשיר

מדיה בקרוסלות של כרטיסים מתקדמים

בקרוסלות של כרטיסים משופרים מוצג מדיה אופקית בחלק העליון של כרטיסי תצוגה עשירה. מדיה אופקית בקרוסלה צריכה להיות ביחס גובה-רוחב של 4:3.

כששולחים מדיה למשתמש, צריך לכבד את המשאבים של המשתמש. כאשר המדיה היא ביחס גובה-רוחב של 4:3, הרזולוציה האופטימלית של המדיה היא 960x720 פיקסלים עם גודל קובץ מקסימלי של 1MB לתמונות ו-5MB לווידאו. הרזולוציה האופטימלית של התמונה הממוזערת של המדיה היא 605x452 פיקסלים, עם גודל קובץ מומלץ של 40kB וגודל מקסימלי מומלץ של 100kB.

הצעות לתשובות ופעולות

הצעות לפעולות ופעולות בכרטיס עשיר צריכות להתייחס ישירות לתוכן בכרטיס הזה.

הצעות לתשובות ולפעולות ברשימת הצ'יפים צריכות להיות דרכים לקדם את השיחה או להצביע עליה.

הצעות לתשובות

הצעות לתשובות עוזרות למשתמשים לענות לנציג שלכם כך שהם יוכלו לענות לו בקלות. כדאי להשתמש בתגובות המוצעות, אלא אם האינטראקציה דורשת תגובה חופשית. קל יותר לעבד אותן מאשר טקסט חופשי, והן מאפשרות לסוכן שלכם לכוון את השיחות במסלול אופטימלי.

הצעות לפעולות

הצעות לפעולות מאפשרות לנציג לבצע פעולות במכשיר המקורי ולספק למשתמש חוויה משולבת מאוד. בעזרת הצעות לפעולות רלוונטיות, תוכלו להתקשר בקלות לתמיכת הלקוחות או למצוא מיקום במפה.

עם זאת, אל תציבו את המשתמשים באפשרויות. יש לספק רק פעולות הקשורות להודעה האחרונה, ולספק רק פעולות רצויות. כדאי להגביל את מספר ההצעות לפעולות ולתשובות מוצעות למשתמשים בהתאם להקשר.

סיכום לגבי העיצוב

כשיוצרים את הנציג חשוב מאוד לתכנן את השיחה, נוחות השימוש ויעילות השימוש. הנציגים צריכים להתמקד בממשק המשתמש של השיחה ולהדריך את המשתמשים בתהליכי עבודה אופטימליים, עם הצעות לתשובות ולפעולות. כשמשתמשים בתמונות או בכרטיסים עשירים, הסוכן צריך לשמור על קצב שמאפשר למשתמשים לשמור על הקשר ולקרוא הודעות בקלות.

כשאתם בונים את הנציג, חשוב לשים לב לחוויית המשתמש ולהימנע מכשלים בשיחה, כך שהמשתמשים ייהנו מחוויה חיובית והם יהיו מוכנים להשתמש בו שוב.