# עומס על צוות שירות: איך מודדים אותו מעבר למספר הקריאות?

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

- כתובת העמוד: https://crmers.co.il/crm-service-team-capacity/
- פורסם: 2026-10-04
- מאת: צוות Crmers
- חלק מהמדריך: [מכירות ושירות ב-CRM: תהליך אחד בלי נתק](https://crmers.co.il/sales-service-guide/)

במשמרת של שמונה שעות, ניצולת של 90% משאירה לנציג 48 דקות שבהן הוא לא מטפל בפנייה. את החשבון הזה עשה אחד המומחים שרואיינו באתר Call Centre Helper, כשנשאלו מה רף הניצולת הנכון למוקד. רוב המומחים שם ראו ב-90% ניצולת גבוהה מדי.

בצוות שירות שעובד מתוך CRM, הדשבורד סופר קריאות. כדי למדוד עומס על צוות שירות מעבר למספר הקריאות, מתרגמים אותן לשעות. נניח שישה נציגים ו-270 שעות משמרת בשבוע. אחרי 30% של הדרכות, ישיבות, חופשות והפסקות נשארות 189 שעות לקריאות. אם הקריאות של השבוע דורשות 170 שעות טיפול, הצוות עובד בניצולת של 90%, בדיוק המצב של 48 הדקות.

## למה מספר הקריאות לא מראה עומס על צוות שירות?

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

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

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

## הנוסחה של עומס על צוות שירות: ביקוש מול קיבולת נטו

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

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

לפי החברה, פחת השעות במוקדים נע בדרך כלל בין 10% ל-40% מהשעות המשובצות, הממוצע הוא 30% עד 35%, ורוב הארגונים מעריכים אותו בחסר. החישוב שהיא מציעה פשוט: מחלקים את מספר הנציגים שנדרש באחד פחות שיעור פחת השעות. מי שצריך 160 נציגים וצופה פחת שעות של 20% צריך לשבץ 200.

### טיימר, דרגות מאמץ או ספירת פעולות: מה עדיף?

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

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

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

רישום זמן מדויק נחוץ כשמחייבים לקוחות לפי שעות, למשל בבנק שעות תמיכה, או כשכל קריאה היא עבודה ארוכה שלא דומה לקודמת. גם אז דיווח בסוף היום אמין יותר מטיימר. כך עובדים [בבר מרין סרביס](https://crmers.co.il/case-studies/br-marine/), חברה לבנייה ימית ויבשתית: העובדים ממלאים טופס דיווח יומי דיגיטלי עם השעות שעבדו, הסטטוס של כל משימה והבעיה שצצה באותו יום, והמנהל רואה בסוף היום מה בוצע.

## רף ניצולת לצוות שירות: כמה מהקיבולת אפשר למלא?

ניצולת (occupancy) היא החלק מהזמן הזמין שבו נציג באמת מטפל בפניות. באותו אתר לניהול מוקדים שאלו כמה מומחים מה הרף הנכון, ולא הייתה ביניהם הסכמה. ההמלצות נעו בין 75% ל-80% כדי להימנע משחיקה, ועד 85% כגבול עליון. אחד מהם נקב ב-84% וקרא לו "מספר הקסם". ניצולת של 90% ומעלה נחשבה גבוהה מדי.

גודל הצוות משנה את המספר. לפי מומחה אחר באותה כתבה, מוקדים של 100 עד 150 נציגים עובדים הכי טוב סביב 80%, ובמוקדים של פחות מ-100 נציגים הרף הוא 70% עד 75%.

מומחה נוסף שם הזכיר שניצולת היא תוצאה של החלטות האיוש, ולא יעד שקובעים מלמעלה. באותו מדריך לתכנון כוח אדם יש חישוב מלא שמראה את זה: מאה שיחות בחצי שעה, שלוש דקות לשיחה, ויעד של מענה ל-80% מהשיחות תוך 20 שניות. כדי לעמוד ביעד צריך 13 נציגים על הקו, והניצולת שלהם יוצאת 77%. אחרי פחת שעות של 30% צריך לשבץ 19. את ה-77% אף אחד לא קבע, הם יצאו מיעד השירות.

## מדידת עומס על צוות שירות במאנדיי

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

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

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

## מדידת עומס על צוות שירות בזוהו CRM

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

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

את הביקוש של כל נציג רואים בדוח מסכם לפי בעל הרשומה ודרגת המאמץ, עם סכום של שדה השעות. בדוח הזה קריאה שעברה בין נציגים נזקפת כולה לבעל הרשומה האחרון. על השוואה בין נציגים כתבנו בנפרד, במאמר על [מדידת תהליכים בלי מעקב אחרי עובדים](https://crmers.co.il/crm-adoption-measure-private/). את הטופס לפניות שלא נרשמו בונים בזוהו כמודול מותאם שהנציגים ממלאים מהאפליקציה בנייד, והשדה "נוצר על ידי" כבר מזהה את הנציג.

## חישוב עומס על צוות שירות: דוגמה מחברה להשכרת מכונות קפה

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

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

בדוגמה שלנו, אחרי שבועיים של מדגם שבהם נספר רק הזמן בסטטוס "בטיפול" לפי [ההגדרה של קריאה פתוחה](https://crmers.co.il/accurate-open-status/), רואים לאן הולכות השעות. "מכונה לא מוציאה מים" היא הקריאה הכבדה ביותר, כי ברוב המקרים צריך לתאם טכנאי ולחזור ללקוח פעמיים. "הזמנת קפסולות" קלה, אבל רוב ההזמנות נכנסות ביום ראשון. בטופס העבודה הנסתרת מופיעים בירורי חיובים שמחלקת הגבייה מעבירה לצוות בוואטסאפ, ולקוח גדול אחד שמתקשר ישר לנייד של הנציג הוותיק. והקריאות שאחרי ביקור טכנאי נפתחות מחדש יותר מכל סוג אחר: הטכנאי סוגר את הקריאה כשהוא עוד אצל הלקוח, ולמחרת הלקוח מגלה שהמכונה עדיין לא עובדת.

הזמנות הקפסולות עוברות לטופס הזמנה שמנותב ישר למחלקת הלוגיסטיקה, והצוות כבר לא מטפל בהן. לבירורי החיובים מגדירים סוג קריאה [וערוץ קליטה קבוע](https://crmers.co.il/whatsapp-crm-operational-flow/) מול הגבייה, ומעכשיו הם נספרים בביקוש. אחרי ביקור טכנאי הקריאה עוברת לסטטוס "ממתין לאישור לקוח", ולמחרת נקבעת לנציג שיחת בדיקה יזומה, בדומה [למשימות בדיקה לפני שהלקוח פותח קריאה](https://crmers.co.il/service-before-support-ticket/).

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

## עוד מהבלוג

- [CRM לשירות בשטח: איך מנהלים טכנאים, קריאות ומלאי ברכב?](https://crmers.co.il/crm-field-service-technicians/)
- [כשאותו לקוח מדבר עם מכירות, כספים ושירות: איך מונעים שלוש גרסאות של אותה אמת?](https://crmers.co.il/single-customer-truth/)
- [לפני שמוסיפים עוד שדה ל-CRM: שלוש שאלות שמונעות עומס על הצוות](https://crmers.co.il/crm-questions-prevent-overload/)

---

Crmers: אפיון והטמעה של מערכות CRM ומערכות מידע · [072-372-7806](tel:+972723727806) · [office@crmers.co.il](mailto:office@crmers.co.il) · [יצירת קשר](https://crmers.co.il/contact/) · [הנחיות לסוכני AI](https://crmers.co.il/agents.md)