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