התשובה הקצרה
Omni-Channel אינו מנגנון חלוקה אלא מודל קיבולת. הוא שואל שאלה אחת בכל רגע: כמה עבודה הנציג הזה יכול לשאת עכשיו. אם התשובה לשאלה הזו שגויה - כי צ'אט ומייל קיבלו אותו משקל - הניתוב יעבוד בדיוק כפי שהוגדר ויפגע בשירות.
לכן סדר העבודה הוא: קודם מודל קיבולת ומשקלים, אחר כך מיומנויות, אחר כך Entitlements ו-Milestones, ורק בסוף אוטומציות הסלמה.
מודל הקיבולת: הנקודה שקובעת הכל
Omni-Channel מקצה לכל נציג "מכסת עבודה" (Capacity) ולכל פריט עבודה משקל. מוקד שמגדיר משקל אחיד לכל הערוצים מקבל אחת משתי תוצאות: נציגים בצ'אט קורסים תחת עומס, או נציגים בטיפול מיילים נראים תפוסים בזמן שהם פנויים.
נקודת מוצא סבירה לכיול:
| סוג עבודה | מאפיין | משקל יחסי מומלץ |
|---|---|---|
| שיחת טלפון | סינכרוני מלא | תופס את כל הקיבולת |
| צ'אט חי | סינכרוני עם הפסקות קצרות | גבוה, בדרך כלל 2-3 במקביל לכל היותר |
| מייל / טופס | אסינכרוני | נמוך |
| Case ממתין ללקוח | לא פעיל | אפס - חייב לשחרר קיבולת |
השורה האחרונה היא הנפוצה בשגיאות: Case שממתין ללקוח שממשיך לתפוס קיבולת גורם לנציגים להיראות עמוסים בזמן שאין להם עבודה פעילה.
מיומנויות: פחות זה יותר
Skills-Based Routing נשמע כמו שיפור מובן מאליו, ובפועל הוא המקור השכיח לפניות שנתקעות. ככל שמוסיפים דרישות מיומנות, גדל הסיכוי שאין נציג פנוי שעונה על כולן.
שלושה כללים שמונעים את זה: להגדיר מיומנויות רק כשהיעדרן באמת מונע טיפול; להגדיר לכל דרישה רמת Fallback שמופעלת אחרי זמן המתנה מוגדר; ולבדוק חודשית כמה פניות הוקצו דרך Fallback - אחוז גבוה מעיד שהמודל אינו תואם את איוש המוקד.
Entitlements ו-Milestones: מהתחייבות למנגנון
SLA שמופיע רק בדוח הוא דיווח בדיעבד. Entitlements ו-Milestones הופכים אותו למנגנון פעיל:
- Entitlement מגדיר לאיזה לקוח מגיעה איזו רמת שירות - בדרך כלל ברירת מחדל אחת ומעט חריגים חוזיים.
- Milestone מגדיר את נקודות הזמן הנמדדות: תגובה ראשונה, עדכון תקופתי, פתרון.
- Business Hours קובעים מתי השעון רץ, וחייבים להיות מוגדרים לכל אזור זמן ולכל ערוץ בנפרד.
- Stopped Time מקפיא את המונה בהמתנה ללקוח - ללא זה המדדים מענישים את המוקד על התנהגות הלקוח.
- פעולות Milestone מייצרות התראה והסלמה לפני החריגה, בדרך כלל סביב 75-80% מהזמן.
הכלל המנחה: אם ההתראה הראשונה מגיעה אחרי החריגה, המנגנון מודד ולא מנהל.
הכרעות היסוד סביב הגדרת Case ושעון SLA מפורטות בהטמעת Service Cloud.
איך יודעים שהמודל לא מחזיק
חמישה סימנים מוקדמים, לפני שהמדדים החודשיים חושפים בעיה:
- אחוז גבוה של הקצאות דרך Fallback - המיומנויות אינן תואמות את האיוש.
- פניות בתור ההקצאה מעל דקות בודדות - חוסר קיבולת או כלל Overflow חסר.
- נציגים שמדווחים על עומס בזמן שדוח הקיבולת מראה זמינות - משקלים שגויים.
- ריכוז חריגות SLA בשעה קבועה ביום - בעיית איוש, לא בעיית ניתוב.
- שיעור גבוה של פניות שהוקצו וננטשו מיד - נציגים מסרבים לעבודה שאינה מתאימה להם.
מדידה שוטפת
| מדד | מה הוא מגלה |
|---|---|
| זמן בתור ההקצאה | האם המודל מוצא נציג בזמן |
| ניצולת קיבולת ממוצעת | האם המשקלים ריאליים |
| חריגות לפי Milestone | היכן בדיוק נשבר ה-SLA |
| שיעור הסלמות שנמנעו | האם ההתראה המוקדמת עובדת |
| פערי חריגה בין ערוצים | האם ערוץ מסוים מקופח בניתוב |
סדר יישום
מפעילים ערוץ אחד עם Entitlement יחיד וללא מיומנויות, מכיילים את המשקלים על נתוני אמת במשך שבועיים, ורק אז מוסיפים ערוץ שני ומיומנויות. הפעלה מלאה ביום אחד מונעת את היכולת לזהות איזה רכיב גרם לעומס, ובדרך כלל מסתיימת בכיבוי הניתוב וחזרה לתורים ידניים.
סיכום
Omni-Channel הוא מודל של קיבולת ולא של חלוקה, ו-SLA הוא מנגנון התראה ולא דוח. שני העקרונות האלה קובעים אם המוקד יעבוד לפי המערכת או ימצא דרכים לעקוף אותה - וההבדל מתגלה כבר בשבוע הראשון להפעלה.