בחלק הזה
סוכנות ביטוח קטנה בפתח תקווה, שלושה אנשים ותיק לקוחות של כמה מאות פוליסות, מנהלת את החידושים בקובץ אקסל אחד ובקבוצת וואטסאפ. הכול עובד — עד היום שבו לקוח מתקשר ושואל למה הפוליסה שלו התחדשה בתנאים אחרים, ואתה מגלה תוך כדי השיחה שהתאריך עבר לפני שבועיים. זו לא בעיה של זיכרון. זו בעיה של מבנה: באקסל התאריך הוא טקסט בתא, ובוואטסאפ הוא לא קיים בכלל. מערכת לניהול סוכנות ביטוח מתחילה בשורה אחת שהתאריך שלה חי — כלומר יודע להזכיר לך לפניו.
מתי לוח שמנוהל בתאריך מתאים לסוכנות — ומתי הוא בכלל לא הכלי הנכון
לוח שהתאריך מנהל אותו הוא לוח שבו העמודה החשובה ביותר בכל שורה היא תאריך עתידי, וכל השאר — סטטוס, שם הלקוח, סוג הכיסוי — הם הקשר סביבו. זה מבנה נכון כשהעבודה שלך היא רצף של אירועים שקורים בזמן ידוע מראש, וטעות היא איחור. חידוש פוליסה הוא בדיוק זה.
ההבחנה הזאת חשובה כי היא קובעת מה נכנס ללוח. סוכן שמכניס לשם הכול — כולל "לחזור לדוד ממחלקת רכב" — מקבל אחרי חודש לוח שמכיל בעיקר רעש, ומפסיק להסתכל עליו. לוח שהתאריך מנהל אותו עובד רק כשכל שורה בו באמת נושאת תאריך.
הלוח עצמו — לקוח בשורה, כיסוי ב-Dropdown, חידוש בעמודת Date
המבנה פשוט להחריד, וזה יתרון. במאנדיי, שורה בלוח נקראת פריט (Item), והעמודות הן סוגי המידע שהיא נושאת. הסוכנות שלנו מגדירה שלוש עמודות בלבד, מעבר לשם הפריט, ולא יותר, בשבוע הראשון.
- שם הלקוח — הוא שם הפריט עצמו, לא עמודה נפרדת. שורה אחת ללקוח־פוליסה, לא ללקוח. ללקוח עם רכב ודירה יש שתי שורות, כי יש שני תאריכי חידוש.
- סוג הכיסוי — עמודת Dropdown עם רשימת ערכים סגורה בעברית: רכב חובה, רכב מקיף, דירה, בריאות, עסק. סגורה, כדי שאפשר יהיה לסנן. תא טקסט חופשי לא ניתן לסינון אמין, כי אחד כותב "דירה" והשני "ביטוח דירה".
- תאריך החידוש — עמודת Date. זו העמודה שכל העמוד הזה נשען עליה. היא לא קישוט; היא מה שמזין גם את התצוגה וגם את התזכורת.
- סטטוס הטיפול — עמודת Status בשלושה מצבים צבועים בלבד: ממתין, בטיפול, טופל. אל תוסיף מצב רביעי בשבוע הראשון.
למה Dropdown ולא טקסט? כי סוג הכיסוי הוא מה שאתה מסנן לפיו כשהלקוח מתקשר וכשאתה בונה סבב חידושים לרבעון. סינון עובד על ערכים, לא על ניסוחים. הרשימה הסגורה היא ההבדל בין "תראה לי את כל חידושי הרכב ברבעון הבא" שעובד בלחיצה, לבין חיפוש טקסט שמחזיר שמונים אחוז מהשורות.
שתי קבוצות בלוח — מה שממתין לחידוש נפרד ממה שנמצא בטיפול תביעה
בתוך לוח במאנדיי יש קבוצות (Groups) — פסי חלוקה שמפרידים שורות לפי היגיון עסקי. בסוכנות, ההפרדה הנכונה היא לא לפי חברת ביטוח ולא לפי סוג לקוח, אלא לפי סוג האירוע: מה שמתחדש מול מה שנמצא בטיפול תביעה.
- קבוצה א׳ — חידושים. כאן חיות שורות שהתאריך שלהן הוא תאריך עתידי קבוע, והפעולה שלך היא לפני התאריך.
- קבוצה ב׳ — תביעות בטיפול. כאן התאריך מסמן מועד מעקב, לא מועד חידוש, והפעולה שלך היא אחרי אירוע שכבר קרה.
הסיבה להפרדה היא פסיכולוגית לא פחות מטכנית. אלה שני מצבי-ראש שונים: חידוש הוא עבודה יזומה שאתה שולט בקצב שלה, ותביעה היא עבודה תגובתית שהלקוח שולט בקצב שלה. כשהן מעורבבות באותה רשימה, התביעות — שהן רועשות יותר, כי הלקוח מתקשר — דוחקות את החידושים למטה. וחידוש שנדחק למטה הוא בדיוק החידוש שתגלה עליו בשיחת טלפון.
האוטומציה האחת של היום הראשון — שהלוח יפתח לך את הפריט מראש
מאנדיי בונה אוטומציות ממתכונים (Recipes) — כללי "כשקורה X, עשה Y" שנבחרים מתוך רשימה, בלי קוד. יש מאות מתכונים. אתה צריך אחד.
המתכון הרלוונטי לסוכנות הוא זה שמבוסס על עמודת Date ומופעל מספר ימים לפני התאריך — לא ביום שלו ולא אחריו. הוא לוקח את התאריך שכבר יושב בשורה, סופר אחורה את מספר הימים שאתה קובע, ובמועד הזה מקפיץ לך את הפריט: התראה, שינוי סטטוס, או הקצאה לאיש בצוות. פרטי הבנייה עצמה מתועדים במרכז האוטומציות של מאנדיי, ואין טעם לחזור עליהם כאן.
למה דווקא המתכון הזה, ולמה רק הוא? כי הוא היחיד שמשנה את הכיוון של המידע. כל עוד אין אוטומציה, אתה הולך אל הלוח כדי לבדוק מה קורה — וזה תלוי בכך שתיזכר לבדוק. עם המתכון הזה, הלוח בא אליך. זה ההבדל היחיד שבאמת מפריד בין אקסל של חידושים לבין מערכת לניהול סוכנות ביטוח, וכל שאר האוטומציות שתוסיף בהמשך הן שיפורי נוחות על גבי השינוי הזה.
התצוגה שמשנה את היום — כשהתאריכים כבר מסודרים במקום להיות רשימה
אותו לוח, אותם נתונים, מסך אחר. תצוגת Calendar לוקחת את עמודת ה-Date ופורסת את השורות על ימים בחודש. בתצוגת הטבלה אתה רואה רשימה ומחשב בראש מה קרוב; ב-Calendar אתה רואה שהשבוע הבא עמוס ושהשבוע שאחריו ריק — וזו מסקנה תפעולית, לא ויזואלית. סוכן שרואה חמישה חידושים בשלישי הבא יכול להזיז שתי שיחות ליום ראשון, לפני שהלחץ קורה.
מה שחשוב להבין הוא שהתצוגה לא מחזיקה מידע משלה. היא קוראת את אותה עמודת Date שהאוטומציה קוראת. אין כאן שני מקורות אמת שצריך לסנכרן, ואין העתקה — יש עמודה אחת שמזינה שני מנגנונים. איך פותחים ומגדירים את התצוגה מוסבר בהרחבה בעמוד «לראות את העבודה על ציר ימים — תצוגת לוח שנה וסנכרון יומן גוגל» במדריך מאנדיי, ולוגיקת התאריכים וטווחי-הזמן עצמם — בעמוד «תאריכים וטווחי-זמן — והשבוע שבו העסק שלך באמת עובד».
איפה זה נשבר בסוכנות — שורה שנפתחה בלי תאריך פשוט לא קיימת
זו הנקודה שמפילה את רוב הלוחות האלה, והיא לא באג — היא היגיון. אם עמודת Date היא מה שמזין את תצוגת ה-Calendar ואת האוטומציה, אז שורה שנפתחה עם שם לקוח, סוג כיסוי וסטטוס — אבל בלי תאריך — לא תופיע ביומן, לא תקבל תזכורת, ולא תעלה בשום סינון של "מה מתחדש החודש". היא יושבת בטבלה, נראית לגמרי תקינה, ושקופה לכל מנגנון שאמור לשמור עליה.
בפועל זה קורה תמיד באותם שלושה רגעים: כשמישהו פותח שורה בזמן שיחה עם לקוח ומתכוון "למלא אחר כך"; כשמייבאים תיק לקוחות מאקסל ולחלק מהשורות התאריך ריק או בפורמט שלא נקלט; וכשפוליסה חדשה נפתחת לפני שחברת הביטוח החזירה תאריך תחילה סופי.
יש גם פתרון מבני, לא רק פתרון-משמעת: קבוצה שלישית קטנה בשם "ממתין לתאריך", שאליה נכנסות שורות שנפתחו בלי תאריך חידוש. היא לא פותרת את הבעיה — היא רק הופכת אותה לגלויה. שורה בקבוצת "ממתין לתאריך" צועקת שחסר בה משהו; אותה שורה בתוך רשימת החידושים נראית בדיוק כמו כל שורה אחרת.
איזו תוכנית סוכנות כזאת צריכה — ומה לבדוק לפני שמחליטים על שדרוג
אני לא הולך לפרט כאן מדרגות ומחירים — הם משתנים, והמקום לבדוק אותם הוא עמוד התוכניות והתמחור הרשמי. מה שכן שייך לעמוד הזה הן שאלות ההחלטה הספציפיות לסוכנות ביטוח, כי הן שונות משאלות ההחלטה של סוכנות דיגיטל או מוסך.
- כמה אנשים באמת נכנסים ללוח? בסוכנות של שלושה, לרוב רק שניים עורכים והשלישי מסתכל. ספור מושבים לפי מי שעורך, לא לפי מי שיושב במשרד.
- כמה אוטומציות אתה מריץ בחודש? תזכורת אחת לכל חידוש נשמעת מעט, עד שמכפילים במאות פוליסות. זו הצריכה שקובעת אם התוכנית הבסיסית מספיקה.
- האם אתה צריך את תצוגת ה-Calendar כדי שהלוח יעבוד? אם התשובה כן — בדוק באיזו רמת תוכנית התצוגה זמינה, לפני שאתה בונה עליה את כל השיטה.
- מי מהצוות צריך לראות מה? בסוכנות יש מידע רגיש על לקוחות. אם צריך להסתיר חלק מהמידע מחלק מהאנשים — זו שאלת הרשאות, והיא נופלת ברמות תוכנית מסוימות ולא באחרות.
- מה קורה כשהתיק גדל? לוח של 200 פוליסות ולוח של 2,000 מתנהגים אחרת. אל תבחר תוכנית לפי היום; בחר לפי הגודל שאליו אתה מכוון בשנה הקרובה.
הדרך השפויה היא להתחיל ברמה הנמוכה שמאפשרת את המתכון היחיד ואת התצוגה, לרוץ איתה חודש שלם עם התיק האמיתי, ורק אז להחליט. שדרוג אפשר לעשות תמיד; להוריד מורכבות שכבר בנית — הרבה פחות.
מה עושים עם זה — ארבעה צעדים לשבוע הקרוב
- יום ראשון — הקם את הלוח על עשרים פוליסות בלבד קח את עשרים החידושים הקרובים שלך, לא את כל התיק. שם לקוח בשורה, Dropdown לסוג כיסוי, Date לתאריך החידוש, Status בשלושה מצבים. שתי קבוצות: חידושים ותביעות. תפסיק שם.
- יום שני — הפעל את המתכון האחד אוטומציה אחת שמבוססת על עמודת Date ופועלת מספר ימים לפניה. קבע את מספר הימים לפי כמה זמן באמת לוקח לך לסגור חידוש. אל תוסיף מתכון שני השבוע.
- יום רביעי — פתח את התצוגה ותסתכל על החודש עבור ל-Calendar וראה איך עשרים החידושים מתפרסים. אם הם מרוכזים בשבוע אחד — יש לך מידע תפעולי שלא היה לך קודם.
- יום ראשון הבא — הרץ את בדיקת השורות בלי תאריך סנן לשורות שעמודת ה-Date שלהן ריקה. מלא אותן או העבר לקבוצת "ממתין לתאריך". הבדיקה הזאת היא מה שמחזיק את כל המבנה בחיים לאורך זמן.
אחרי שבועיים, אם הלוח עבר את מבחן הפוליסות הראשונות, הרחב לשאר התיק. לפני זה — לא. סוכנות שמייבאת 800 שורות ביום הראשון מקבלת 800 שורות שחציין בלי תאריך, וזו בדיוק המערכת שנוטשים אחרי חודש.
העמוד הזה הוא פרק אחד בסדרה. לסקירה של כל סוגי העסק וההדגמות — מאנדיי לפי סוג עסק — 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.