בחלק הזה
משרד רואי חשבון בפתח תקווה, ארבעה אנשים במשרד ולמעלה משישים תיקים פעילים. כל תחילת סבב דיווח נראית אותו דבר: מנהלת המשרד פותחת קובץ אקסל מהתקופה הקודמת, משכפלת אותו, צובעת שורות בירוק וצהוב ביד, ובמקביל רצה בין שלוש קבוצות וואטסאפ כדי לברר מי כבר שלח חומר. כשמישהו שואל בקול רם "מי עוד לא מסר?" — אף אחד לא יודע להשיב מהראש. זו בדיוק הנקודה שבה תוכנה לניהול משרד רואי חשבון מפסיקה להיות מותרות ומתחילה להיות תשתית: לא כי היא עושה משהו קסום, אלא כי היא מחזיקה את התשובה הזאת במקום קבוע אחד במקום בזיכרון של שלושה אנשים. (המספרים כאן הם דוגמה להמחשה בלבד.)
בקצרה
- לקוח = שורה. כל תיק הוא פריט אחד בלוח, לא קובץ ולא שיחה.
- סבב דיווח = קבוצה. סבב חדש נפתח כקבוצה חדשה, המבנה נשאר זהה.
- סטטוס אחד מדבר בשפת המשרד — התוויות נכתבות במילים שנאמרות בפועל בטלפון.
- Files ליד Date — מה שהלקוח מסר, ומתי נקלט בפועל.
- אוטומציה אחת ליום הראשון — פריט שנסגר עובר לקבוצת הסבב הסגור.
- תצוגת טבלה מקובצת + פילטר לפי מנהל התיק — כל אחד רואה את מה שהוא צריך.
לפני שבונים — מתי לוח מטריצה מתאים למשרד ומתי לא
המבנה שנתאר כאן הוא מה שנקרא בפשטות "מטריצה": ציר אחד של לקוחות, ציר שני של אותן עמודות שחוזרות בכל תקופה. הוא עובד מצוין כשמתקיימים שלושה תנאים. הראשון: אותה עבודה חוזרת על עצמה בתדירות קבועה על פני קבוצת לקוחות דומה — בדיוק מה שקורה בסבב דיווח תקופתי. השני: מה שמעניין אתכם באמת בכל רגע נתון הוא מצב הלקוח בסבב הנוכחי, לא רשימת כל המסמכים שקיבלתם ממנו אי פעם. השלישי: מספר העמודות שמתארות את הלקוח בסבב הוא קטן — סטטוס, מי אחראי, מתי נקלט, מה התקבל. חמש-שש עמודות, לא עשרים.
איפה זה לא מתאים? כשכל לקוח מייצר בפועל תהליך מרובה-שלבים שונה מהותית מהאחרים — למשל תיק שדורש ליווי מיוחד לאורך חודשים עם עשרות אבני-דרך משלו. שם השורה האחת נשברת, כי אתם מנסים לתאר מסע שלם בתא אחד. במקרה כזה עדיף לוח נפרד לאותם תיקים חריגים, ולהשאיר את לוח המטריצה למה שהוא באמת טוב בו: לראות שישים שורות במסך אחד ולזהות תוך שנייה מי חורג.
שלושת מרכיבי הלוח: שורה ללקוח, קבוצה לסבב, ועמודת Status
נתחיל מהיחידה הבסיסית. במאנדיי, שורה בלוח נקראת פריט (Item), והשורות מסודרות בתוך קבוצות (Groups) — פסי חלוקה לוגיים בתוך אותו לוח. הבחירה הקריטית במשרד רואי חשבון היא מה יושב בכל אחד מהם, והיא לא מובנת מאליה: אפשר היה לחשוב שכל משימה תהיה שורה. זו טעות נפוצה, והיא מייצרת לוח עם מאות שורות שאף אחד לא מסתכל עליו. הכלל כאן פשוט — שורה אחת לכל לקוח בסבב, וזהו.
הקבוצה, לעומת זאת, מייצגת את סבב הדיווח עצמו. "סבב ינואר-פברואר", "סבב מרץ-אפריל" — כל סבב הוא קבוצה משלו, עם אותה רשימת לקוחות ואותן עמודות. היתרון המעשי: כשנפתח סבב חדש אתם לא בונים לוח מאפס ולא משכפלים קובץ. אתם מוסיפים קבוצה, ומעתיקים לתוכה את השורות של הסבב הקודם — המבנה, שמות העמודות והצבעים נשארים בדיוק כפי שהיו. השנה הקודמת נשארת בלוח, מקופלת, זמינה לפתיחה כשמישהו שואל "מה היה איתו בפעם הקודמת".

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

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

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

איפה זה נשבר בפועל: לוח שמנסה להחזיק גם את הלקוח וגם כל מסמך
הכישלון החוזר במשרדי רואי חשבון הוא לא טכני, הוא מבני. מישהו מחליט שאם ממילא יש לוח, כדאי שיהיה בו גם מעקב אחרי כל מסמך בודד — חשבוניות ספקים, דפי בנק, אישורי ניכוי, טפסים. כך נולד לוח שבו שורה אחת מנסה לתאר בו-זמנית שני דברים ששייכים לרמות שונות: את מצב הלקוח בסבב, ואת מצב מסמך ספציפי. התוצאה היא לוח עם עשרים עמודות שאף אחד לא מסוגל לקרוא במסך אחד, וסטטוס שאי אפשר להשיב עליו — כי הלקוח "מסר חלקית" זה לא אותו דבר כמו "מסמך מספר שבע התקבל".
שורה בלוח עונה על שאלה אחת. ברגע שהיא מנסה לענות על שתיים, אף אחת מהן כבר לא מקבלת תשובה בהצצה.
הפתרון פשוט ולא דורש כלים נוספים: שומרים על השורה ברמת הלקוח, ומורידים את הפירוט למקום שנועד לו — תת-פריטים מתחת לשורת הלקוח, או פשוט הקבצים עצמם בעמודת Files. עמודת הסטטוס נשארת עונה על שאלה אחת בלבד: אצל מי הכדור. אם מתברר שהמשרד באמת חייב מעקב פרטני אחרי מסמכים, זה תפקיד של לוח נוסף שמקושר, ולא של עוד עמודות באותה שורה.
לפני שמשדרגים: שלוש שאלות שקובעות איזו תוכנית המשרד באמת צריך
מאנדיי נמכרת במספר מוצרים ובכמה תוכניות, והתמחור בנוי סביב מדרגות של מספר מושבים ולא לפי משתמש בודד. לא ניכנס כאן למדרגות ולמחירים — הם משתנים ומופיעים במלואם אצל הספק. מה שכן שווה לעשות לפני שמחליטים, זה לענות על שלוש שאלות שמשנות את התשובה יותר מכל השוואת-מחירים:
- כמה אנשים באמת נכנסים ללוח, ובאיזו תדירות? לא כמה עובדים יש במשרד — כמה מהם ייגעו בסטטוס. מתמחה שמסתכל פעם בשבוע ומנהל תיק שמעדכן כל יום אינם אותו שיקול.
- האם רואים את הלוח בעיניים או שרוצים גם דוח? אם מספיק לכם לסרוק את השורות — צורך אחד. אם השותף רוצה מסך שמסכם כמה תיקים פתוחים לכל מנהל, זה כבר צורך אחר, ויכולות מסוימות בפלטפורמה תלויות-תוכנית.
- האם צריך להכניס לקוח או גורם חיצוני לתוך הלוח? שיתוף החוצה, בכל צורה, הוא נקודת החלטה — גם מבחינת תוכנית וגם מבחינת מה שאתם מוכנים שגורם חיצוני יראה בתיקים של אחרים.
הדרך השפויה: להתחיל בסבב אחד אמיתי עם המבנה שתואר כאן, ולראות מה חסר בפועל אחרי שלושה שבועות. תוכנית נבחרת מתוך חוסר קיים, לא מתוך תרחיש עתידי. את פירוט התוכניות והמוצרים אפשר לקרוא בעמוד התוכניות והמחירים הרשמי — הוא המקור המעודכן, לא סקירות צד-שלישי.
מה עושים עם זה — שלושה צעדים לשבוע הקרוב
- נסחו את התוויות לפני שנוגעים בכלי כתבו על דף את המילים שנאמרות במשרד כשמדברים על מצב תיק. שש תוויות לכל היותר, וכל אחת עונה על השאלה "אצל מי הכדור". זה החלק הקשה, והוא לא טכני.
- בנו סבב אחד בלבד קבוצה אחת, השורות של הלקוחות הפעילים, ועמודות סטטוס, אנשים, תאריך קליטה ו-Files. אל תוסיפו עמודה חמישית "כי אולי נצטרך". סבב אחד מלא מלמד יותר מלוח מושלם ריק.
- הפעילו מתכון אחד וסגרו את האקסל את המתכון שמעביר פריט סגור לקבוצת הסבב הסגור — וזהו. במקביל, החליטו במפורש שהקובץ הישן לא מתעדכן יותר. שתי מערכות במקביל זו הדרך הבטוחה שאף אחת מהן לא תהיה נכונה.
העמוד הזה הוא חלק מסדרה שמדגימה איך אותם רכיבים בסיסיים מתלבשים על סוגי עסק שונים. לתמונה המלאה ולשאר הדוגמאות — מאנדיי לפי סוג עסק: 43 הדגמות לעסק ישראלי. סמוך לתחום, שווה גם מאנדיי למשרד עורכי דין, שמתמודד עם בעיה קרובה ומבנה שונה.
מקורות
- monday.com Support — Get started with monday automations
- monday.com Support — Available column types on monday.com
- monday.com Support — The board views
- monday.com Support — Plans and pricing for monday.com
- monday.com Support — Getting started with workspaces
נכון ל-28/08/2026.