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