בדף הזה מפורטות שיטות מומלצות ליצירת חוויות יעילות ומעניינות של RCS Business Messaging, כולל הטמעה טכנית ועיצוב שיחה.
הנחיות טכניות
בדיקת היכולות של המכשיר
לפני שמתחילים שיחה עם משתמש, צריך לוודא שהמכשיר של המשתמש יכול לקבל הודעות RCS. כדי לזהות את היכולות של המשתמש, שולחים בדיקת יכולות ומתאים אישית את האינטראקציות של הנציג בהתאם. ליצור אינטראקציה עם המשתמשים רק בדרכים שהמכשירים שלהם תומכים בהן. אם במכשיר של המשתמש אין תמיכה ב-RCS, צריך להגדיר שיטת תקשורת חלופית בערוץ אחר, כמו SMS.
לשמור על גודל ההודעה המקסימלי
יש מגבלות על הגודל המקסימלי של הודעת RBM ועל קובץ המדיה שהיא יכולה להכיל. פרטים נוספים זמינים במאמר הגדרות גודל מקסימלי להודעות.
חשוב לוודא שהלוגו ותמונת ה-Hero מוצגים בצורה טובה
- משאירים מספיק מקום מסביב ללוגו כדי לאפשר חיתוך ולשמור על תקינות חזותית.
- אל תגרמו ללוגו או לתמונה הראשית להימתח או להשתנות, כי זה עלול להשפיע לרעה על תפיסת המותג.
- בודקים את הלוגו ואת תמונת ה-Hero גם במצב בהיר וגם במצב כהה כדי לוודא שהם נראים טוב וגלויים.
משאבים נוספים שיעזרו לכם לעצב את הלוגו או לפתור בעיות מפורטים בהנחיות לעיצוב סמלי לוגו.
לוגו
- כדאי לעצב את הלוגו מתוך מחשבה על חיתוך עגול, כדי לשמור על איזון ובהירות.
- כדאי למקם את הלוגו במרכז התמונה כדי למנוע בעיות שקשורות לחיתוך.
- בסמלי לוגו עם רקעים שקופים, חשוב לוודא שיש מספיק ניגודיות גם ברקעים בהירים וגם ברקעים כהים כדי להתאים למצב כהה. אם אתם לא בטוחים, השתמשו ברקע לבן אחיד.
תמונת גיבור
- מומלץ להשתמש ביחס גובה-רוחב של 45:14 כדי למנוע חיתוך לא רצוי ולהבטיח תצוגה אסתטית.
כשאתם מעצבים את תמונת ה-Hero, חשוב לקחת בחשבון את חפיפה הלוגו, כדי לוודא שהאלמנטים המרכזיים לא מוסתרים.
איך בודקים אם יש הודעות נכנסות כפולות
כשבודקים הודעות נכנסות ממשתמשים ומגיבים להן, צריך לבדוק את התיבה messageId ולוודא שלא קיבלתם את ההודעה כבר ועניתם לה.
במערכות מבוזרות יש שתי דרכים לשליחת הודעות:
- לכל היותר פעם אחת: המערכת שולחת הודעה פעם אחת, אבל אם יש שגיאות רשת או תקשורת בדרך, יכול להיות שההודעה לא תתקבל.
- לפחות פעם אחת: יכול להיות שהמערכת תשלח הודעה כמה פעמים, אבל ההודעה יכולה להתקבל גם אם יש שגיאות ברשת או בתקשורת.
ב-Google Cloud Pub/Sub נעשה שימוש במערכת לפחות פעם אחת. אמנם זה עלול לגרום לכך שתקבלו הודעות כפולות, אבל קל מאוד למנוע את הכפילות על ידי מעקב אחרי מחרוזות messageId. אם כבר קיבלתם הודעה, תוכלו להתעלם מהודעות נוספות שתקבלו עם אותו messageId.
מידע נוסף על קבלת הודעות זמין במאמר טיפול באירועים נכנסים.
הטמעת ניסיונות חוזרים עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff)
כשקוראים ל-API כלשהו, יכול להיות שהקריאה תיכשל בגלל בעיות בתשתית, עומס יתר על השירות, מגבלות על מספר הבקשות לשנייה ושגיאות אחרות. כדי להתאושש בצורה חלקה מקריאות API שנכשלו, מומלץ להטמיע ניסיונות חוזרים עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff).
כשמשתמשים בניסיונות חוזרים עם השהיה מעריכית לפני ניסיון חוזר, התשתית מבצעת באופן אוטומטי את הפעולות הבאות:
- מזהה קריאה ל-API שנכשלה.
- הגדרת משך ההמתנה הראשוני והמספר המקסימלי של ניסיונות חוזרים.
- הפונקציה משהה את הפעולה למשך זמן ההמתנה.
- ניסיון חוזר בקריאה ל-API.
הערכת התגובה לקריאה ל-API:
- אם הפעולה הושלמה, המערכת ממשיכה לשלב הבא בתהליך העבודה.
- אם הפעולה נכשלת, משך ההמתנה עולה וחוזרים לשלב 3.
- אם מתרחשת כשל אחרי מספר הניסיונות החוזרים המקסימלי, הבקשה עוברת למצב 'נכשל'.
משכי ההמתנה האידיאליים והמספר המקסימלי האידיאלי של ניסיונות חוזרים משתנים בהתאם לתרחיש לדוגמה. קובעים את המספרים האלה על סמך דרישות זמן האחזור של התשתית ותהליך העבודה.
אופטימיזציה של ביצועי ה-API באמצעות נקודות קצה אזוריות
כדי לבצע אופטימיזציה של ביצועי ה-API ולשפר את זמן האחזור:
להשתמש בנקודות הקצה הקרובות ביותר לאזור של המשתמש.
בטבלה הבאה מפורטות המלצות לגבי נקודות קצה אזוריות של RBM שאפשר להשתמש בהן, בהתאם למספר הטלפון של המשתמש.
הקידומת של מספר הטלפון נקודת קצה מומלצת אזור גיאוגרפי +1 us-rcsbusinessmessaging.googleapis.com אמריקה +2 europe-rcsbusinessmessaging.googleapis.com אירופה +3 europe-rcsbusinessmessaging.googleapis.com אירופה +4 europe-rcsbusinessmessaging.googleapis.com אירופה 5+ us-rcsbusinessmessaging.googleapis.com אמריקה +6 asia-rcsbusinessmessaging.googleapis.com אסיה +7 europe-rcsbusinessmessaging.googleapis.com אירופה +8 asia-rcsbusinessmessaging.googleapis.com אסיה +9 asia-rcsbusinessmessaging.googleapis.com אסיה ברירת מחדל us-rcsbusinessmessaging.googleapis.com אמריקה מומלץ למקם את השרתים ליד נקודת הקצה שנבחרה.
מידע על מרכזי הנתונים של Google זמין בכתובת https://www.google.com/about/datacenters/locations/.
מידע נוסף על זיהוי האזור של הסוכנות זמין במאמר יצירת סוכנות.
ממשק משתמש וחוויית משתמש של שיחה
ממשק משתמש בממשק שיחה, ולא ממשק משתמש של אפליקציה
סוכני RBM מתאימים במיוחד למשימות יעילות וספציפיות למשתמשים בממשק משתמש מבוסס-שיחה. הנציגים הכי טובים גורמים לאינטראקציות להיות ממוקדות, ברורות ומורכבות כמו שיחה טבעית.
סוכני תמיכה לא יכולים להסתמך על ממשק המשתמש החזותי של אפליקציה או דף אינטרנט, ואסור להם לנסות לחקות אותו. במקום זאת, הנציגים צריכים להסתמך על שיחות שנוצרו בקפידה כדי לענות על הצרכים של המשתמשים, באמצעות הנחיות, הצעות וטיפול טוב בשגיאות.
בנוסף, הנציגים לא צריכים לחקות עץ שיחות או ממשקים שמסתמכים על כך שהמשתמשים יגיבו במספר שמייצג פעולה מסוימת. המשתמשים צריכים להיות מסוגלים לתקשר עם הנציגים בצורה טבעית, כמו שהם מתקשרים עם אדם אחר בשיחה.
התחלת שיחה
תחילת השיחה קובעת את הציפיות של המשתמשים לגבי מה שהנציג יכול לעשות. כדאי להתחיל את השיחות בצורה חזקה: להציג את האישיות של הנציג, להציג מידע שחשוב למשתמשים כבר בהתחלה ולשתף את היכולות של הנציג. תנו למשתמשים אפשרויות ברורות לאינטראקציה עם הנציג ולהמשך השיחה.
הצגת האישיות של הנציג: מברכים את המשתמש ומציגים את המותג כדי להגדיר את האווירה. אם אתם יוצרים לסוכן אישיות, כמו עוזר וירטואלי או שירות דיגיטלי, חשוב לציין בבירור שמדובר בצ'אטבוט ולא באדם אמיתי. אפשר להגדיר את שם הנציג כך שיתאים לפרופיל. דמות היא דרך מצוינת לחזק את התדמית שלכם. זה יכול להיות הלוגו שלכם, אבל גם דמות גרפית בסגנון קריקטורה מתאימה.
שיתוף המידע על היכולות של הנציג: הודעת פתיחה טובה מאפשרת ללקוח להבין מה הוא יכול לקבל מהשיחה. הוא מסביר על היכולות של הסוכן ברמה גבוהה. הוא כולל גם הצעות לתשובות ופעולות שיעזרו למשתמשים לעבור בנתיב מסוים. אתם יכולים להשתמש בהצעות האלה כדי לעזור למשתמשים לנווט בשיחה ולהבין את המשימות שבהן הנציג יכול לעזור.
כותבים הודעות ברורות ועקביות
שלחו הודעות שקל למשתמשים להבין ולענות עליהן. יוצרים טקסט של הודעה שמעודד את המשתמשים להשיב. חשוב לשמור על סגנון, פורמט וקצב עקביים כדי ליצור אמון בקרב המשתמשים.
כשאתם יוצרים טקסט להודעה, כדאי לזכור את השיטות המומלצות הבאות:
לא ליצור קטעים ללא מוצא. כל הודעה צריכה להוביל לשלב הבא.
- אם בתהליך השימוש יש משימה עם כמה שלבים, כדאי להשתמש בסמנים לשיחה כדי להנחות את המשתמש בתהליך.
לדוגמה, עכשיו…, וגם…, הבנתי! הנה…
- חשוב לנסח את התשובות בקצרה, כי הצעות התשובות והפעולות יכולות להכיל עד 25 תווים.
- אם השיחה כוללת העברה, אישור מהיר יכול להקל על המעבר.
לדוגמה, "בסדר. מנהל החשבון שלך ימשיך מכאן".
לדוגמה, "נהדר! אני חושבת שאני יודעת מה אתם מחפשים", ואז לספק קישור לאתר שלכם.
מאשרים את ההודעה של המשתמש באמצעות מילה או ביטוי של אישור.
לדוגמה, "בחירה נהדרת!", "בסדר", "אוקיי" או "הבנתי".
פנו ישירות למשתמש באמצעות השם שלו (אם הוא ידוע לכם) או באמצעות לשון הפנייה 'את/ה'. עדיף לא להתייחס למשתמש כ'אני' או כ'לי', כי זה עלול לגרום לבלבול.
בכותרות ובתוויות, משתמשים באותיות רישיות רק בתחילת המילה, ולא בכל המילה.
לדוגמה, 'דף חשבון', ולא 'דף חשבון'.
השתמשו בקיצור מילים. זה מתאים גם לנציגים עם סגנון רציני או רשמי.
לדוגמה, "it's" (זה) נשמע יותר כמו שפה מדוברת מאשר "it is" (זהו).
מומלץ להשתמש בסימני קריאה במשורה.
משתמשים בפסיק סידורי, כלומר "A, B ו-C" ולא "A, B ו-C".
כתבו מספרים כספרות.
לדוגמה, '1, 2, 3' ולא 'אחד, שתיים, שלוש'.
כשמשתמשים באמוג'י, חשוב לוודא שהסגנון השובב מתאים לתרחיש לדוגמה.
לדוגמה, יכול להיות שמשתמשים שמזמינים גרר או מחפשים את תוצאות בדיקות הבריאות שלהם לא בעניין.
שמירת ההודעות בסדר
אם אתם שולחים כמה הודעות ברצף, חשוב שהמשתמשים יקבלו את ההודעות האלה בסדר. עיבוד הודעות עם מדיה נמשך זמן רב יותר מעיבוד הודעות טקסט בלבד. כדי לוודא שהמשתמשים יקבלו את ההודעות בסדר הנכון, צריך להמתין עד שמקבלים תשובה מסוג 200 OK להודעה מסוימת לפני ששולחים את ההודעה הבאה ברצף.
יצירת שיחות מעניינות בעזרת הצעות לתשובות ולפעולות
הצעות לתשובות ופעולות הן כלים יעילים שיעזרו לכם להנחות את המשתמשים בשיחות ולשפר אותן. הם יכולים להגיב להודעה או לכרטיס עשיר ולהציע אפשרויות להמשך השיחה או לשינוי הנושא שלה.
הצעות לתשובות: כדי לעזור למשתמשים להשיב במהירות לנציג, אפשר לספק להם אפשרויות מוגדרות מראש. מומלץ להשתמש בהצעות לתשובות כשהדבר אפשרי, במיוחד כשצפויות תשובות ספציפיות.
הצעות לפעולות: מאפשרות לנציג לשלוט בתכונות של המכשיר, וכך לפשט משימות כמו קריאה לתמיכה או חיפוש מיקומים.
כדי ליצור שיחות מעניינות ויעילות יותר, כדאי לפעול לפי השיקולים החשובים הבאים:
- רלוונטיות: חשוב לוודא שההצעות תואמות לשיחה הנוכחית.
- תמציתיות: כדאי להגביל את מספר ההצעות כדי לא להציף את המשתמשים.
- בהירות: כדאי להשתמש בשפה ברורה ותמציתית בטקסט של ההצעה.
עזרה למשתמש
הנציג צריך לענות להודעות HELP ממשתמשים ולהסביר להם על היכולות של הנציג. רשימה של הצעות לתשובות שמותאמות ליכולות של הנציגים יכולה לשפר את חוויית המשתמש.
לכבד את הרצון של משתמשים שלא לקבל הודעות
כדי לשמור על אמון המשתמשים, צריך לכבד את ההעדפות שלהם לגבי תקשורת. אם משתמש מציין שהוא רוצה להפסיק לקבל הודעות, הנציג שלכם חייב לכבד את הבחירה שלו. המשמעות היא שהם צריכים להבין את הביטויים השונים של ביטול ההסכמה ולהגיב בצורה מתאימה, כמו 'STOP', בכל השפות הרלוונטיות.
מומלץ לבדוק מה כתוב בחוקים המקומיים לגבי מענה להודעות מסוג "STOP" ולגבי פקודות אחרות, ולהיעזר בשיטות המומלצות למדינה שבה הנציג יופעל.
לדוגמה, אפשר לעיין בשיטות המומלצות של CTIA.
טיפול בבקשות לביטול הסכמה
פלטפורמת RBM לא מספקת דרך ישירה לניהול רשימות של משתמשים שביטלו את ההסכמה. אתם אחראים על ניהול מסד הנתונים שלכם של משתמשים שביקשו להפסיק לקבל הודעות.
המשך שיחות
אם משתמש מחק את השיחה עם הנציג שלכם, הוא יצטרך ליצור איתכם קשר מחדש דרך ערוץ אחר, כמו הסכמה באתר, קוד SMS קצר או מנגנון הסכמה אחר. האינטראקציה החדשה הזו מסמנת שהם מעוניינים שוב לקבל הודעות.