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

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

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

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

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

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

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

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

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

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

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

תבניות עבודה עם פניות אזרחים: השוואה

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

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

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

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

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

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

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

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

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

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

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

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

מערך תיעוד, תרשימים ותקנונים

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

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

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

ניתוח פרויקט: זמן המענה הצטמצם פי שלושה

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

מה שינו

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

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

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

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

שיעור הפניות שנסגרו ללא נציג — 12% → 61%. זמן המענה הראשון — 3 ימים → יום אחד. פניות חוזרות — 29% → 14%. שיעור המענים שהנציג בכל זאת תיקן נשאר בטווח של 8% ומשמש אות עיקרי לאימון נוסף: כל תיקון מנותח ומחליטים אם מדובר בתבנית חדשה או בשגיאת תיוג.

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

במה נבדל עוזר בינה מלאכותית ממשיב אוטומטי רגיל?

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

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

האמון במענה נשען על יכולת הבדיקה. הניסוח מורכב לפי סעיף בתקנון או לפי נורמה בבסיס המשפטי כגון КонсультантПлюс, וההפניה נשארת במענה — אותה רואה גם האזרח וגם הנציג. אם המקור לא נמצא, העוזר אינו משלים מדעתו, אלא מתעד את החסר בבסיס הידע.

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

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

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

מה לעשות עם פניות לא מובנות?

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

מי אחראי לטעות של המערכת?

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

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

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

כיצד מוגנים הנתונים האישיים?

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

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

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

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

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