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

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

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

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

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

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

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

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

מה משתנה אחרי ההטמעה: מהירות ושלמות המיון

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

• [ ] שיעור הפניות שמוינו ללא אדם. המודל קורא את טקסט הפנייה, מחלץ ישויות וסוגר בעצמו תרחישים טיפוסיים — בנושאים המוניים זה 60–75% מהזרם הנכנס.
• [ ] הזמן עד הקצאת מבצע. הפנייה לא ממתינה יותר למיון ידני בתור: הזמן מתקצר מעשרות דקות לשניות, והתשובה הראשונה מגיעה באותה סשן.
• [ ] שיעור ההחזרות להבהרה. אם בטיקט אין מוצר, גרסה או צעדי שחזור, המבצע מחזיר אותו למחבר — היעד למדד הזה הוא אחוזים חד-משמעיים מכלל הפניות.
• [ ] סוג כשלי הניתוב שנעלם. הקצאות שגויות בין תורים (פנייה על תשלום נופלת לתמיכה טכנית) מפסיקות להיות בעיה מערכתית: התור נבחר לפי תוכן, לא לפי צורת הפנייה.
• [ ] עומס על התמיכה. השעות שהתפנו עוברות למקרים מורכבים, לא למיון מכני ולשכתוב שדות.
• [ ] שלמות הטיקט. מאפיינים חובה מתמלאים בכניסה מנתוני הפנייה, לא מהזיכרון של המחבר או הנציג.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

במה שונה סיווג אוטומטי מכללי ניתוב?

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

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

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

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

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

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

ואם הנושא נדיר וכמעט אין דוגמאות דומות?

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

איך נשמרת היסטוריית ההתכתבות והקבצים המצורפים?

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

האם האדם נשאר בשרשרת ואיך נשלטת איכות המיון?

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

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

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

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

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