Make היא פלטפורמה שמחברת בין המערכות של העסק ומעבירה ביניהן מידע לבד: ליד מהאתר נכנס ל-CRM, עסקה שנסגרה מפיקה מסמך, הודעה בוואטסאפ פותחת משימה. בונים את זה על מסך ויזואלי, בלי לכתוב קוד, ומשלמים לפי כמות הפעולות שהתרחישים מבצעים בחודש.
אני בונה ב-Make כמעט בכל פרויקט, בדרך כלל לצד monday. במאמר הזה אסביר איך זה עובד, כמה זה עולה בפועל, ואראה שלושה תרחישים שרצים אצל לקוחות.
איך Make עובדת?
היחידה הבסיסית ב-Make היא תרחיש (Scenario). כל תרחיש מתחיל בטריגר, משהו שקרה: טופס נשלח, סטטוס השתנה ב-monday, הגיעה הודעה. אחרי הטריגר באים מודולים, כל אחד פעולה במערכת אחרת: לחפש רשומה, ליצור פריט, לשלוח מייל, להפיק מסמך.
מה שמבדיל את Make הוא הלוגיקה שאפשר להכניס באמצע. מסננים (filters) שעוצרים את התרחיש אם תנאי לא מתקיים, נתבים (routers) שמפצלים אותו למסלולים שונים, ולולאות שעוברות על רשימה של פריטים. ככה אפשר לבנות תהליך שמתנהג אחרת אם הלקוח קיים או חדש, אם ההזמנה מעל סכום מסוים, או אם חסר שדה.
Make מתחברת ליותר מ-3,000 אפליקציות מוכנות (נכון לאוקטובר 2026), ובהן monday, Google Sheets, WooCommerce, Shopify, Wix, ManyChat ומודלי AI כמו ChatGPT, Claude או Gemini. למערכת שאין לה חיבור מוכן, למשל חלק מתוכנות החשבוניות בישראל, אפשר בדרך כלל להתחבר ישירות דרך ה-API שלה עם מודול HTTP.
Make, Zapier או האוטומציות של monday?
שאלה שאני מקבל הרבה. התשובה תלויה בכמה מורכב התהליך ובכמה מערכות הוא נוגע.
| האוטומציות המובנות של monday | Zapier | Make | |
|---|---|---|---|
| מתאים ל | פעולות בתוך monday: שינוי סטטוס, התראה, יצירת פריט | חיבורים פשוטים וליניאריים בין שתי מערכות | תהליכים עם תנאים, פיצולים ועיבוד נתונים בין כמה מערכות |
| איך בונים | "כאשר... אז..." מתוך תבניות | שלבים אחד אחרי השני | מפה ויזואלית עם מסלולים |
| איך משלמים | כלול במנוי, עם מכסת פעולות חודשית לפי התוכנית | לפי משימות (tasks) שהצליחו | לפי קרדיטים, כמעט כל מודול שרץ |
| נקודת חולשה | מוגבל למה ש-monday יודעת לעשות | מתייקר מהר בתהליכים ארוכים | דורש יותר הבנה כדי לבנות נכון |
הכלל שאני עובד לפיו: אם אוטומציה של monday עושה את העבודה, לא צריך כלי נוסף. כשהתהליך יוצא מ-monday למערכת אחרת, או צריך החלטה באמצע, אני עובר ל-Make.
כמה עולה Make? (נכון לאוקטובר 2026)
מאז 27 באוגוסט 2025 Make מחייבת לפי קרדיטים (credits), שהחליפו את ה"פעולות" (operations) כיחידת החיוב. רוב המודולים צורכים קרדיט אחד בכל הרצה. מודולי AI ותכונות מתקדמות צורכים לפי השימוש, למשל לפי כמות הטקסט שנשלחה למודל, ולכן הם יכולים לעלות כמה קרדיטים בהרצה אחת.
- תוכנית חינמית: 1,000 קרדיטים בחודש, עד 2 תרחישים פעילים, והרצה מתוזמנת לכל היותר פעם ב-15 דקות.
- בתוכניות בתשלום (Core, Pro, Teams) המחיר נקבע לפי כמות הקרדיטים בחודש, ואין הגבלה על מספר התרחישים הפעילים. אפשר לקנות קרדיטים נוספים בחבילות. את המחיר המדויק כדאי לבדוק בדף התמחור של Make, כי הוא משתנה לפי החבילה ולפי תשלום חודשי או שנתי.
המחירים משתנים, אז כדאי לבדוק את דף התמחור של Make לפני שמחליטים.
איך מעריכים צריכה? נניח שנכנסים לעסק 200 לידים בחודש, ולכל ליד רץ תרחיש של 6 מודולים: קבלת הליד, חיפוש ב-monday, יצירת פריט, עדכון שדות, הודעת וואטסאפ והתראה לנציג. זה בערך 1,200 קרדיטים בחודש לתרחיש הזה לבד. כבר יותר ממה שהתוכנית החינמית נותנת, אבל בתוך התוכנית הבסיסית בתשלום עם הרבה מקום לתרחישים נוספים. מה שמנפח צריכה הוא בדרך כלל תרחיש שבודק כל דקה אם יש משהו חדש, גם כשאין, או לולאה שעוברת על מאות שורות בכל הרצה.
3 תרחישים אמיתיים שבניתי ב-Make
1. סוכנות נסיעות: סריקת דרכונים והצעות מחיר משינוי סטטוס
בסוכנות נסיעות שעבדתי איתה, כל הזמנה התחילה בהקלדה: לפתוח את צילום הדרכון של כל נוסע ולהקליד שם, מספר ותוקף. אחר כך לבנות הצעת מחיר מאפס לפי סוג הטיול. לקוח שביקש גרסה נוספת קיבל את כל התהליך מההתחלה.
בנינו את זה על שינויי סטטוס ב-monday, ו-Make עושה את העבודה מאחורי הקלעים. סטטוס אחד שולח את צילום הדרכון לסריקה, שולף ממנו את הפרטים וממלא את כרטיס הנוסע. סטטוס אחר מרכיב הצעת מחיר שלמה לפי סוג הטיול ומחזיר מסמך מוכן לשליחה. הצעה נוספת ללקוח קיים נבנית על הטיול שכבר יושב במערכת ויוצאת תוך דקות.
2. דרופשיפינג לאתרי בנייה: Priority, monday ותעודות משלוח בוואטסאפ
העסק הזה יושב באמצע השרשרת. הספק מגיע לאתר הבנייה עם הסחורה, אבל הלקוח הזמין מהעסק, והחשבונית בסוף החודש יוצאת מהעסק. על כל משלוח היה צריך להפיק ידנית תעודת משלוח בפריוריטי, להתאים אותה להזמנה ולהעביר ללקוח. במאות משלוחים בחודש, סוף החודש היה חיפוש.
חיברתי את פריוריטי ל-monday כך שההזמנה חיה בשני המקומות. השליח בשטח משנה סטטוס ב-monday ברגע שהוא מוסר את הסחורה, והתרחיש אוסף את פרטי ההזמנה, מפיק תעודת משלוח בפריוריטי על שם העסק ושולח אותה ללקוח בוואטסאפ. מאות תעודות בחודש יוצאות בלי שמישהו נוגע בהן, וההתאמה בין תעודה, הזמנה וחשבונית קורית לבד.
את הפירוט המלא של שני המקרים אפשר לקרוא בעמוד סיפורי הצלחה.
3. ManyChat ל-monday, עם בדיקה אם הלקוח כבר קיים
זה תרחיש שאני בונה הרבה לעסקים שמקבלים פניות באינסטגרם או בוואטסאפ. ManyChat מנהלת את השיחה הראשונה: עונה על שאלות נפוצות ואוספת שם וטלפון. ברגע שהלקוח משאיר פרטים, Make מקבלת אותם ועושה דבר אחד שהרבה חיבורים פשוטים מדלגים עליו: מחפשת ב-monday אם הלקוח כבר קיים, לפי הטלפון.
- אם הוא לא קיים, התרחיש יוצר ליד חדש עם המקור ("אינסטגרם", "וואטסאפ") ומשייך אותו לנציג.
- אם הוא קיים, התרחיש לא פותח כפילות. הוא מעדכן את הפריט הקיים, מוסיף עדכון עם תוכן הפנייה ושולח לנציג התראה שלקוח מוכר חזר.
בלי הבדיקה הזו, אחרי כמה חודשים יש ב-CRM שלושה כרטיסים לאותו אדם, וכל נציג רואה רק חלק מההיסטוריה. אם אתם מתלבטים איך לחבר את הוואטסאפ עצמו, כתבתי על זה מדריך לוואטסאפ API לעסקים.
מתי לא צריך Make?
- כשהכול קורה בתוך מערכת אחת. אם הבעיה היא תזכורת למשימה ב-monday, האוטומציה המובנית מספיקה.
- כשהתהליך עצמו לא ברור. אם כל עובד עושה את זה קצת אחרת, אוטומציה רק תעשה את הבלגן מהר יותר. קודם ממפים את התהליך, וכתבתי על זה במאמר על אפיון לפני בנייה.
- כשמדובר בפעולה שקורה פעמיים בחודש ולוקחת חמש דקות. הבנייה והתחזוקה יעלו יותר מהזמן שתחסכו.
- כשלמערכת אין שום דרך להתחבר מבחוץ (בלי API ובלי ייצוא). Make לא תוכל לעזור שם.
Make היא תשתית: מה קורה אחרי שהתרחיש עולה?
תרחיש שעובד ביום הראשון יכול להישבר בחודש השלישי. מישהו שינה שם של עמודה ב-monday, ספק החשבוניות עדכן את ה-API, טוקן החיבור פג, או לקוח מילא בטופס טלפון עם רווחים. לכן אני מתייחס לכל תרחיש כמו לתשתית שצריך לתחזק:
- טיפול בשגיאות. בכל תרחיש חשוב אני מוסיף מסלול שגיאה (error handler) שמחליט מה לעשות כשמודול נכשל: לנסות שוב, לדלג, או לעצור ולשמור את ההרצה כדי להשלים אותה אחר כך.
- התראה כשמשהו נכשל. הודעה בוואטסאפ או במייל לאדם שאחראי, עם הפריט שנתקע. ככה מגלים בעיה באותו יום, לפני שלקוח מתקשר לשאול איפה ההצעה שלו.
- מעקב אחרי צריכת הקרדיטים. קפיצה פתאומית בצריכה היא בדרך כלל סימן ללולאה שרצה יותר מדי או לטריגר שרץ סתם.
- תיעוד. רשימה פשוטה של כל התרחישים: מה כל אחד עושה, באילו מערכות הוא נוגע, ומה יקרה אם הוא יפסיק לעבוד.
את החלק הזה הכי קל לדלג עליו כשבונים לבד, ובגללו הרבה אוטומציות מפסיקות לעבוד בשקט אחרי כמה חודשים. אם אתם רוצים לראות מה אפשר לחבר אצלכם, יש פירוט בעמוד אוטומציה לעסקים, או שאפשר לכתוב לי ולספר מה גוזל לכם את השבוע.
עודכן לאחרונה: אוקטובר 2026
