בדף הזה מפורטות שיטות מומלצות ליצירת חוויות יעילות ומושכות ב-RCS Business Messaging. המאמר כולל מידע על הטמעה טכנית ועל עיצוב שיחות.
הנחיות טכניות
בדיקת היכולות של המכשיר
לפני שמתחילים שיחה עם משתמש, צריך לוודא שהמכשיר שלו יכול לקבל הודעות RCS. כדי לזהות את היכולות של המשתמש, שולחים בדיקת יכולות ומתאימים את האינטראקציות של הנציג בהתאם. האינטראקציה עם המשתמשים צריכה להתבצע רק בדרכים שהמכשירים שלהם תומכים בהן. אם המכשיר של המשתמש לא תומך ב-RCS, צריך להגדיר שיטת תקשורת חלופית בערוץ אחר, כמו SMS.
התייחסות לגודל המקסימלי של ההודעה
יש מגבלות על הגודל המקסימלי של הודעת RBM ושל קובץ המדיה שהיא יכולה להכיל. פרטים נוספים זמינים במאמר בנושא הגודל המקסימלי של הודעות.
בדיקה אם יש הודעות נכנסות כפולות
כשאתם בודקים הודעות נכנסות ממשתמשים ומשיבים להן, כדאי לבדוק את messageId ולוודא שלא קיבלתם את ההודעה כבר והשבתם לה.
במערכות מבוזרות, יש שתי דרכים לשליחת הודעות:
- לכל היותר פעם אחת: המערכת שולחת הודעה פעם אחת, אבל אם יש שגיאות ברשת או בתקשורת במהלך השליחה, יכול להיות שההודעה לא תתקבל.
- לפחות פעם אחת: המערכת עשויה לשלוח הודעה כמה פעמים, אבל אפשר לקבל את ההודעה גם אם יש שגיאות ברשת או בתקשורת.
Google Cloud Pub/Sub משתמש במערכת לפחות פעם אחת. למרות שזה יכול לגרום לכפילויות של הודעות נכנסות, אפשר לבטל את הכפילויות בקלות על ידי מעקב אחרי מחרוזות messageId. אם כבר קיבלתם הודעה, אפשר להתעלם בבטחה מכל הודעה נוספת שתקבלו עם אותו messageId.
שימוש במזהים ייחודיים לכל ההודעות היוצאות
כשנציג שולח הודעה למשתמש, הערך של messageId שכוללים בקריאת ה-API חייב להיות ייחודי לכל הודעה.
מידע נוסף על קבלת הודעות זמין במאמר בנושא טיפול באירועים נכנסים.
הטמעה של ניסיונות חוזרים עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff)
כשמתקשרים ל-API כלשהו, יכול להיות שהקריאה תיכשל בגלל בעיות בתשתית, עומס יתר בשירות, מגבלות QPS ושגיאות אחרות. כדי להתאושש בצורה חלקה מקריאות ל-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 מתאימים במיוחד לביצוע משימות יעילות וספציפיות עבור משתמשים בממשק משתמש שיש בו צ'אט. הנציגים הווירטואליים המתוכננים הכי טוב שומרים על מיקוד באינטראקציות, על בהירות ועל מבנה שדומה לשיחה טבעית.
סוכנים לא יכולים להסתמך על ממשק המשתמש החזותי של אפליקציה או דף אינטרנט, ואסור להם לנסות לחקות אותו. במקום זאת, נציגים צריכים להסתמך על שיחות מתוכננות בקפידה שנותנות מענה לצרכים של המשתמשים באמצעות הנחיות מילוליות, הצעות וטיפול טוב בשגיאות.
בנוסף, נציגים לא צריכים לחקות תפריטים קוליים או ממשקים שמסתמכים על משתמשים שמגיבים במספר שמייצג פעולה מסוימת. המשתמשים צריכים להיות מסוגלים לתקשר עם נציגים בצורה טבעית, כמו שהם מתקשרים עם אדם אחר בשיחה.
התחלת שיחה
תחילת השיחה קובעת את הציפיות של המשתמשים לגבי מה שהנציג יכול לעשות. חשוב להתחיל את השיחה בצורה טובה: להציג את האישיות של הנציג, להקדים מידע שחשוב למשתמשים ולשתף את היכולות של הנציג. צריך לתת למשתמשים אפשרויות ברורות לאינטראקציה עם הנציג ולהמשך השיחה.
הצגת האישיות של הנציג: כדי להגדיר את הטון, כדאי לפתוח את השיחה עם ברכה למשתמש והצגת המותג. אם אתם יוצרים פרסונה לסוכן, כמו עוזר וירטואלי או קונסיירז' דיגיטלי, חשוב לציין בבירור שמדובר בצ'אטבוט ולא באדם אמיתי. אתם יכולים להגדיר את שם הנציג כך שיתאים לאישיות. דמות היא דרך מצוינת לחזק את התדמית שלכם. זה יכול להיות הלוגו שלכם, אבל גם דמות גרפית בסגנון קריקטורה תתאים.
לספר מה הסוכן יכול לעשות: הודעת פתיחה טובה צריכה להבהיר מה אפשר לעשות בשיחה. ההסבר הזה מתאר את היכולות של נציג התמיכה ברמה גבוהה. הוא כולל גם הצעות לתשובות ופעולות כדי להנחות את המשתמשים בנתיבים ספציפיים. ההצעות האלה יעזרו למשתמשים להתמצא בשיחה ולהבין באילו משימות הסוכן יכול לעזור.
כתיבת הודעות ברורות ועקביות
שליחת הודעות שקל למשתמשים להבין ולהגיב להן. יוצרים טקסט של הודעה שמניע את המשתמשים להגיב. חשוב לשמור על סגנון, פורמט וקצב עקביים כדי ליצור אמון בקרב המשתמשים.
כשיוצרים את הטקסט של ההודעה, חשוב לזכור את השיטות המומלצות הנוספות הבאות:
אל תיצרו מצבים שאין מה לעשות בהם. כל הודעה צריכה להוביל לשלב הבא משמעותי.
- אם מסלול המשתמש כולל משימה עם כמה שלבים, כדאי להשתמש במילות קישור כדי להנחות את המשתמש בתהליך.
לדוגמה, Now…, And…, Got it! בבקשה…
- התשובות צריכות להיות תמציתיות כי התשובות המוצעות והפעולות יכולות להכיל עד 25 תווים.
- אם השיחה כוללת העברה למוקדן אחר, כדאי להגיב במהירות כדי שהמעבר יהיה חלק.
לדוגמה, "בסדר. מכאן, מנהל החשבון שלך יטפל בבקשה".
לדוגמה, "מצוין! אני חושב שאני יודע מה אתה מחפש" ולספק קישור לאתר שלכם.
להגיב להודעה של המשתמש במילה או בביטוי שמביעים הכרה.
לדוגמה, "בחירה מצוינת!", "אישור", "בסדר" או "הבנתי".
פנייה ישירה למשתמש באמצעות השם שלו (אם ידוע) או באמצעות כינוי הגוף 'אתה/את'. כדי למנוע בלבול, לא מומלץ להתייחס למשתמש כאל "אני" או "אותי".
בכותרות ובתגיות, משתמשים באות גדולה רק בתחילת השם, ולא בכל מילה.
לדוגמה, "Account statement" ולא "Account Statement".
להשתמש בצורות מקוצרות, שמתאימות גם לסוכנים עם סגנון רציני או רשמי.
לדוגמה, "it's" היא צורה יותר דיבורית מאשר "it is".
השתמשו בסימני קריאה במשורה.
משתמשים בפסיק לפני המילה האחרונה ברשימה, כלומר, "A, B, and C" ולא "A, B and C".
לכתוב מספרים כספרות.
לדוגמה, "1, 2, 3" ולא "one, two, three".
כשמשתמשים באמוג'י, חשוב לוודא שהסגנון השובב מתאים לתרחיש השימוש.
לדוגמה, משתמשים שמזמינים גרר או מחפשים את תוצאות בדיקות הבריאות שלהם לא בהכרח ירצו לראות מודעות.
שמירת ההודעות בסדר הנכון
אם אתם שולחים כמה הודעות ברצף, חשוב שהמשתמשים יקבלו את ההודעות האלה לפי הסדר. הזמן שלוקח לעבד הודעות עם מדיה ארוך יותר מהזמן שלוקח לעבד הודעות טקסט בלבד. כדי לוודא שהמשתמשים יקבלו את ההודעות בסדר הנכון, צריך להמתין עד שתקבלו תגובה 200 OK להודעה לפני ששולחים את ההודעה הבאה ברצף.
איך יוצרים שיחות מעניינות בעזרת הצעות לתשובות והצעות לפעולות
תשובות מהירות ופעולות הן כלים יעילים שיכולים לשפר את השיחות עם המשתמשים. הם יכולים להופיע אחרי הודעה או כרטיס עשיר ולהציע אפשרויות להמשך השיחה או לשינוי הנושא שלה.
הצעות לתשובות: אפשרות שמאפשרת למשתמשים להשיב במהירות לנציג באמצעות אפשרויות מוגדרות מראש. כדאי להשתמש בהצעות לתשובות כשזה אפשרי, במיוחד כשמצפים לתשובות ספציפיות.
הצעות לפעולות: מאפשרות לסוכן להשתלב עם תכונות המכשיר, ולייעל משימות כמו התקשרות לתמיכה או חיפוש מיקומים.
כדי ליצור שיחות יעילות ומושכות יותר, חשוב להקפיד על ההנחיות הבאות:
- רלוונטיות: חשוב לוודא שההצעות תואמות לשיחה הנוכחית.
- תמציתיות: הגבלת מספר ההצעות כדי לא להעמיס על המשתמשים.
- בהירות: חשוב להשתמש בשפה ברורה ותמציתית בטקסט של ההצעה.
עזרה למשתמש
הנציג צריך להגיב להודעות עם המילה HELP שמשתמשים שולחים, ולהסביר להם מה הנציג יכול לעשות. רשימה של תשובות מוכנות מראש שמותאמות ליכולות של הנציג יכולה לשפר חוויית משתמש גרועה.
חשוב לוודא שהלוגו ותמונת הגיבור מוצגים בצורה טובה
- חשוב להשאיר מספיק מקום מסביב ללוגו כדי לאפשר חיתוך ולשמור על שלמות ויזואלית.
- חשוב להימנע ממתיחה או מעיוות של הלוגו או התמונה הראשית, כי זה עלול לפגוע בתפיסת המותג.
- בודקים את הלוגו ואת תמונת הנושא במצב בהיר ובמצב כהה כדי לוודא שהם נראים טוב ושהם בולטים.
לקבלת משאבים נוספים שיעזרו לכם לעצב את הלוגו או לפתור בעיות, אפשר לעיין בהנחיות לעיצוב לוגו.
לוגו
- כדאי לעצב את הלוגו עם חיתוך עגול כדי לשמור על איזון ובהירות.
- כדי למנוע בעיות חיתוך, צריך למקם את הלוגו במרכז התמונה.
- אם הלוגו כולל רקע שקוף, צריך לוודא שיש ניגודיות מספקת בין הלוגו לבין רקעים בהירים וכהים, כדי שהלוגו יתאים למצב כהה. אם לא בטוחים, כדאי להשתמש ברקע לבן אחיד.
תמונה ראשית (Hero)
- כדי למנוע חיתוך לא רצוי, כדאי להשתמש ביחס גובה-רוחב של 45:14.
כשמעצבים את תמונת הגיבור, חשוב לקחת בחשבון את החפיפה עם הלוגו כדי שאלמנטים מרכזיים לא יוסתרו.
צריך לכבד את בקשות המשתמשים שלא לקבל הודעות
כדי לשמור על אמון המשתמשים, חשוב לכבד את ההעדפות שלהם לגבי יצירת קשר. אם משתמש מציין שהוא רוצה להפסיק לקבל הודעות, הנציג שלכם חייב לכבד את הבחירה שלו. היא כוללת הבנה של ביטויים שונים לביטול הסכמה, כמו "הפסקה", בכל השפות הרלוונטיות, והגבה בצורה מתאימה.
מומלץ לבדוק מה כתוב בחוקים המקומיים לגבי מענה להודעות מסוג "STOP" ולגבי פקודות אחרות, ולהיעזר בשיטות המומלצות למדינה שבה הנציג יופעל.
לדוגמה, אפשר לעיין בשיטות המומלצות של CTIA.
טיפול באירועים של ביטול הרשמה והרשמה
אפליקציית Google Messages כוללת תכונות מובנות של ביטול הרשמה והרשמה,
שמאפשרות למשתמשים לשלוט בשיחות שלהם. כשמשתמש בוחר לבטל את המינוי, הסוכן שלכם יקבל אירוע webhook UNSUBSCRIBE. אירוע SUBSCRIBE מציין כוונת משתמש לחדש את האינטראקציה עם הנציג.
מידע מפורט על טיפול באירועים מסוג ביטול הרשמה והרשמה מחדש, כולל פרטים על מטען ייעודי (payload), כללים עסקיים ודוגמאות, זמין במסמכי התיעוד בנושא אירועים שנוצרו על ידי משתמשים.
טיפול בביטולי הסכמה
פלטפורמת RBM לא מספקת דרך ישירה לנהל רשימות של משתמשים שהביעו התנגדות לקבלת הודעות. אתם אחראים לתחזוקה של מסד נתונים משלכם של משתמשים שבחרו להפסיק לקבל הודעות באמצעות ביטול הרשמה או דרכים אחרות לביטול הסכמה.
המשך השיחות
אם משתמש מוחק את השיחה שלו עם הסוכן, הוא צריך ליצור קשר מחדש דרך ערוץ אחר, כמו הצטרפות לרשימת תפוצה באתר, קוד קצר של SMS או מנגנון אחר לקבלת הסכמה. האינטראקציה החדשה הזו מסמלת את ההתעניינות המחודשת שלהם בקבלת הודעות.