אוטומציה של סיווג פניות במוקד תמיכה באמצעות בינה מלאכותית

אוטומציה של סיווג פניות: היכן נשבר המיון הידני

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

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

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

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

מה נותן מיון אוטומטי של פניות בשירות התמיכה

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

מה משתנה בגדלים מדידים

המודל מאומן על היסטוריית פניות סגורות ופועל יחד עם כללים: תנאים קשיחים סוגרים מקרים חד-משמעיים (תבנית תקלה, לקוח בעל עדיפות), המסווג — את השאר. מתחת לסף הביטחון הפנייה עוברת לתור כללי עם סימון "לא זוהה", ולכן שיעור ההפניות השגויות יורד ולא עולה.

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

עמידות בשעת שיא ומשוב

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

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

גישות לסיווג פניות: כללים, מודל, היברידי

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

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

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

יישום צעד אחר צעד: מניתוח הזרימה ועד למסירה

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

1. ביקורת זרימת הפניות. מייצאים את היסטוריית הפניות, בוחנים את ההתפלגות לפי ערוצים, שיעור הכפילויות, פניות ללא טקסט, קבצים מצורפים והתראות אוטומטיות. סופרים איזה חלק מהזרימה בכלל ניתן לסמן. בתום השלב — מפת הזרימה ורשימת צווארי הבקבוק.
2. עיצוב קטגוריות. מתאמים את עץ הנושאים ואת כללי הניתוב עם בעלי התהליכים. יש בדיוק כמה קטגוריות שהשירות מוכן לשרת: פירוט יתר מייצר רעש ובלבול בקו הראשון.
3. הכנת מערך ייחוס. מסמנים פניות היסטוריות, בנפרד מתעדים מקרי גבול ואת הכלל עבורם. מערך זה משמש בהמשך כסרגל איכות, ולא כתרגיל חד-פעמי.
4. הגדרה ואימון. המודל נבנה לפי אוצר המילים והמינוח שלכם, מקרים שכיחים נסגרים בכללים. נקבע סף ביטחון: מתחתיו הפנייה עוברת לאדם, ולא לתור שגוי.
5. בדיקה בזרימה חיה. מריצים במצב צל — המערכת מסמנת, והניתוב עדיין נעשה בידי הנציג. משווים למערך הייחוס, סופרים שיעור שגיאות לפי כל קטגוריה ומתקנים את השנויות במחלוקת.
6. מסירה לתפעול. מוסרים תיאור קטגוריות, הנחיה לנציגים, סדר אימון מחדש על דוגמאות חדשות ותקנון לסקירת עץ הנושאים בעת שינוי תהליכים.

מערך האספקה: כללים, סכמות, תקנונים, סימון

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

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

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

מקרה בוחן: כיצד גדל שיעור ההחלטות האוטומטיות

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

מה שינו

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

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

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

מה נהיה

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

מה לעשות אם הפניות כבר מופצות לפי כללים ישנים

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

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

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

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

ספקות טכניים נפוצים ומגבלות

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

מה יקרה לפניות מקטגוריות חדשות?

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

כיצד מטופלות פניות לא טיפוסיות ומעורבות?

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

מי וכיצד בודק את איכות המיון?

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

נדון בזרימת הפניות שלכם ונחזור עם הערכה

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

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

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