יכולות מותאמות אישית של סוכן קולי מבוסס AI: בניית תהליכי עבודה נכנסים ייעודיים לארגון

לפי מחקר של Salesforce, 84% מהלקוחות אומרים שהחוויה שחברה מספקת חשובה כמו המוצרים שלה. בשיחות נכנסות, איכות החוויה נקבעת כמעט לחלוטין לפי השאלה האם הסוכן יכול לגשת לנתונים הנכונים ולהגיב עם מידע מדויק בהקשר - וזו בעיית התאמה אישית, לא בעיית מודל.

כך זה עובד בפועל:

• מספר הטלפון של המתקשר מותאם ל-CRM או למסד הנתונים של הלקוחות בתוך שתי השניות הראשונות של השיחה.
• הסוכן שולף פרטי חשבון, טיקטים פתוחים, בעלות על מוצרים, דרגת חוזה והיסטוריית אינטראקציות אחרונה.
• הסוכן משתמש בנתונים האלה כדי להתאים אישית את הברכה שלו ולמלא מראש את ההקשר השיחתי - בלי לבקש מהמתקשר לחזור על מידע שכבר סיפק בערוצים אחרים.
• אם כוונת המתקשר קשורה למוצר מסוים או למאפיין חשבון מסוים, הסוכן מבצע שאילתה למערכת הרלוונטית (ERP, פלטפורמת חיוב, מערכת מלאי) באמצע השיחה כדי לשלוף מידע מדויק ובזמן אמת.

גישה זו מבטלת את המקור הנפוץ ביותר לתסכול לקוחות בשיחות נכנסות: להתבקש לחזור על מידע שהחברה כבר מחזיקה. מחקר של Forrester מצביע על כך ש-73% מהלקוחות רואים בבקשה לחזור על מידע גורם משמעותי או מרכזי לחוסר שביעות רצון באינטראקציות שירות.

פלטפורמת UIRIX AI Inbound Calls תומכת באינטגרציית שליפת נתונים בזמן אמת באמצעות מחברי API ניתנים להגדרה, ומאפשרת לצוותי אנטרפרייז להגדיר אילו מקורות נתונים נשאלים, באיזה רצף, ואיזו התנהגות fallback תופעל כאשר שליפה נכשלת.

עבור מוקדי שירות ארגוניים, עדכוני CRM ידניים לאחר שיחה הם מקור משמעותי לעיכוב נתונים ולשגיאות. נתוני תעשייה מצביעים על כך שנציגים אנושיים משקיעים בממוצע 6 דקות בעבודה לאחר שיחה לכל אינטראקציה, ושברשומות CRM מתבצע עדכון מדויק רק בכ-70% מהמקרים בשל לחץ נפח ועייפות.

מה כתיבה חזרה ל-CRM לוכדת:

• סיווג כוונת השיחה (למה המתקשר התקשר, מסווג מול הטקסונומיה שלכם)
• חילוץ ישויות (מספרי חשבון, שמות מוצרים, סוגי בעיות, פעולות מבוקשות)
• תוצאת השיחה (נפתרה, הוסלמה, התבקשה שיחת חזרה, נקבעה פגישה)
• דגל סנטימנט (חיובי, ניטרלי, שלילי או כזה שמפעיל הסלמה)
• תמלול מלא של השיחה או סיכום מובנה
• טריגרים לפעולות המשך (יצירת טיקט, תזמון שיחת חזרה, סימון לצוות חידושים)

כל הנתונים האלה נכתבים לרשומת ה-CRM בצורה מובנית ברגע שהשיחה מסתיימת - או בחלק מעיצובי תהליך העבודה, מתעדכנים בהדרגה במהלך השיחה ככל שכל פיסת מידע נלכדת.

ניתוב סטטי (הקש 1 לחיוב, הקש 2 לתמיכה) מנתב על בסיס קלט המתקשר בלבד. ניתוב דינמי מנתב על בסיס שילוב של זהות המתקשר, כוונת השיחה, זמינות נציגים, דרגת המתקשר, שעה ביום וכללים עסקיים שהוגדרו על ידי הארגון.

דוגמאות ללוגיקת ניתוב דינמית:

• מתקשר מזוהה כחשבון בדרגת אנטרפרייז: ניתוב לתור מנהל הלקוח הייעודי
• כוונה שזוהתה: חידוש חוזה בתוך 30 ימים: ניתוב למומחה שימור, סימון בעדיפות גבוהה
• המתקשר מביע סנטימנט שלילי בפעם השנייה: הסלמה מיידית לנציג בכיר
• שיחה התקבלה מחוץ לשעות הפעילות: הצעת תזמון שיחת חזרה או חלופות שירות עצמי
• למתקשר יש טיקט פתוח שלא נפתר מ-48 השעות האחרונות: ניתוב לאותו צוות שיצר את הטיקט
• הכוונה תואמת לקו מוצר B: ניתוב לתור מומחי מוצר B, תוך עקיפת התור הכללי
• האימות נכשל לאחר שני ניסיונות: ניתוב למומחה לאימות זהות

כללי ניתוב דינמיים נכתבים כלוגיקה עסקית ניתנת להגדרה - לא כתוכנה מקודדת קשיח - מה שאומר שמנהלי מוקד שירות יכולים לעדכן את התנהגות הניתוב בלי לערב הנדסה.

זרימות שיחה מותאמות אישית לפי קו מוצר מאפשרות לסוכן הקולי מבוסס ה-AI:

• להפעיל פרסונה, טון ותחום ידע שונים על בסיס המוצר או השירות שלגביו המתקשר שואל
• להחיל טרמינולוגיה, מסלולי הסלמה ואפשרויות פתרון ייעודיים למוצר
• לגשת למסדי נתונים, תיעוד ולוגיקת תמחור ייעודיים למוצר
• לנתב לתורים אנושיים ייעודיים למוצר כאשר נדרשת הסלמה

עיצוב זרימות ברמת הארגון כולל בדרך כלל שכבת ניתוב ראשית שמזהה את קו המוצר הרלוונטי מתוך נתוני המתקשר או הכוונה הראשונית, ואז מעבירה לזרימה המתמחה המתאימה. ארכיטקטורה זו שומרת על זרימות בודדות ניתנות לניהול ולתחזוקה על ידי צוותי קווי המוצר, במקום לדרוש מצוות מרכזי יחיד לנהל את כל הזרימות.

ה-UIRIX AI Voice Agent Platform תומכת בארכיטקטורת זרימות מודולרית, שבה כל קו מוצר או יחידה עסקית יכולים לנהל את זרימת השיחה שלהם תוך שיתוף תשתית משותפת לטלפוניה, אינטגרציית CRM ואנליטיקה.

התאמה ללא קוד:

• משתמשים עיקריים: מנהלי מוקד שירות, מעצבי CX, בעלי מוצר
• שיטת קונפיגורציה: בוני זרימות ויזואליים, עורכים מבוססי טפסים, drag-and-drop
• מהירות פריסת שינויים: דקות עד שעות
• עומק התאמה אישית: גבוה ללוגיקת שיחה, בינוני לאינטגרציית נתונים
• הכי מתאים ל: עדכוני זרימות שיחה, שינויים בבסיס הידע, התאמות לכללי ניתוב

התאמה מבוססת API:

• משתמשים עיקריים: צוותי הנדסה, ארכיטקטי פתרונות
• שיטת קונפיגורציה: REST APIs, webhooks, SDKs, קוד מותאם אישית
• מהירות פריסת שינויים: שעות עד ימים
• עומק התאמה אישית: בלתי מוגבל
• הכי מתאים ל: אינטגרציות נתונים מותאמות אישית, לוגיקה עסקית מורכבת, זרימות אימות ייחודיות

רוב הפריסות הארגוניות משתמשות בשתי הגישות בשילוב, כפי שמפורט ב-מדריך ההטמעה הארגוני שלנו. צוותים עסקיים מחזיקים בזרימות השיחה ובכללי הניתוב דרך הממשק ללא קוד. צוותי הנדסה מחזיקים בשכבת האינטגרציה. העיקרון הארכיטקטוני החשוב ביותר הוא שקונפיגורציה ללא קוד לא צריכה לדרוש פריסת קוד כדי להיכנס לתוקף.

• שליפת נתונים: אילו מערכות ניתן לשאול? מהי ההשהיה? מה קורה במקרה של כשל בשליפה?
• כתיבה חזרה ל-CRM: אילו שדות ניתן לכתוב? האם זה בזמן אמת או לאחר שיחה? אילו מערכות CRM נתמכות באופן מובנה?
• ניתוב דינמי: כמה תנאי ניתוב ניתן לשלב? האם ניתן לערוך כללי ניתוב ללא קוד?
• ארכיטקטורת Multi-Flow: האם ניתן לתחזק זרימות נפרדות על ידי צוותים נפרדים? האם קיימת שכבת ניתוב ראשית?
• תמיכה רב-לשונית: כמה שפות? אותו עומק התאמה אישית בכל השפות?
• אינטגרציית אימות: אילו ספקי זהות נתמכים? אילו שיטות אימות זמינות?
• אנליטיקה ודיווח: האם ניתן לעקוב אחר אירועים מותאמים אישית? האם ניתן לייצא תמלולים? אילו דשבורדים זמינים?
• אבטחה וציות: אילו הסמכות מחזיקה הפלטפורמה? היכן הנתונים מעובדים ומאוחסנים?
• ממשק ללא קוד: מה משתמשים לא טכניים יכולים להגדיר באופן עצמאי? מה דורש הנדסה?
• גישה ל-API: האם יש API מלא לכל יכולות הפלטפורמה? אילו אירועי webhook זמינים?

הערכה שיטתית של הקטגוריות הללו מייצרת השוואה מובנית שניתן להשתמש בה לבניית כרטיס ניקוד לספקים ולהגדרת דרישות RFP. ראו את מדריך השוואת הפלטפורמות שלנו למסגרת הערכה מלאה.

כיצד מטפלים בכתיבה חזרה ל-CRM אם השיחה מתנתקת לפני הסיום?
עמידות ברמת הפלטפורמה צריכה לכלול תור עיבוד לאחר שיחה שמשלים את הכתיבה חזרה גם אם השיחה מסתיימת בפתאומיות. זו דרישה טכנית ספציפית שצריך לאשר מול כל ספק במהלך ההערכה.

עד כמה כללי ניתוב דינמיים יכולים להיות מפורטים?
לוגיקת הניתוב יכולה להיות מפורטת ככל שהנתונים הזמינים מאפשרים. פריסות ארגוניות משלבות באופן שגרתי ארבעה תנאים או יותר - זהות מתקשר, כוונה, סנטימנט, שעה ביום, זמינות נציג - להחלטת ניתוב אחת. המגבלה המעשית היא מורכבות הכללים העסקיים, לא הפלטפורמה.

האם יחידות עסקיות שונות יכולות לנהל את הזרימות שלהן באופן עצמאי?
כן, בפלטפורמות שתומכות בבקרת גישה מבוססת תפקידים ברמת הזרימה. זו יכולת ספציפית שצריך לאמת, משום שחלק מהפלטפורמות משתמשות בסביבת קונפיגורציה משותפת אחת שדורשת ניהול מרכזי.

מהו לוח הזמנים הטיפוסי לבניית זרימת שיחה מותאמת אישית עבור קו מוצר חדש?
עם בונה זרימות ללא קוד ושכבת אינטגרציה קיימת, מעצבי CX מנוסים יכולים לכתוב ולבדוק זרימה חדשה לקו מוצר בתוך שבועיים עד ארבעה. בניות ראשונות שדורשות אינטגרציות מערכת חדשות נמשכות בדרך כלל שישה עד עשרה שבועות.

כיצד הסוכן מטפל בשאלות שלא אומן עליהן?
לסוכן ארגוני מוגדר היטב יש התנהגות fallback מוגדרת: הוא מכיר בשאלה, מנסה לשלוף מידע רלוונטי מבסיס הידע, ואם אינו מסוגל לפתור - מסלים לתור האנושי המתאים עם סיכום מובנה של השיחה שמועבר לנציג המקבל.