פיתוח סוכן AI לאוטומציה של תמיכה טכנית L1/L2

מדוע סוכן בינה מלאכותית לתמיכה טכנית טובע בפניות חד-גוניות

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

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

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

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

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

מה משתנה בעבודת התמיכה לאחר ההטמעה

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

שיעור הפניות שנסגרו ללא נציג

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

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

זמן תגובה ראשונה וזמן פתרון מלא

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

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

קו 24/7 ללא משמרות לילה

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

פניות חוזרות ופריקת עומס מהנציגים

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

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

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

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

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

מגבלות הגישה

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

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

כיצד עוברת ההטמעה: שלבי העבודה ההנדסית

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

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

הרכב האספקה: תרחישים, בסיס ידע, נהלים

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

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

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

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

מה נעשה

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

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

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

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

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

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

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

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

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

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

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

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

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

להלן תשובות קצרות לכל סעיף.

מה קורה כאשר פנייה אינה נפתרת?

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

כיצד הסוכן עובד עם נתונים פנימיים?

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

האם ניתן לאמן את הסוכן מחדש על דוגמאות משלכם?

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

כיצד נבדקת איכות התשובות?

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

נדון במשימה: ממה מתחילה העבודה

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

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

סדר שיתוף הפעולה נראה כך:

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

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

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