אוטומציה של עיבוד פניות: ניתוב AI לתמיכה

ניתוב פניות AI: היכן נשבר המיון הידני

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

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

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

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

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

מה נותן המעבר לעיבוד פניות אוטומטי

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

שיעור ההקצאה האוטומטית הוא המדד הראשון שאנחנו מודדים לפני ואחרי. בהתחלה זה בדרך כלל 40–60%: אוטומטית מתפזר מה שנקרא באופן חד-משמעי לפי הנושא. לאחר אימון משלים על תיוג שנצבר המדד מגיע ל-75–85%, והוא נתקע לא במודל אלא באיכות הרובריקה — התורים שלפיהם הפניות באמת מתפזרות.

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

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

דרכי ניתוב: כללים, מודל, תוכנית היברידית

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

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

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

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

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

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

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

מה נשאר אצל המזמין: כללים, מודלים, נהלים

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

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

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

מקרה בוחן: חלוקת פניות ללא מיון ידני

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

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

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

מה שינינו

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

מדדים לפני ואחרי

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

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

במה שונה מיון לפי כללים ממודל מאומן?

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

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

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

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

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

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

ספקות טכניים לפני תחילת העבודה

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

אפשר לשנות כללים תוך כדי תנועה?

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

כמה נתונים היסטוריים צריך?

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

איך נבדקת איכות הניתוב?

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

איך מבטלים שינויים?

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

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

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

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

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

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

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