כמה עולה פלטפורמת אוטומציה: Make, Zapier ו-n8n

מה המאמר הזה עושה ומה לא

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

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

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

שלוש דרכים לספור את אותו דבר

זה הלב של העניין, ומי שמבין אותו מפסיק להיות מופתע מהחשבון.

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

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

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

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

דוגמה מספרית

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

נניח 500 לידים בחודש:

• מודל משימות/פעולות: בערך 500 × 7 = 3,500 יחידות בחודש. זה כבר מוציא אתכם מהמסלולים הזולים ומכניס לרמת ביניים.
• מודל הרצות: 500 הרצות. גם המסלול הבסיסי מכסה את זה בנוחות.

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

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

מה מנפח את הצריכה בלי שתשימו לב

ארבעה דפוסים שאחראים לרוב ההפתעות:

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

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

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

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

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

מתי אירוח עצמי משתלם

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

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

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

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

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

העלויות שלא במחירון

שלושה סעיפים שמופיעים בתקציב האמיתי ולא בדף התמחור:

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

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

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

איך בוחרים לפי עלות בלי לטעות

שיטה פשוטה שלוקחת חצי שעה ומונעת את רוב ההפתעות:

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

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

לבנות זול יותר מלכתחילה

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

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

אצוות במקום בזה אחר זה. דוח יומי שמעבד מאה שורות בהרצה אחת עדיף על מאה הרצות.

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

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

שלוש נקודות שבהן החשבון קופץ

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

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

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

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

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

שאלות נפוצות

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

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

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

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

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

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

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