מאנדיי לחברת IT ותמיכה טכנית — קריאות, SLA ומלאי ציוד

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

11 דק׳ זמן קריאה · עודכן אוגוסט 2026

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

בקצרה

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

לפני שבונים לוח — מתי מאנדיי מתאים לחברת IT

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

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

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

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

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

חמש עמודות ולא יותר — איך נראה לוח הקריאות

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

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

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

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

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

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

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

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

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

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

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

אוטומציה אחת, לא חמש — הקריאה שלא זזה צפה

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

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

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

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

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

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

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

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

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

איפה זה נשבר — הקריאה שנסגרה בטלפון ולא נסגרה בלוח

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

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

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

איזו תוכנית צריכה חברת שירות — שלוש השאלות שמכריעות

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

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

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

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

מה זה אומר עליך — שלושה צעדים לשבוע הקרוב

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

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

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

מקורות

  1. monday.com Support — Available column types on monday.com — סוגי העמודות הזמינים בלוח, כולל סטטוס, אנשים, תאריך ונוסחה. נכון ל-28/08/2026.
  2. monday.com Support — Get started with monday automations — מבנה מתכוני האוטומציה, ניהולם וכיבוי מול מחיקה. נכון ל-28/08/2026.
  3. monday.com Support — The board views — תצוגות הלוח הזמינות והמעבר ביניהן. נכון ל-28/08/2026.
  4. monday.com Support — Plans and pricing for monday.com — המוצרים הנפרדים, מבנה המושבים ומחזורי החיוב. נכון ל-28/08/2026.
  5. monday.com — monday.com tutorial — היררכיית סביבת עבודה, לוח, קבוצה ופריט. נכון ל-28/08/2026.