בדף הזה מפורטות שיטות מומלצות ליצירת חוויות יעילות ומושכות ב-RCS Business Messaging, שכוללות גם הטמעה טכנית וגם עיצוב שיחות.
הנחיות טכניות
בדיקת היכולות של המכשיר
לפני שמתחילים שיחה עם משתמש, צריך לוודא שהמכשיר שלו יכול לקבל הודעות RCS. כדי לזהות את היכולות של המשתמש, שולחים בדיקת יכולות ומתאימים את האינטראקציות של הנציג בהתאם. האינטראקציה עם המשתמשים צריכה להתבצע רק בדרכים שהמכשירים שלהם תומכים בהן. אם המכשיר של המשתמש לא תומך ב-RCS, צריך להגדיר שיטת תקשורת חלופית בערוץ אחר, כמו SMS.
התייחסות לגודל המקסימלי של ההודעה
יש מגבלות על הגודל המקסימלי של הודעת RCS לעסקים ועל קובץ המדיה שהיא יכולה להכיל. פרטים נוספים זמינים במאמר בנושא גודל מקסימלי של הודעות.
איך מונעים שליחה של הודעות כפולות
כדי להימנע משליחת הודעות כפולות למשתמשים, המערכת צריכה קודם לוודא שההודעה לא נמסרה לפני שהיא מנסה לשלוח אותה באמצעות SMS.
כדי לשפר את האמינות של המערכת ולמנוע כפילויות בהודעות, מומלץ לפעול לפי השיטות המומלצות הבאות:
- הגדרת משך החיים של מאגר החיבורים כך שיתאים לזמן החיים (TTL) של DNS: שימוש במאגרי חיבורים ובמאגרי אובייקטים של לקוחות כדי לעשות שימוש חוזר בחיבורים קיימים ובאובייקטים של לקוחות. כדי להימנע משימוש בכתובות IP לא עדכניות אחרי עדכוני DNS, צריך להגדיר את הזמן המקסימלי שחיבור או אובייקט נשארים במאגר כך שיתאים לזמן החיים של ה-DNS של ה-API.
- אל תניחו שפסק זמן לחיבור מעיד על כשל: אל תניחו שפסק זמן לחיבור מעיד על כך שההודעה ב-RCS לעסקים לא נמסרה. יכול להיות שההודעה עדיין נמצאת בתהליך עיבוד בצד השרת.
- בדיקת אישורי מסירה: תמיד צריך לבדוק אם יש אישורי מסירה לפני שמפעילים הודעת גיבוי.
- התאמת ה-TTL לזמן הקצוב לתפוגה של החיבור: מומלץ להגדיר את ה-TTL של ההודעה כך שיתאים לזמן הקצוב לתפוגה של החיבור, בכל הזדמנות שמתאפשרת.
- ביטול ההודעות לפני החזרה ל-SMS: המערכת תמיד תנסה לבטל את ההודעה המקורית לפני שליחת ה-SMS. אם הביטול נכשל, צריך לטפל בכשל, כי יכול להיות שהוא מצביע על כך שההודעה כבר נמסרה למשתמש.
- ניסיון חוזר לשליחת הודעות: אם השליחה של הודעה נכשלת בגלל שגיאה שאפשר לנסות שוב או בגלל פסק זמן של חיבור, צריך לנסות שוב את פעולת השליחה. כדי למנוע כפילויות, צריך להשתמש בערך ההתחלתי
messageID, וכדי ליצור מרווחים בין הניסיונות, צריך להטמיע השהיה מעריכית לפני ניסיון חוזר.
בדיקה אם יש הודעות נכנסות כפולות
כשאתם בודקים הודעות נכנסות ממשתמשים ומשיבים להן, כדאי לבדוק את messageId ולוודא שלא קיבלתם את ההודעה כבר והשבתם לה.
במערכות מבוזרות, יש שתי דרכים לשליחת הודעות:
- לכל היותר פעם אחת: המערכת שולחת הודעה פעם אחת, אבל אם יש שגיאות ברשת או בתקשורת במהלך השליחה, יכול להיות שההודעה לא תתקבל.
- לפחות פעם אחת: המערכת עשויה לשלוח הודעה כמה פעמים, אבל אפשר לקבל את ההודעה גם אם יש שגיאות ברשת או בתקשורת.
Google Cloud Pub/Sub משתמש במערכת לפחות פעם אחת. למרות שזה יכול לגרום לכפילויות של הודעות נכנסות, אפשר לבטל את הכפילויות בקלות על ידי מעקב אחרי מחרוזות messageId. אם כבר קיבלתם הודעה, אפשר להתעלם מכל הודעה נוספת שתקבלו עם אותו messageId.
שימוש במזהים ייחודיים לכל ההודעות היוצאות
כשנציג שולח הודעה למשתמש, הערך של messageId שכוללים בקריאת ה-API חייב להיות ייחודי לכל הודעה.
מידע נוסף על קבלת הודעות זמין במאמר בנושא טיפול באירועים נכנסים.
לא להשתמש בכתובות IP לא עדכניות
המערכת שלכם צריכה תמיד להשתמש בכתובת ה-IP הנכונה והעדכנית כשהיא מתחברת ל-RBM API. פלטפורמות תכנות שונות משתמשות בערכי ברירת מחדל של פסק זמן (timeout) במטמון DNS, שיכולים להיות ארוכים משמעותית מההגדרה של TTL ב-DNS של Google. זה עלול לגרום למערכת לנסות להתחבר לכתובות IP שתוקפן פג, ולגרום לפסק זמן. ערך ה-TTL של מטמון ה-DNS בדומיין של RBM הוא 300 שניות.
כדי לוודא שהלוגיקה של החיבור מכבדת את ה-TTL של 300 שניות, פועלים לפי השלבים הבאים.
- התאמת הזמן הקצוב לתפוגה של מאגר החיבורים ל-TTL: אם אתם משתמשים במאגר של חיבורים או אובייקטים של לקוחות, הגדירו את משך החיים המקסימלי שלו ל-300 שניות (או פחות). הפעולה הזו גורמת למערכת לאחזר כתובת IP חדשה כשהאובייקט מתרענן.
- לוודא שמתבצע רענון של ה-DNS: צריך לוודא שהפלטפורמה או ספריית לקוח ה-HTTP מוגדרות לרענון של מטמון ה-DNS כל 300 שניות או פחות.
- בדיקת ה-TTL הנוכחי: מומלץ לבדוק באופן אוטומטי את ה-TTL של הדומיין ב-RBM API כדי לוודא שאתם משתמשים בערך המקסימלי הנכון. צריך לבדוק את הדומיין שמתאים לאזור הפריסה:
dig +nocmd +noall +answer +ttlid A us-rcsbusinessmessaging.googleapis.com | sort
dig +nocmd +noall +answer +ttlid A asia-rcsbusinessmessaging.googleapis.com | sort
dig +nocmd +noall +answer +ttlid A europe-rcsbusinessmessaging.googleapis.com | sort
הטמעה של ניסיונות חוזרים עם השהיה מעריכית לפני ניסיון חוזר (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/
מידע נוסף על זיהוי האזור של הסוכן זמין במאמר בנושא יצירת סוכן.
ממשק משתמש בממשק שיחה וחוויית משתמש
ממשק משתמש בממשק שיחה, לא ממשק משתמש של אפליקציה
נציגי שירות ב-RCS מתאימים במיוחד למתן מענה יעיל וממוקד למשתמשים בממשק משתמש שיחתי. הנציגים שמעוצבים בצורה הכי טובה שומרים על אינטראקציות ממוקדות, ברורות ומובנות, ומובנות כמו שיחה טבעית.
סוכנים לא יכולים להסתמך על ממשק המשתמש החזותי של אפליקציה או דף אינטרנט, ואסור להם לנסות לחקות אותו. במקום זאת, נציגים צריכים להסתמך על שיחות מתוכננות בקפידה שנותנות מענה לצרכים של המשתמשים באמצעות הנחיות מילוליות, הצעות וטיפול טוב בשגיאות.
בנוסף, נציגים לא צריכים לחקות תפריטים קוליים או ממשקים שמסתמכים על משתמשים שמגיבים במספר שמייצג פעולה מסוימת. המשתמשים צריכים להיות מסוגלים לתקשר עם נציגים בצורה טבעית, כמו שהם מתקשרים עם אדם אחר בשיחה.
התחלת שיחה
תחילת השיחה קובעת את הציפיות של המשתמשים לגבי מה שהנציג יכול לעשות. חשוב להתחיל את השיחה בצורה טובה: להציג את האישיות של הנציג, להקדים מידע שחשוב למשתמשים ולשתף את היכולות של הנציג. צריך לתת למשתמשים אפשרויות ברורות לאינטראקציה עם הנציג ולהמשך השיחה.
הצגת האישיות של הנציג: כדי להגדיר את הטון, כדאי לפתוח את השיחה עם ברכה למשתמש והצגת המותג. אם אתם יוצרים פרסונה לסוכן, כמו עוזר וירטואלי או קונסיירז' דיגיטלי, חשוב לציין בבירור שמדובר בצ'אטבוט ולא באדם אמיתי. אתם יכולים להגדיר את שם הנציג כך שיתאים לאישיות. דמות היא דרך מצוינת לחזק את התדמית שלכם. זה יכול להיות הלוגו שלכם, אבל גם דמות גרפית בסגנון קריקטורה תתאים.
לספר מה הסוכן יכול לעשות: הודעת פתיחה טובה צריכה להבהיר מה אפשר לעשות בשיחה. ההסבר הזה מתאר את היכולות של הסוכן ברמה גבוהה. הוא כולל גם הצעות לתשובות ופעולות כדי להנחות את המשתמשים בנתיבים ספציפיים. ההצעות האלה יעזרו למשתמשים להתמצא בשיחה ולהבין באילו משימות הסוכן יכול לעזור.
כתיבת הודעות ברורות ועקביות
שליחת הודעות שקל למשתמשים להבין ולהגיב להן. יוצרים טקסט של הודעה שמניע את המשתמשים להגיב. חשוב לשמור על סגנון, פורמט וקצב אחידים כדי ליצור אמון בקרב המשתמשים.
כשיוצרים את הטקסט של ההודעה, חשוב לזכור את השיטות המומלצות הנוספות הבאות:
אל תיצרו מצבים שאין מה לעשות בהם. כל הודעה צריכה להוביל לשלב הבא משמעותי.
- אם מסלול המשתמש כולל משימה עם כמה שלבים, כדאי להשתמש במילות קישור כדי להנחות את המשתמש בתהליך.
לדוגמה, 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 כוללת תכונות מובנות של ביטול הרשמה והרשמה,
שמאפשרות למשתמשים לשלוט בשיחות שלהם. כשמשתמש בוחר לבטל את המינוי, הסוכן שלכם יקבל אירוע UNSUBSCRIBE webhook. אירוע SUBSCRIBE מציין את הכוונה של המשתמש לחדש את האינטראקציה עם הנציג.
מידע מפורט על טיפול באירועים מסוג ביטול הרשמה והרשמה מחדש, כולל פרטים על מטען ייעודי (payload), כללים עסקיים ודוגמאות, זמין במסמכי התיעוד בנושא אירועים שנוצרו על ידי משתמשים.
טיפול בביטולי הסכמה
פלטפורמת RCS לעסקים לא מספקת דרך ישירה לניהול רשימות של משתמשים שהביעו התנגדות לקבלת הודעות. באחריותכם לתחזק מסד נתונים משלכם של משתמשים שבחרו להפסיק לקבל הודעות באמצעות ביטול הרשמה או דרכים אחרות לביטול הסכמה.
המשך השיחות
אם משתמש מוחק את השיחה שלו עם הסוכן, הוא צריך ליצור קשר מחדש דרך ערוץ אחר, כמו הצטרפות לרשימת תפוצה באתר, קוד קצר של SMS או מנגנון אחר לקבלת הסכמה. האינטראקציה החדשה הזו מסמלת את ההתעניינות המחודשת שלהם בקבלת הודעות.