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