פיתוח מערכת בינה מלאכותית לחיוג חזוי (מחייג חזוי)

מדוע חיוג ניבויי נשבר בעומס שיא

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

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

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

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

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

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

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

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

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

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

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

אפשרויות חיוג: ידני, אוטומטי, ניבויי

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

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

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

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

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

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

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

תוצרי הטמעה: תצורות, תרשימים, נהלים

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

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

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

מקרה בוחן: כיצד צומצם זמן האבטלה של נציגים במרכז קשר

מרכז קשר עם מאגר של כמה מאות אלפי אנשי קשר וצוות של כארבעים נציגים עבד ידנית: הנציג התפנה, חיכה לחיבור, שמע צלצולים ארוכים וסירובים קצרים. לפי לוגי המרכזייה, עומס הנציג בשיחה עמד על 30–35%, ושיעור השיחות שהופסקו לפני מענה המנוי הגיע ל-14%.

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

מה שונה בלוגיקת החיוג

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

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

עומס הנציגים בשיחה עלה מ-32% ל-76% — אותם אנשים מטפלים בפי שניים יותר אנשי קשר במשמרת. שיעור החיבורים המבוטלים ירד מ-14% ל-3%, וההמתנה של המנוי בתור הצטמצמה בחצי: שיחות הפסיקו להיתקע על קווים תפוסים.

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

מה לעשות אם חיוג אוטומטי כבר פרוס?

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

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

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

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

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

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

ספקות טכניים: השהיות, ביטולים, אינטגרציות

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

מה קורה עם שיחות מבוטלות?

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

כיצד מתבצעת האינטגרציה עם המאגר?

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

כיצד אנו בודקים את איכות המודל?

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

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

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

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

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

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