בחלק הזה
סיטונאי מוצרי ניקיון באזור התעשייה בחולון, שלושה סוכנים ברכבים ולקוח עסקי ממוצע שמזמין פעמיים בחודש (מספרים לדוגמה, להמחשה בלבד). בשבע וחצי בערב הסוכן עוצר בצד הכביש ושולח הודעה קולית: "תשמע, מכולת של אבו־חמד בלוד רוצה שישה ארגזים של הנוזל הכחול, ותגיד לו שהמחיר כמו פעם שעברה". מישהו במשרד מאזין, מתרגם, כותב בגיליון. כל הזמנה עוברת פענוח ידני לפני שהיא בכלל הופכת לשורה. הדף הזה מראה איך מערכת לניהול הזמנות סיטונאי יכולה לשבת על לוח אחד במאנדיי — שמקבל את הבקשה כבר במבנה נכון, ומחזיק את מצב הטיפול בכל לקוח עסקי במקום אחד.
בקצרה
- לוח אחד — פריט לכל בקשת הזמנה שהגיעה מהשטח, לא לכל לקוח ולא לכל מוצר.
- טופס במקום הודעה — הסוכן פותח Form בנייד וממלא ארבעה שדות, והפריט נולד מלא.
- אוטומציה אחת — שיוך לפי אזור והתראה לאחראי, ותו לא.
- Mirror ולא העתקה — היסטוריית הלקוח נשארת בלוח הלקוחות ומוצגת מתוכו.
- גבול ברור — זה לא מחליף מערכת הזמנות או הנהלת חשבונות, אלא יושב לפניה.
לפני שבונים משהו — לאיזה סיטונאי הלוח הזה מתאים, ומתי לא.
הלוח הזה מתאים לעסק שבו ההזמנה נולדת בשיחה ולא במסך. סוכן יושב מול בעל מכולת, מסכם איתו כמות, ואז צריך להעביר את זה למשרד. זה נכון לסיטונאי מזון, לספק חומרי ניקיון, למפיץ מוצרי חשמל קטנים, לכל מי שיש לו בין שניים לעשרה אנשים שמסתובבים ומביאים הזמנות. השלב שנשבר אצלם הוא לא ההזמנה עצמה — הוא התרגום מהודעה לשורה, והוא נעשה פעם אחת בערב על ידי מי שגם עונה לטלפונים.
ומתי הוא לא מתאים: אם כבר יש לך מערכת הזמנות אמיתית — ERP קטן, מערכת של הספק, אתר B2B שהלקוחות מזמינים בו לבד — הלוח הזה לא בא במקומה ולא צריך לבוא. מאנדיי היא שכבת ניהול מעל תהליכים, לא מערכת מלאי ולא מערכת הנהלת חשבונות. היא לא מנפיקה חשבונית, היא לא יודעת כמה ארגזים נשארו במחסן, והיא לא מדווחת לאף אחד. אם כל ההזמנות שלך כבר נכנסות מסודר למערכת קיימת — אתה לא צריך את הדף הזה, ואם רק חלק מהן נכנסות (למשל, הזמנות טלפוניות מהשטח שאף אחד לא מקליד למערכת עד הבוקר) — הלוח הזה הוא בדיוק המסננת שלפני.
מבנה הלוח — פריט אחד לכל בקשת הזמנה
לוח במאנדיי מורכב מפריטים (items) — שורות — ומעמודות (columns) שנושאות את המידע על כל שורה. בלוח הזה, כל פריט הוא בקשת הזמנה אחת שהגיעה מהשטח, לא לקוח ולא מוצר. הבחירה הזאת נשמעת טכנית והיא לא: אם תעשה פריט ללקוח, כל הזמנה חדשה תדרוס את הקודמת, ולא תדע מה קרה בשלישי שעבר. פריט לבקשה נותן לך היסטוריה בחינם.
חמש עמודות מספיקות כדי שהלוח יעבוד, ואף אחת מהן לא דקורטיבית:
- Status — מצב הטיפול. ארבעה מצבים ולא יותר: התקבלה מהשטח · באישור מחיר · באריזה · יצאה. חמישה מצבים ומעלה זה כבר סטטוס שאף אחד לא מעדכן.
- Dropdown של אזור — צפון, שרון, מרכז, שפלה, דרום. זו העמודה שהאוטומציה תסתמך עליה, ולכן הערכים בה חייבים להיות קבועים ולא טקסט חופשי.
- People של הסוכן — מי מביא את ההזמנה ומי אחראי לסגור אותה. עמודת People היא גם מי שמקבל את ההתראות.
- Numbers של הכמות — כמות ביחידות או בארגזים. עמודת מספרים ניתנת לסיכום בתחתית הלוח, כך שאתה רואה כמה יחידות פתוחות עכשיו בכלל.
- Connect boards ללוח הלקוחות — עמודת החיבור שמצמידה את שורת ההזמנה ללקוח העסקי, שיושב בלוח נפרד.
התצוגה שבה אתה עובד ביום־יום היא Table — הטבלה הרגילה. לא כי היא הכי יפה, אלא כי בעסק סיטונאי אתה סורק שורות: מי הזמין, כמה, מאיזה אזור, מה הסטטוס. Kanban ולוח שנה יפים לתהליכים שבהם הזמן הוא הציר; כאן הציר הוא הכמות והלקוח, וטבלה נותנת לך את שניהם במבט אחד עם סכום בתחתית. יש למאנדיי עוד תצוגות לוח — הן קיימות, הן מוסברות במדריך הכלי, ואין סיבה לגעת בהן בשלב הזה.
הדלת מהשטח — טופס שהסוכן פותח מהנייד
כאן נמצא כל ההבדל. במקום שהסוכן ישלח הודעה, הוא פותח קישור אחד שמור אצלו במסך הבית, ורואה טופס עם ארבע שאלות בעברית: שם לקוח, אזור, פריט, כמות. הוא ממלא, שולח, וממשיך לנסוע. מהצד שלך נוצר פריט בלוח — עם אזור מלא, עם כמות בעמודת מספרים, בלי אף מילה שצריך לפענח. הודעה קולית של ארבעים שניות הופכת לשורה מובנית של ארבעה שדות.
שני דברים שקורים כאן וכדאי לשים לב אליהם. הראשון — הסוכן לא צריך גישה ללוח, לא צריך משתמש, ולא רואה את המחירים של לקוחות אחרים. הוא רואה טופס. השני — הטופס אוכף מבנה: אזור נבחר מרשימה סגורה, ולא "איפשהו ליד רמלה". דווקא האכיפה הזאת היא מה שמאפשר לאוטומציה בהמשך לעבוד בכלל.
בניית הטופס עצמה כבר מוסברת אצלנו, ואין טעם לחזור עליה: דלת לתוך הלוח למי שאין לו גישה: איך בונים טופס מידע — עמוד 27 במדריך מאנדיי המלא. שם תמצא איך פותחים את הטופס מהלוח, איך מגדירים שדות חובה ואיך משתפים את הקישור. כאן חשוב רק לדעת מה השדות צריכים להיות ולמה: ארבעה שדות, לא שמונה. ניסיון להוסיף הערות, אמצעי תשלום ותאריך אספקה מועדף מבטיח שסוכן שנוסע בכביש 6 יפסיק להשתמש בטופס וייחזור להודעה הקולית.
היסטוריית הלקוח — Mirror במקום להעתיק פעמיים
לכל סיטונאי יש שתי רשימות שונות בראש: רשימת ההזמנות, ורשימת הלקוחות. הפיתוי הוא לדחוס את שתיהן לגיליון אחד, ואז לגלות שכל שינוי בפרטי הלקוח דורש עדכון בשלושים שורות. במאנדיי הפתרון הוא שני לוחות שמדברים: לוח בקשות ההזמנה, ולוח לקוחות שבו כל פריט הוא לקוח עסקי אחד — עם תנאי תשלום, שם איש קשר, כתובת המחסן, וסטטוס אשראי.
עמודת Connect boards בשורת ההזמנה מצמידה את הבקשה ללקוח. עמודת Mirror לצידה שואבת מהלקוח המחובר נתון שרלוונטי לך ברגע ההזמנה — למשל תנאי התשלום או סטטוס האשראי — ומציגה אותו בשורת ההזמנה. הנתון לא הועתק; הוא מוצג מהמקור שלו. שינית תנאי תשלום בלוח הלקוחות, וכל שורות ההזמנה שמחוברות ללקוח הזה מציגות את הערך החדש. בלי סנכרון, בלי "מי עדכן איפה".
מה זה נותן בפועל בשעה שמונה בערב: אתה מסתכל בשורת ההזמנה של אבו־חמד ורואה בלי לצאת מהלוח שהוא שוטף+30 ושיש לו חוב פתוח. זה משנה את ההחלטה אם ההזמנה יוצאת מחר או ממתינה לשיחה. הצד השני — Mirror הוא לקריאה מהמקור. אם משהו נראה שגוי בשורת ההזמנה, המקום לתקן אותו הוא בלוח הלקוחות. מנגנון החיבור והמראה מפורט אצלנו בעמוד נפרד: לוח מדבר עם לוח: עמודת חיבור ועמודת מראה — עמוד 36 במדריך המלא.
האוטומציה היחידה שצריך — שיוך לפי אזור והתראה לאחראי
אוטומציה במאנדיי היא מתכון מוכן: מתי־שקורה־משהו — תעשה־משהו. יש עשרות מתכונים, וזה בדיוק הפח. עסק שמתחיל בשמונה אוטומציות מגיע תוך שבוע למצב שבו אף אחד לא יודע למה נשלחה ההודעה. בלוח הזה מפעילים מתכון אחד: פריט חדש שנוצר בלוח — שייך אותו למשתמש לפי הערך בעמודת האזור, ושלח לו התראה.
למה דווקא זה, ולמה זה מספיק. בעסק סיטונאי, הכתובת לטיפול בהזמנה נקבעת כמעט תמיד לפי גיאוגרפיה — מי אחראי על השפלה, מי על הצפון. ברגע שהאזור נבחר מרשימה סגורה בטופס, השיוך הוא מכני ואין בו שיקול דעת, וזה בדיוק סוג העבודה שכדאי להעביר למכונה. ההתראה הנלווית סוגרת את הפער הקלאסי: הזמנה שנכנסה ב־19:30 לא מחכה עד שמישהו יפתח את הלוח בבוקר. מרכז האוטומציות של מאנדיי מוסבר בתיעוד הרשמי, ומבנה המתכון עצמו כבר מכוסה במדריך הכלי — כאן ההחלטה היחידה שלך היא איזה מתכון, ולא איך בונים אותו.
איפה זה נשבר — כששני אנשים מעדכנים את אותה שורה
הכשל הכי נפוץ בלוח סיטונאי הוא לא טכני. סוכן בשטח מעדכן בטלפון שההזמנה אושרה, ובאותה דקה מישהי במשרד מסמנת "באריזה" כי המחסנאי אמר לה. שני העדכונים אמיתיים, אבל אחד דורס את השני, ובסוף אף אחד לא בטוח מה המצב. במאנדיי כל שינוי נרשם בהיסטוריית הפריט, אז אפשר לשחזר מי שינה מה — אבל שחזור אחרי מריבה זה לא ניהול.
שלושה כללים שפותרים את רוב הבעיה, ואף אחד מהם לא מצריך פיצ'ר:
- לכל סטטוס יש בעלים אחד. "באישור מחיר" מעודכן רק על ידי מי שמאשר מחירים. "באריזה" ו"יצאה" — רק על ידי המחסן. הסוכן לא נוגע בסטטוס אחרי השליחה.
- מה שיש עליו ויכוח — כותבים בעדכון, לא בעמודה. אזור העדכונים בכל פריט הוא שרשור. שם מנהלים את השיחה, ושם היא נשמרת. העמודות הן תוצאה, לא דיון.
- שינוי אחרי "יצאה" הוא פריט חדש. לקוח שהוסיף שני ארגזים אחרי שהמשאית יצאה — זו בקשה חדשה, לא עריכה של הישנה. אחרת המספרים בסוף החודש לא יסתדרו עם התעודות.
והמלכודת השנייה, שקטה יותר: הרחבת הלוח. בתוך חודש מישהו ירצה עמודת מחיר ליחידה, ואז עמודת רווח, ואז נוסחה. ברגע שהלוח מתחיל לחשב כסף, הוא מתחרה במערכת שכבר עושה את זה — ומפסיד, כי הוא לא רואה זיכויים, החזרות והנחות רטרו. שמור את הלוח על שאלת "מה מצב הבקשה", והשאר את שאלת "כמה זה" למערכת שמנפיקה מסמכים. אם מגיעה שאלה של מע"מ, תנאי חשבונית או דיווח — זה שולחן של רואה החשבון ושל אתר רשות המסים, לא של הלוח.
איזו תוכנית — שאלות ההחלטה לצוות מכירות בגודל הזה
כאן לא אתן לך מדרגות ולא מספרים, כי הם משתנים ומופיעים במקום אחד רשמי. מה שאני כן יכול לתת זה את שלוש השאלות שקובעות לאיזו תוכנית עסק סיטונאי בגודל הזה נופל — ואיתן אתה נכנס לעמוד התוכניות ומצליב בעצמך:
- כמה אנשים באמת צריכים משתמש? סוכן שממלא טופס בלבד לא צריך מושב. מי שצריך מושב הם מי שפותח את הלוח: אתה, מי שמאשר מחירים, המחסן. אצל סיטונאי טיפוסי זה שלושה עד חמישה, גם כשיש עשרה סוכנים בשטח.
- כמה עדכונים אוטומטיים אתה צפוי להריץ בחודש? מתכון אחד שרץ על כל הזמנה נכנסת מייצר שימוש ישיר במכסת הפעולות של החשבון. עשרים הזמנות ביום זו תמונה אחרת מארבע.
- אתה צריך לחפש רוחבית בכל הלוחות? חיפוש חוצה־לוחות (Search Everything) לא זמין בכל התוכניות. אם ה"מה קרה עם כהן מאשקלון" שלך חוזר כמה פעמים ביום — זו הפונקציה שתכריע.
שים לב לניואנס שרוב האנשים מפספסים: החיוב במאנדיי נעשה בחבילות של מושבים ולא לפי משתמש בודד. המשמעות המעשית — לפעמים תוספת עובד אחד לא עולה כלום, ולפעמים היא מקפיצה אותך חבילה שלמה. בדוק את המספר המדויק במסך התוכניות עצמו לפני שאתה מוסיף אנשים.
מאיפה מתחילים — שלושה צעדים לשבוע הקרוב
- יום ראשון — הגדר את האזורים שב עשר דקות וכתוב את רשימת האזורים הסגורה שלך, ומי אחראי על כל אחד. זו ההחלטה היחידה בעמוד הזה שאי אפשר לתקן בקלות אחר כך, כי האוטומציה נשענת עליה.
- יום שלישי — הרץ טופס אחד עם סוכן אחד אל תפרוס לכולם. בחר את הסוכן שהכי פחות אוהב טכנולוגיה, תן לו את הקישור, ותראה אם הוא ממלא אותו שלוש פעמים בלי שתזכיר. אם כן — הלוח יחזיק. אם לא — קצר את הטופס.
- סוף השבוע — חבר את לוח הלקוחות רק אחרי שההזמנות זורמות, בנה את לוח הלקוחות וחבר. הפוך מזה — קודם לקוחות ואז הזמנות — ותמצא את עצמך מנהל מאגר יפה שאף הזמנה לא נכנסת אליו.
אחרי השלושה האלה יש לך תמונה אמיתית: כמה בקשות נכנסות בשבוע, כמה מהן נתקעות בשלב אישור מחיר, ואיזה אזור מייצר הכי הרבה עבודה. זו לא מהפכה בעסק — זו החלפה של פענוח־ערב בשורה מובנית. מערכת לניהול הזמנות סיטונאי לא נבנית ביום, אבל היא בהחלט מתחילה בטופס אחד ובלוח אחד.
רוצה לראות איך אותו עיקרון עובד בסוגי עסק אחרים — יבואן שמנהל ספקים, בית דפוס עם אישורי גרפיקה, או חנות אונליין? חזור למדריך המרכזי: מאנדיי לפי סוג עסק — 43 הדגמות לעסק ישראלי. ולסוגי עסק קרובים במיוחד לשלך: יבואן ומפיץ · קריאות שירות בשטח · הצד התפעולי של חנות אונליין.
מקורות
- Introduction to monday.com — מרכז העזרה הרשמי · נכון ל-28/08/2026
- Available column types on monday.com · נכון ל-28/08/2026
- The board views — תצוגות לוח · נכון ל-28/08/2026
- Get started with monday Integrations · נכון ל-28/08/2026
- Plans and pricing for monday.com · נכון ל-28/08/2026
- Search Everything — חיפוש חוצה־לוחות · נכון ל-28/08/2026