מערכת AI לניתוב פניות למחלקות

ניתוב פניות ידני נשבר כאשר זרימת הפניות גדלה

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

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

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

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

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

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

סיווג, עדיפויות וזמני תגובה במערכת אחת

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

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

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

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

המערכת משתלבת בתשתית הקיימת: פניות מסונכרנות דרך ממשק תוכנה אל Zendesk, Jira Service Management או מסד נתונים פנימי, והסימון והעדיפות נכתבים לאותם שדות שהמפעילים כבר משתמשים בהם.

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

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

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

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

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

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

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

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

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

קונפיגורציה של המערכת, תרשימי זרימה ונהלים

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

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

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

מקרה בוחן: כיצד נפטרנו מפניות אבודות בתור התמיכה

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

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

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

מטריקות לפני ואחרי

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

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

מה לעשות אם הכללים מוגדרים אך אינם עובדים

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

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

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

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

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

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

ספקות טכניים לפני הפעלת המערכת

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

האם האדם יישאר במעגל ההחלטה?

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

מה לעשות עם קבצים מצורפים לא תקניים והודעות קוליות?

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

כיצד נשלטת איכות המודל לאחר ההפעלה?

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

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

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

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

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