כשאתם יוצרים אינטראקציה עם משתמשים באמצעות סוכני Business Messages, כדאי לזכור את השיטות המומלצות הבאות.
אין לספק או לבקש מידע רגיש
הימנעות משימוש בתוכן רגיש במהלך שיחות צ'אט תגן על המידע שלכם ושל הלקוחות. מידע רגיש כולל, בין היתר, את הפרטים הבאים:
- מספרים של כרטיסי אשראי
- מספר תעודת זהות, מספר דרכון או מספרי זיהוי רשמיים אחרים
- פרטי כניסה, כמו סיסמאות
מענה מהיר למשתמשים
זמני תגובה איטיים או לא סבירים להודעות של משתמשים יוצרים חוויית משתמש גרועה אצל הלקוחות. חשוב לתכנן את תשתית התשובות כך שתהיה מסוגלת לספק תשובות בזמן להודעות של המשתמשים.
גרוע יותר מתגובה איטית היא בכלל לא תגובה. חשוב לוודא שהמשתמשים תמיד מקבלים תשובות להודעות שלהם, ללא קשר לעומס ההודעות. לדוגמה, אם הצוות לא זמין, אפשר לשלוח הודעה אוטומטית עם אישור לקבלת הפנייה, ולציין בה הערכה לגבי מועד המענה המלא.
Google מודדת את זמן התגובה (TTR) בין הודעות. אם הנציג של המותג לא מגיב במהירות לצרכנים, Google תסיר את לחצני ההודעות של המותג.
העברה לטיפול אנושי במקרים שבהם האוטומציה לא יכולה למלא בקשות
משתמשים מתוסכלים כשהתגובה האוטומטית לא מתאימה להם. לכן, כל הנציגים שמתחילים את השיחה מנקודות כניסה בניהול Google (למעט נקודת הכניסה של Google Ads) חייבים לכלול נציגים אנושיים שיכולים לטפל בשיחות במקרים שבהם האוטומציה לא יכולה. לפני ההשקה, צריך להגדיר את סוג האינטראקציה עם הנציג כך שיכלול נציגים אנושיים.
אם האוטומציה לא מצליחה למלא בקשה של משתמש פעמיים ברציפות, מומלץ לשלוח הודעה עם הצעה לבקשת תמיכה בצ'אט בשידור חי.
כשמשתמש מקייש על ההצעה הזו, הנציג מקבל אירוע שנוצר בעקבות בקשה לנציג תמיכה. הנציג צריך להשיב על כך ולהעביר את השיחה לנציג אנושי כדי שהמשתמש יקבל את העזרה שהוא צריך.
בני אדם לא צריכים להיות זמינים מסביב לשעון. הגדרת הזמינות של הנציגים כדי שהמשתמשים ידעו מתי הם יכולים לצפות לתגובה אנושית.
אימות משתמשים באמצעות OAuth
כדי לאמת את זהויות המשתמשים ולספק להם מידע מותאם אישית, מבצעים אימות של המשתמשים באמצעות מערכות לקצה העורפי באמצעות OAuth. אימות באמצעות OAuth מאפשר לסוכנים לגשת במהירות לנתוני המשתמשים, ומונע ממשתמשים או מסוכנים לכלול במהלך השיחה מידע רגיש (כמו שמות משתמשים או סיסמאות). אימות באמצעות OAuth
מדידת שביעות הרצון של הלקוחות ב-Business Messages
ב-Business Messages אפשר למדוד את רמת שביעות הרצון של הלקוחות (CSAT) באמצעות סקרים ישירות בחוויית ההודעות. כדי למנוע ממשתמשים לקבל כמה סקרים, תוכלו להשתמש בפונקציית הסקרים של Business Messages. אל תטמיעו שיטות משלכם למדידת שביעות רצון הלקוחות.
להמשיך באותו נושא
אין לשלוח הודעות לא רצויות או לא רלוונטיות לשיחה הנוכחית. לדוגמה,
- הודעות לגבי מוצר או שירות שאינם קשורים לבקשה המקורית
- שליחת הודעות חוזרות ללא תגובה מהמשתמש
- שליחת הודעות ארוכות במיוחד או שימוש מוגזם בסמלי אמוג'י ובכתובות URL
שימוש במזהה מקום כשהאפשרות זמינה
בנקודות כניסה מבוססות-מיקום, הודעות עשויות לכלול את הערך placeId בחישוב העומס של ההקשר. אתם יכולים להשתמש בה כדי לספק מידע שהמשתמשים עשויים לשאול עליו, כמו מלאי שטחי פרסום במיקום מסוים. המזהה placeId הוא מזהה ייחודי של מקום במסד הנתונים של מקומות Google ובפלטפורמה של מפות Google.
גם אם אתם משיקים את הקמפיין רק עם נקודות כניסה שמבוססות על מיקום, חשוב להטמיע אסטרטגיה למקרים שבהם לא מופיע placeId. אמנם זה לא נפוץ, אבל יש נסיבות שבהן placeId, בין נתוני הקשר אחרים, לא מועבר ל-webhook.
הטמעת ניסיונות חוזרים עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff)
כשקוראים ל-API כלשהו, יכול להיות שהקריאה תיכשל בגלל בעיות בתשתית, עומס יתר על השירות, מגבלות על מספר הבקשות לשנייה ושגיאות אחרות. כדי להתאושש בצורה חלקה מקריאות ל-API שנכשלו, מומלץ להטמיע ניסיונות חוזרים עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff).
באמצעות ניסיונות חוזרים עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff), התשתית שלכם תנסה באופן אוטומטי
- זיהוי קריאה ל-API שנכשלה
- הגדרת משך ההמתנה הראשוני והמספר המקסימלי של ניסיונות חוזרים
- השהיה למשך זמן ההמתנה
- ניסיון חוזר בקריאה ל-API
הערכת התגובה לקריאה ל-API:
- אם הפעולה הושלמה, המערכת ממשיכה לשלב הבא בתהליך העבודה
- אם הפעולה נכשלת, משך ההמתנה עולה וחוזרים לשלב 3
- אם מתרחשת כשל אחרי מספר הניסיונות החוזרים המקסימלי, המערכת עוברת למצב כשל
משכי ההמתנה האידיאליים ומספר הניסיונות החוזרים האידיאליים משתנים בהתאם לתרחיש לדוגמה. צריך לקבוע את המספרים האלה על סמך דרישות זמן האחזור של התשתית ותהליכי העבודה.
איך בודקים אם יש הודעות נכנסות כפולות
כשבודקים הודעות נכנסות ממשתמשים ומשיבים להן, צריך לסמן את התיבה messageId ולוודא שלא קיבלתם את ההודעה הזו בעבר ועניתם לה.
במערכות מבוזרות יש שתי דרכים לשליחת הודעות: לכל היותר פעם אחת, ולפחות פעם אחת. במערכות 'לכל היותר פעם אחת', המערכת שולחת הודעה פעם אחת, אבל אם יש שגיאות ברשת או בתקשורת, יכול להיות שההודעה לא תתקבל. במערכות 'לפחות פעם אחת', המערכת עשויה לשלוח הודעה כמה פעמים, אבל ההודעה יכולה להתקבל גם אם יש שגיאות ברשת או בתקשורת.
ב-Business Messages נעשה שימוש במערכת 'לפחות פעם אחת'. אמנם זה עלול לגרום לכך שתקבלו הודעות כפולות, אבל קל מאוד למנוע את הכפילות על ידי מעקב אחרי מחרוזות messageId. אם כבר קיבלתם הודעה, תוכלו להתעלם מהודעות נוספות שתקבלו עם אותו messageId.