סוכן AI לשירות לקוחות: תשובות מתוך נהלי העסק, בלי ניחושים

בוחרים שאלה שהצוות יודע לבדוק

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

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

לכל נוהל צריכים להיות מקור, תאריך ואחראי

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

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

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

מוצאים את הקטע הרלוונטי לפני שמנסחים תשובה

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

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

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

מקרים חריגים עוברים לאדם

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

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

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

בודקים גם מקרים שבהם אין תשובה

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

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

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

מודדים את עבודת הטיפול, לא את כמות התשובות

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

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

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