n8n מול Make — השוואה מלאה

הציר היחיד שמהם נגזר כל השאר

אפשר לפרוס טבלה עם ארבעים שורות ולא להכריע כלום. ההבדל האמיתי בין n8n ל-Make הוא שאלה אחת: מי מחזיק את המכונה שמריצה את האוטומציה.

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

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

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

הציר השני: מה בדיוק נספר

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

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

ההבדל הזה לא "אחד זול יותר". הוא הופך את הכיוון לפי צורת התהליך שלך:

תהליך ארוך שרץ מעט
  30 צעדים × 200 הרצות בחודש
  Make:  6,000 פעולות
  n8n:     200 הרצות
  → n8n זול בהרבה

תהליך קצר שרץ הרבה
  3 צעדים × 20,000 הרצות בחודש
  Make:  60,000 פעולות
  n8n:   20,000 הרצות
  → הפער מצטמצם מאוד

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

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

איך שיטת הספירה משנה את מה שתבנה

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

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

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

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

אותו תהליך, בשניהם

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

ב-Make
  1. Webhook            — הטופס נכנס
  2. Set                — נרמול טלפון ותאריך
  3. Router             — לקוח קיים או חדש?
  4. Search (CRM)       — חיפוש לפי טלפון
  5. Create/Update      — לפי הענף
  6. Email/WhatsApp     — תשובה ראשונית
  7. Create Task        — משימה למעקב
  → 7 פעולות בהרצה. 300 פניות = 2,100 פעולות.

ב-n8n
  אותם שבעה צמתים בדיוק
  → 300 הרצות בחודש.

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

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

מה שכן שונה בבנייה עצמה: הנרמול בצעד 2. ב-n8n זו שורת קוד; ב-Make זה שילוב של פונקציות טקסט בממשק. שניהם עובדים, ואחד מהם מהיר יותר לכתוב ולקרוא בעוד חצי שנה.

קלות ההתחלה

כאן Make מנצח בבירור, ואין טעם לטשטש את זה.

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

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

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

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

כשמשהו נשבר

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

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

כשמגיעים לקיר

בשלב מסוים תצטרך משהו שאין לו מודול מוכן. שם ההבדל נעשה ממשי.

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

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

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

הזווית הישראלית

זה החלק שאף השוואה זרה לא תכסה, והוא לרוב מה שמכריע בפועל.

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

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

שני פרטים נוספים:

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

עברית בתוך הזרימה

ארבעה דברים שנשברים ושאף אחד לא מזהיר מהם:

• טלפונים. מספר ישראלי מגיע בארבע צורות — עם אפס, בלי, עם מקף, עם קידומת בינלאומית. בלי נרמול בכניסה, אותו לקוח ייווצר שלוש פעמים ב-CRM. שורת עיבוד אחת בתחילת התהליך פותרת את זה לנצח.
• תאריכים. 3/9 הוא שלושה בספטמבר כאן ותשעה במרץ במערכת אמריקאית. בכל שדה שעובר בין שירותים — פורמט YYYY-MM-DD, שאין בו אי-בהירות.
• כיווניות בהודעות. טקסט עברי שמסתיים במספר או בקישור מתהפך בתצוגה. בהודעה שנשלחת ללקוח זה נראה כמו שגיאה. אם זה חוזר — הוסף תו כיווניות בתחילת השורה, או סדר את המשפט כך שלא יסתיים במספר.
• שמות שדות בעברית. עובדים, ומקשים על ניפוי כשהם עוברים דרך JSON. שדות באנגלית, תוכן בעברית — זה הכלל שחוסך זמן.

איפה מודל שפה נכנס לתמונה

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

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

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

שלוש הגנות שלוקחות דקות:

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

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

מידע: מה עובר ולאן

כאן חוזר הציר הראשון, ובשביל חלק מהעסקים הוא מכריע לבדו.

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

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

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

מה עולה לך באמת

"n8n חינם" הוא משפט נכון וחלקי, וההשלמה שלו היא ההבדל בין חיסכון לצרה.

התוכנה חינם; ההרצה לא. בהתקנה עצמית אתה משלם על:

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

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

ולצאת

שאלה ששווה לשאול ביום הראשון, כי התשובה קובעת כמה מסוכן לטעות.

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

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

ומה עם צוות

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

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

שלושה הרגלים שמכסים את רוב זה בלי כלים:

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

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

לעבור מאחד לשני

שאלה שעולה אחרי חצי שנה, לרוב כשהחשבון של Make התחיל להכאיב.

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

מה שכן לוקח זמן, ושכדאי לתכנן:

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

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

ההכרעה

בלי לשבת על הגדר:

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

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

ולמי שרוצה להוסיף שחקן שלישי לתמונה: ההשוואה המלאה עם Zapier.

כששניהם לא התשובה

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

טעויות שחוזרות

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