Make אוטומציות - המדריך המלא לבניית תהליכים אוטומטיים עם Make
כלי האוטומציה שאנחנו ממליצים עליו הכי הרבה: בניית תרחישים חזותיים, חיבור מערכות עם API ו-Webhooks, סוכני AI, חישוב Credits - וכל המלכודות שכדאי להכיר.

בקצרה
Make היא פלטפורמת No-Code ו-Low-Code המאפשרת לחבר בין אפליקציות, להעביר מידע ולבצע תהליכים אוטומטיים בלי לפתח כל אינטגרציה מאפס. אוטומציות עם Make נבנות כתרחישים חזותיים, הנקראים Scenarios, ובהם אירוע מסוים מפעיל סדרת פעולות. לדוגמה: ליד מתקבל בטופס, פרטיו נבדקים, הוא מתווסף ל-CRM, נשלחת אליו הודעה ואיש המכירות מקבל התראה. ניתן לבנות במערכת תהליכים פשוטים, אוטומציות עסקיות מורכבות, חיבורים באמצעות API ו-Webhooks, תהליכי AI ואפילו סוכני AI שמפעילים כלים ומערכות בהתאם למטרה שהוגדרה להם.
פרטי הכלי
- חברה מפתחת
- Celonis (Make)
- אתר רשמי
- www.make.com
- מחיר
- חינם (1,000 Credits בחודש) / חבילות בתשלום לפי Credits (נבדק: אוגוסט 2026)
- גרסה שנבדקה
- Make Cloud (אוגוסט 2026)
- פרטיות
- אחסון EU זמין; הנתונים עוברים דרך שרתי Make - בדקו רגישות לפני חיבור
תמיכה בעברית
- ממשק: אנגלית
- קלט: מלאה בנתונים
- פלט: מלאה בנתונים
מה זה Make ואיך המערכת עובדת?
Make היא מערכת לבניית אוטומציות ואינטגרציות בין אפליקציות, מאגרי מידע ושירותים דיגיטליים. בעבר הפלטפורמה נקראה Integromat, אך המוצר הוותיק הוחלף במותג ובפלטפורמת Make. מי שמחפש כיום Integromat או מייק אוטומציות מתכוון בדרך כלל לאותה משפחת יכולות שהתפתחה לפלטפורמה הנוכחית.
כדי להבין מה אפשר לעשות עם Make, חשוב להבחין בין אינטגרציה לבין אוטומציה. אינטגרציה היא עצם החיבור בין שתי מערכות והאפשרות להעביר ביניהן מידע. אוטומציה היא התהליך העסקי שמשתמש בחיבור הזה כדי לבצע עבודה לפי טריגרים, תנאים וכללים. חיבור בין טופס ל-CRM הוא אינטגרציה. קליטת הליד, בדיקת מקור ההגעה, מניעת כפילות, שיוך לנציג ושליחת הודעה הם אוטומציה.
היחידה המרכזית במערכת נקראת Scenario, כלומר תרחיש. כל Scenario מורכב ממודולים המחוברים זה לזה ומייצגים את שלבי התהליך. המודול הראשון הוא בדרך כלל Trigger, אירוע שמתחיל את ההרצה. לאחריו מגיעים מודולים שמחפשים מידע, מעבדים אותו או מבצעים פעולה במערכת אחרת.
כך נראה תהליך בסיסי:
טופס באתר מתקבל ← Make קולטת את הליד ← בודקת מאיזה קמפיין הגיע ← מחפשת אם הוא כבר קיים ב-CRM ← יוצרת או מעדכנת את הרשומה ← שולחת הודעת WhatsApp ← מעדכנת את איש המכירות.
במהלך ההרצה, הנתונים עוברים בין המודולים כיחידות מידע המכונות Bundles. בכל מודול אפשר לבחור אילו נתונים לקבל מהשלבים הקודמים ולאילו שדות להעביר אותם. פעולה זו נקראת Mapping. אם בטופס קיימים השדות שם, אימייל וטלפון, ניתן למפות אותם לשדות המקבילים בכרטיס הלקוח ב-CRM.
אפשר להריץ תרחיש באופן ידני באמצעות Run once לצורכי בדיקה, להגדיר הפעלה במועדים קבועים, או להשתמש ב-Webhook שמפעיל את התהליך בזמן אמת מיד כאשר מתקבל אירוע. הבחירה תלויה במהירות התגובה הנדרשת, במגבלות המערכות ובכמות המידע שצריך לעבד.
למי מתאימות אוטומציות עם Make?
אוטומציות עם Make מתאימות לעסקים ולצוותים שמבצעים שוב ושוב פעולות דיגיטליות המבוססות על כללים ברורים. אין הכרח לדעת לתכנת, אך ככל שהתהליך מורכב יותר, נדרשת הבנה טובה יותר של מבני נתונים, תנאים, הרשאות, APIs וטיפול בתקלות.
אנשי שיווק יכולים להשתמש ב-Make כדי לחבר טפסים, מערכות דיוור, פלטפורמות פרסום ו-CRM. אנשי SEO יכולים לרכז נתונים, להפיק דוחות, ליצור התראות ולהעביר בריפים ותכנים בין מערכות. צוותי מכירות יכולים לנהל קליטת לידים, חלוקה לנציגים ופולואפים. מנהלי תפעול יכולים לצמצם הזנה ידנית ולסנכרן מידע בין מחלקות.
גם לבעלי חנויות, מנהלי משאבי אנוש, אנשי שירות, יוצרי תוכן ומפתחים יש שימושים רבים. מפתחים יכולים להיעזר ב-HTTP, ב-Webhooks וב-API כדי לחבר מערכות שאין להן אפליקציה מוכנה, בלי לבנות לבדם את כל שכבת התזמון, הניטור והעברת הנתונים.
Make פחות מתאימה כאשר מדובר בפעולה קטנה שכבר קיימת באופן מובנה במערכת הנוכחית, או כאשר עלות ההקמה והתחזוקה גבוהה מהזמן שהתהליך יחסוך. גם תהליכים קריטיים בעלי דרישות מחמירות במיוחד לביצועים, פרטיות, זמינות או שליטה בתשתית עשויים להצדיק פיתוח מותאם או פתרון באירוח עצמי.
מהם הרכיבים החשובים שצריך להכיר ב-Make?
לפני שבונים אוטומציה ב-Make, כדאי להכיר את אבני הבניין העיקריות של המערכת:
Modules - הרכיבים שמתחברים לאפליקציות ומבצעים חיפוש, קליטה, יצירה, עדכון או מחיקה של מידע.
Triggers - אירועים שמתחילים את התרחיש, כמו טופס חדש, הזמנה שהתקבלה או שורה שנוספה לגיליון.
Actions - פעולות שמבוצעות בעקבות הטריגר, כגון יצירת איש קשר, שליחת אימייל או עדכון משימה.
Filters - תנאים שקובעים אם המידע רשאי לעבור לשלב הבא.
Routers - פיצול התהליך למספר מסלולים בהתאם לתנאים שונים.
Iterators - פירוק רשימה למספר פריטים כדי לעבד כל אחד מהם בנפרד.
Aggregators - איחוד מספר פריטים לרשימה או לתוצאה מרוכזת אחת.
Webhooks - כתובות ייעודיות שמקבלות מידע ומפעילות תרחיש בזמן אמת.
Data Stores - מאגרי מידע פנימיים לשמירת ערכים ורשומות בין הרצות.
Variables - ערכים זמניים המשמשים במהלך הרצה מסוימת.
Functions - פונקציות לעיבוד טקסט, מספרים, מערכים ותאריכים.
Error Handlers - מסלולים שמגדירים כיצד לפעול כאשר מודול נכשל.
Subscenarios - תרחישים חוזרים שאפשר להפעיל מתוך תרחישים אחרים. נכון לאוגוסט 2026, הזמינות שלהם תלויה בין היתר בסוג הארגון והחבילה.
ההבדל בין Iterator ל-Aggregator חשוב במיוחד. Iterator לוקח מערך, למשל חמישה קבצים שהגיעו באימייל, ומפצל אותו לחמישה פריטים. המודולים הבאים יעבדו כל קובץ בנפרד. Aggregator מבצע את הפעולה ההפוכה ומרכז מספר פריטים לתוצאה מאוחדת, למשל רשימת לידים שתישלח בדוח אחד.
איך בונים אוטומציה ב-Make שלב אחר שלב?
1. מגדירים את הבעיה והתוצאה הרצויה
אוטומציה טובה מתחילה מחוץ ל-Make. לפני פתיחת ה-Scenario Builder, צריך לתאר את התהליך בשפה פשוטה: מה מתחיל אותו, איזה מידע נכנס, אילו החלטות מתקבלות ומה צריכה להיות התוצאה.
כדאי לענות מראש על השאלות הבאות:
מהו הטריגר שמתחיל את התהליך?
אילו שדות ומסמכים מתקבלים?
אילו נתונים הם חובה?
האם צריך לבדוק כפילויות?
אילו תנאים משפיעים על מסלול הטיפול?
מה צריכה להיות התוצאה הסופית?
מה יקרה אם אחת המערכות אינה זמינה?
2. יוצרים Scenario חדש
לאחר פתיחת חשבון ב-Make יוצרים תרחיש חדש ובוחרים את האפליקציה הראשונה. מומלץ לתת לתרחיש שם שמתאר במדויק את מטרתו, למשל "Website Leads to CRM and Sales Alert", ולא שם כללי כמו "Scenario 1".
3. בוחרים Trigger
ה-Trigger יכול להיות שורה חדשה ב-Google Sheets, טופס שהתקבל, הודעת Gmail, ליד חדש ממערכת פרסום, הזמנה בחנות או Custom Webhook. אם האפליקציה תומכת ב-Instant Trigger, המידע יכול להגיע מיד. אם לא, Make תבדוק במרווחי זמן אם הופיע מידע חדש.
4. מחברים את החשבונות
Connection הוא החיבור המאושר בין Make לבין מערכת חיצונית. במהלך יצירת החיבור המשתמש מתבקש להתחבר לחשבון ולאשר הרשאות. חשוב לקרוא אילו הרשאות מתבקשות ולהעניק רק את ההרשאות הדרושות להפעלת התרחיש.
5. מוסיפים פעולות
אחרי הטריגר מוסיפים את הפעולות שצריכות להתבצע. לדוגמה, חיפוש איש קשר ב-CRM, יצירת רשומה חדשה, הוספת שורה בגיליון ושליחת הודעת אישור.
6. ממפים את הנתונים
Mapping מחבר בין הפלט של מודול אחד לקלט של המודול הבא. אם הטופס שולח full_name, email ו-phone, יש להתאים כל ערך לשדה הנכון במערכת היעד. בשלב הזה מומלץ גם לנרמל נתונים, למשל להסיר רווחים ממספר טלפון, להמיר אותו לפורמט בינלאומי ולהפוך אימייל לאותיות קטנות.
7. מוסיפים Filters ו-Routers
Filter מאפשר להעביר רק מידע שעומד בתנאי. אפשר, למשל, לעצור ליד ללא מספר טלפון או להעביר רק הזמנות ששולמו. Router מאפשר לפצל את התהליך: לידים מישראל עוברים לנציג מקומי, לידים מחו"ל לצוות בינלאומי ולידים בעלי תקציב גבוה למנהל מכירות.
8. מריצים Run once
Run once מאפשר לקבל דוגמת נתונים אמיתית ולבדוק את המיפוי. רצוי להשתמש ברשומת בדיקה ייעודית ולא בלקוח אמיתי, במיוחד אם התרחיש כולל שליחת הודעות, יצירת חשבוניות, מחיקה או עדכון מידע.
9. בודקים את היסטוריית ההרצות
לא מספיק לבדוק אם המודולים הפכו לירוקים. יש לפתוח את פרטי ההרצה ולבדוק מה נכנס ומה יצא מכל מודול, אילו מסלולים הופעלו, האם המידע נשמר בשדות הנכונים וכמה Credits נצרכו.
10. קובעים תזמון ומפעילים
לבסוף מגדירים אם התרחיש ירוץ מיד, אחת למספר דקות, פעם ביום או לפי לוח זמנים אחר. לפני ההפעלה כדאי להוסיף התראות, Error Handlers ותיעוד קצר שמסביר את מטרת התרחיש ואת התלות שלו במערכות אחרות.
דוגמה מלאה: איך להעביר לידים מטופס ל-CRM באמצעות Make?
נניח שהעסק מקבל לידים דרך Facebook Lead Ads ורוצה להעביר אותם ל-Google Sheets, ל-CRM ולמערכת הודעות. התהליך יכול להיראות כך:
Facebook Lead Ads ← Make ← בדיקת תקינות ← חיפוש ב-CRM ← יצירה או עדכון ← הודעת אישור ← התראה לאיש המכירות
הטריגר קולט ליד חדש ומעביר ל-Make את השם, האימייל, הטלפון, שם הקמפיין ותשובות נוספות מהטופס. המודול הבא מנקה את הנתונים: מסיר תווים מיותרים מהטלפון, ממיר את האימייל לפורמט אחיד ובודק שקיימת לפחות דרך תקשורת אחת.
לאחר מכן מופעל Filter. ליד שאין בו אימייל תקין וגם אין בו מספר טלפון אינו ממשיך למסלול המכירה. במקום להיעלם, הוא מועבר למסלול נפרד ששומר אותו בגיליון "Invalid Leads" לצורך בדיקה.
הלידים התקינים עוברים למודול חיפוש ב-CRM. החיפוש מתבצע לפי אימייל או מספר טלפון מנורמל. אם הרשומה כבר קיימת, Make מעדכנת את מקור הליד ואת תאריך הפנייה האחרון. אם היא אינה קיימת, נוצרת רשומה חדשה. כך מונעים יצירה חוזרת של אותו איש קשר בכל פעם שהוא ממלא טופס.
לאחר השמירה נשלחת ללקוח הודעת אישור, בכפוף להסכמה ולכללי הפלטפורמה שדרכה נשלחת ההודעה. במקביל, נשלחת לנציג המכירות התראה הכוללת את פרטי הליד, מקור הקמפיין וקישור לכרטיס ב-CRM.
אם החיבור ל-CRM נכשל זמנית, Error Handler יכול לשמור את פרטי הכשל ולהפעיל ניסיון חוזר. אם הבעיה נמשכת, נשלחת התראה לאחראי והליד נשמר בתור לטיפול. המטרה היא למנוע מצב שבו תקלה רגעית גורמת לאובדן פנייה.
זהו ההבדל בין חיבור בסיסי לבין אוטומציה עסקית שמתאימה לשימוש אמיתי: התהליך אינו רק מעביר מידע, אלא בודק אותו, מונע כפילויות ויודע להתמודד עם כשל.
אילו אוטומציות אפשר לבנות עם Make?
אוטומציות לשיווק ולמכירות
אפשר לקלוט לידים מטפסים וממודעות, לסנכרן אותם עם CRM, לדרג אותם לפי מאפיינים, לחלק אותם בין נציגים וליצור משימות פולואפ. ניתן גם לעדכן קהלים במערכות פרסום, להעשיר מידע ולרכז ביצועי קמפיינים בדוחות.
Make אוטומציות לאנשי SEO ותוכן
אנשי SEO יכולים להשתמש ב-Make כדי לרכז נתונים ממקורות שונים, לעבד קבצים ולשלוח דוחות תקופתיים. אפשר ליצור בריף תוכן באמצעות AI, להעביר טיוטה למסמך, לפתוח משימת עריכה ולשלוח אותה לאישור אנושי. אפשר גם לנטר עמודים, לזהות שינויים או תקלות ולהתריע לצוות.
ה-AI אינו צריך לקבל שליטה אוטומטית בפרסום. בתהליך מקצועי הוא יכול להציע כותרות, לסכם מידע או לסווג בעיות, אך החלטות כמו מחיקת עמוד, שינוי Canonical או פרסום תוכן צריכות לעבור בדיקה.
שירות לקוחות
Make יכולה לפתוח קריאה בעקבות טופס או אימייל, לזהות את נושא הפנייה, לנתב אותה למחלקה המתאימה ולשלוח אישור קבלה. מודל AI יכול לסכם שרשור ארוך או להציע קטגוריה, בעוד שהמערכת העסקית שומרת את הפנייה ומנהלת את הסטטוס.
כספים ותפעול
אפשר לחבר עסקה שאושרה להפקת מסמך, לעקוב אחר תשלום, לסנכרן הזמנות ומלאי וליצור משימות תפעוליות. בתהליכים כספיים חשוב להוסיף בדיקות כפילות, הרשאות מצומצמות ואישור אנושי לפני פעולות בלתי הפיכות. להעמקה ניתן לקרוא את המדריך על אוטומציה של חשבוניות ומעקב תשלומים.
משאבי אנוש
Make יכולה לקלוט מועמדים, לסכם קורות חיים, לפתוח משימות לצוות הגיוס ולהפעיל תהליך Onboarding לעובד חדש. עם זאת, אין להשתמש בהחלטת AI אוטומטית כתחליף לבחינה אנושית, במיוחד כאשר היא עשויה להשפיע על קבלה לעבודה.
איך משלבים ChatGPT או Claude באוטומציות של Make?
השילוב הפשוט ביותר הוא הוספת מודל AI כשלב בתוך תרחיש רגיל. לדוגמה:
טופס נכנס ← מודל AI מסכם ומסווג את הפנייה ← Make בודקת את הסיווג ← הפנייה מועברת למחלקה המתאימה.
AI מתאים במיוחד למשימות שבהן הקלט אינו אחיד ונדרשת פרשנות: סיכום טקסט, חילוץ פרטים, סיווג פנייה, יצירת טיוטה או הערכת כוונת המשתמש. לעומת זאת, בדיקות הרשאה, חישובים כספיים, מניעת כפילות ופעולות קריטיות עדיף להשאיר במסלול המבוסס על כללים קבועים.
כדי שהשילוב יהיה אמין, מומלץ לבקש מהמודל להחזיר פלט מובנה, למשל JSON עם שדות מוגדרים מראש. לאחר מכן צריך לבדוק שהשדות קיימים, שהערכים נמצאים בטווחים מותרים ושהמודל לא החזיר טקסט במקום המבנה המבוקש.
מה ההבדל בין תרחיש רגיל לבין Make AI Agent?
Scenario רגיל מבצע מסלול שהוגדר מראש. אם מגיע ליד מאזור מסוים, הוא עובר לנתיב מסוים. כל החלטה וכל פעולה תוכננו על ידי בונה האוטומציה.
Make AI Agent מקבל מטרה, הוראות, הקשר וכלים זמינים ויכול להחליט אילו פעולות לבצע ובאיזה סדר. לדוגמה, Agent המטפל בפניית לקוח יכול לבדוק מידע במערכת, לחפש סטטוס הזמנה, לסכם את המקרה ולבחור אם לפתוח משימה או להעביר את הפנייה לנציג.
Make מציגה את סוכני ה-AI שלה כשכבה המשלבת קבלת החלטות עם פעולות אמיתיות במערכות מחוברות, תוך אפשרות לצפות בהחלטות ולהוסיף בקרה. מידע רשמי על Make AI Agents.
סוכן AI אינו עדיף אוטומטית על תרחיש רגיל. אם התהליך צפוי ומבוסס על כללים, Scenario רגיל יהיה לרוב זול, יציב וקל יותר לבדיקה. Agent מתאים כאשר יש מגוון מצבים שקשה לייצג באמצעות עשרות מסלולים קשיחים. גם אז חשוב להגביל את הכלים, את היקף הנתונים ואת הפעולות שהסוכן רשאי לבצע.
מה אפשר לעשות עם Make MCP?
MCP הוא פרוטוקול המאפשר למערכות AI להתחבר לכלים ולמקורות מידע באופן מובנה. Make MCP Server מאפשר למערכות AI תואמות להפעיל תרחישים ולבצע פעולות מסוימות בחשבון Make. התיעוד הרשמי של Make MCP Server.
במקום שהמשתמש ייכנס ל-Make ויפעיל תרחיש בעצמו, הוא יכול לבקש מסוכן AI לבצע פעולה:
"חפש את הלקוח במערכת, פתח עבורו משימת המשך ועדכן את איש המכירות."
ה-AI מפרש את הבקשה ומפעיל כלי מתאים שהוגדר באמצעות Make. כך ניתן להפוך תרחישים קיימים לכלים ש-ChatGPT, Claude או לקוחות MCP תואמים יכולים להפעיל.
החיבור אינו מעניק לסוכן הרשאה בלתי מוגבלת באופן אוטומטי. צריך להגדיר Scopes, לנהל Tokens או OAuth ולבחור אילו פעולות זמינות. מומלץ להתחיל בכלים לקריאה בלבד ורק לאחר בדיקות לאפשר כתיבה או שינוי מידע.
איך מחברים מערכת שאין לה אינטגרציה מוכנה ב-Make?
היעדר אפליקציה מוכנה אינו אומר בהכרח שאי אפשר לחבר את המערכת. אם יש לה API מתועד, אפשר להשתמש במודול HTTP כדי לשלוח בקשות ולקבל מידע. אם היא מסוגלת לשלוח Webhooks, אפשר לקלוט ממנה אירועים בזמן אמת.
בדרך כלל צריך לבדוק:
האם למערכת יש API פעיל ומתועד?
באיזו שיטת אימות היא משתמשת?
אילו Endpoints זמינים?
מהם מבנה הבקשה והפלט?
האם קיימות מגבלות קצב?
האם אפשר לקבל Webhook כאשר מידע משתנה?
כיצד מטופלים עימוד, שגיאות ותוקף הרשאות?
חיבור באמצעות API דורש יותר ידע מחיבור אפליקציה מוכנה, אך הוא מעניק גמישות רבה. אין לשמור מפתחות API בתוך טקסטים, פרומפטים או שדות גלויים בתרחיש.
כמה עולה Make והאם אפשר להשתמש בה בחינם?
Make מציעה תוכנית חינמית לצד חבילות בתשלום. נכון למועד כתיבת המדריך, התוכנית החינמית כוללת הקצאה חודשית של 1,000 Credits, אך החבילות, המחירים והמגבלות עשויים להשתנות ולכן יש לבדוק אותם בעמוד התמחור הרשמי של Make.
חשוב להבחין בין Operations לבין Credits. Operation מתארת פעילות שבוצעה בתרחיש, למשל הרצה של מודול שמעבד או בודק מידע. Credit הוא יחידת השימוש שעליה מבוססת החבילה. ברוב הפעולות הרגילות היחס הוא Credit אחד לכל Operation, אך בתכונות מסוימות, במיוחד שירותי AI מובנים וקוד, החיוב עשוי להיות דינמי ולהתחשב בטוקנים, בזמן הרצה או בגורמים נוספים. הסבר רשמי על Credits ו-Operations.
גם מספר הפריטים משפיע על הצריכה. מודול חיפוש עשוי לצרוך פעולה אחת ולהחזיר עשרה Bundles, אך מודול הפעולה שאחריו עשוי לרוץ פעם אחת עבור כל Bundle. לכן תרחיש שנראה כאילו יש בו חמישה מודולים אינו בהכרח צורך חמישה Credits בלבד.
איך מחשבים כמה Credits תצרוך אוטומציה?
אפשר להתחיל מהערכה עקרונית:
מספר הרצות × מספר פעולות בכל הרצה × מספר הפריטים המעובדים
זו אינה נוסחת חיוב מדויקת לכל תרחיש. Router ו-Filter, למשל, אינם צורכים Credits בפני עצמם לפי התיעוד הנוכחי, בעוד שמודולים אחרים עשויים לרוץ פעמים רבות בעקבות Iterator או פלט הכולל מספר Bundles. שימוש ביכולות AI מסוימות עשוי להוסיף חיוב דינמי לפי טוקנים. כך תכונות שונות צורכות Credits.
נניח שתרחיש רץ 1,000 פעמים בחודש. בכל הרצה הוא קולט ליד, מחפש אותו ב-CRM, יוצר או מעדכן רשומה ושולח התראה. אם בכל הרצה עובר ליד אחד, אפשר לבצע הערכה ראשונית לפי מספר המודולים שרצו בפועל. אם כל הרצה מחזירה עשרה פריטים ומפעילה על כל אחד מהם שתי פעולות, הצריכה תהיה גבוהה משמעותית.
הדרך המדויקת ביותר היא להריץ נתוני בדיקה מייצגים, לבדוק את צריכת ה-Credits בהיסטוריית ההרצות ולהכפיל לפי נפח הפעילות הצפוי. לאחר ההפעלה יש לעקוב אחר הצריכה בפועל ולא להסתמך רק על ההערכה הראשונית.
Make מול Zapier ומול n8n: מה עדיף?
אין כלי אחד שמתאים לכל תהליך. Make בולטת בממשק חזותי שמקל להבין תרחישים מסועפים, ביכולות עיבוד נתונים ובגמישות בחיבור APIs. Zapier נוחה בדרך כלל להתחלה מהירה ולתהליכים ליניאריים. n8n פונה יותר למשתמשים טכניים ומציעה גם אפשרויות אירוח עצמי ושליטה רחבה בתשתית.
פרמטר | Make | Zapier | n8n |
|---|---|---|---|
אופי הממשק | חזותי ומסועף | פשוט וליניארי יחסית | טכני וגמיש |
קהל מרכזי | משתמשים עסקיים וטכניים | מתחילים וצוותים עסקיים | מפתחים ומשתמשים טכניים |
תהליכים מורכבים | חזקה מאוד | נוחה בעיקר בפשטות ובבינוניות | חזקה מאוד |
אירוח עצמי | לא | לא | אפשרי |
עקומת למידה | בינונית | קצרה יחסית | בינונית עד גבוהה |
עבודה עם API | גמישה | אפשרית | גמישה מאוד |
AI Agents ו-MCP | קיימים | קיימות יכולות AI וכלים | אפשר לבנות ולחבר |
אם אתם מתלבטים בין שתי הפלטפורמות הפופולריות, מומלץ לקרוא את ההשוואה המלאה בין Make ל-Zapier. ההחלטה צריכה להתבסס על מורכבות התהליך, היקף השימוש, יכולות הצוות, דרישות השליטה והעלות הכוללת לאורך זמן.
טעויות נפוצות בבניית Make אוטומציות
רוב התקלות אינן מתחילות במודול הלא נכון אלא בתכנון חסר. תרחיש יכול לעבוד היטב בבדיקה אחת ועדיין להיכשל כאשר שדה חסר, מערכת חיצונית אינה זמינה או מתקבלים מספר פריטים במקום פריט אחד.
טעויות שכדאי למנוע:
בניית Scenario לפני הגדרת התהליך העסקי.
הנחה שכל הרשומות יגיעו באותו מבנה.
אי-בדיקת ערכים חסרים או פורמטים לא תקינים.
יצירת לקוחות, משימות או חשבוניות כפולות.
אי-הגדרת Error Handler והתראות.
התעלמות ממגבלות API ומזמני המתנה.
ביצוע חיפושים ופעולות מיותרים שצורכים Credits.
יצירת תרחיש עצום שקשה לבדוק ולתחזק.
שמירת מידע רגיש בשדות גלויים.
שימוש ב-AI ללא בדיקת פלט.
הפעלת התרחיש על כל המידע לפני בדיקה מדורגת.
יצירת לולאה שבה עדכון של Make מפעיל שוב את אותו תרחיש.
כדי למנוע לולאה, אפשר להוסיף שדה המציין שמקור העדכון הוא Make, לשמור מזהה אירוע שכבר עובד או להגדיר Filter שמתעלם מעדכונים שנוצרו על ידי האוטומציה עצמה.
כיצד מטפלים בשגיאות ב-Make?
כאשר מודול נכשל, לא תמיד נכון לעצור את כל התרחיש. ההחלטה תלויה בסוג התקלה ובחשיבות הפעולה. תקלה זמנית בחיבור מצדיקה לעיתים Retry. רשומה חסרת שדה יכולה לעבור למסלול בדיקה. כשל בפעולה כספית עשוי לדרוש עצירה מלאה והתראה מיידית.
Error Handler מאפשר ליצור מסלול טיפול היוצא מהמודול שעלול להיכשל. אפשר לשמור את פרטי השגיאה, לשלוח התראה, לדלג על פריט, לספק ערך חלופי או לנסות שוב. Make מספקת מספר אסטרטגיות טיפול, ובהן Retry, Resume, Ignore ו-Rollback, אך לא כל פעולה חיצונית ניתנת לביטול לאחר שכבר בוצעה. המדריך הרשמי לטיפול בשגיאות.
Retry מתאים לתקלות זמניות, כמו שירות שאינו זמין או מגבלת קצב. אין להשתמש בו באופן עיוור בשלב שעלול ליצור פעולה כפולה. לפני ניסיון חוזר כדאי לבדוק אם הרשומה או התשלום כבר נוצרו במערכת היעד.
אוטומציה אינה מוכנה לשימוש אמיתי רק משום שעבדה פעם אחת ב-Run once. צריך לבדוק אותה עם מידע חסר, ערכים כפולים, מספר פריטים, תגובה איטית, כשל זמני ותשובה בלתי צפויה מה-API.
אבטחת מידע והרשאות באוטומציות עם Make
כל אוטומציה מרחיבה את מספר המקומות שדרכם מידע עובר. לכן צריך להתייחס להרשאות ולפרטיות כחלק מהתכנון, ולא כבדיקה שמבצעים בסוף.
יש להעניק לכל Connection רק את ההרשאות הדרושות, להימנע מחשבונות משותפים, להגן על כתובות Webhook ולא להכניס סיסמאות או מפתחות API לפרומפטים. מומלץ להפריד בין תרחישי בדיקה לתרחישים פעילים ולהשתמש במידע מדומה או מצומצם במהלך הפיתוח.
לפני חיבור מודל AI צריך לבדוק איזה מידע נשלח אליו, האם הוא כולל מידע אישי או עסקי רגיש ומהן הגדרות השמירה של הספק. פעולות כמו מחיקה, העברת כסף, פרסום תוכן ושליחת מידע רגיש צריכות לכלול אישור אנושי או שכבת אימות חזקה.
איך יודעים אם אוטומציית Make באמת משתלמת?
לא כל משימה שניתן להפוך לאוטומטית ראויה לאוטומציה. תהליך טוב הוא בדרך כלל תהליך שחוזר בתדירות גבוהה, מבוסס על כללים, צורך זמן וגורם לטעויות כאשר הוא מתבצע ידנית.
כדי להעריך כדאיות, מחשבים כמה פעמים המשימה מתבצעת בחודש, כמה זמן נחסך בכל פעם ומהי עלות שעת העבודה. לאחר מכן מפחיתים את עלות Make, המערכות הנוספות, ההקמה והתחזוקה.
חיסכון חודשי = שעות עבודה שנחסכו × עלות שעת עבודה - עלות המערכות והתחזוקה
כדאי לכלול גם את ערך צמצום הטעויות, קיצור זמן התגובה ושיפור חוויית הלקוח. מנגד, יש להביא בחשבון את הנזק האפשרי מתקלה. אוטומציה שחוסכת שעתיים בחודש אך עלולה לשלוח חשבוניות כפולות אינה בהכרח עסקה טובה.
לרוב כדאי להתחיל בתהליך קטן, מדיד והפיך. לאחר שמוכיחים שהוא יציב וחוסך זמן, אפשר להרחיב אותו. גישה זו מתאימה גם לעסקים שמחפשים קיצור תהליכי עבודה עם AI בלי לאבד שליטה.
איך לבחור תהליך ראשון לאוטומציה?
בחרו משימה שחוזרת מספר פעמים בשבוע, אינה דורשת שיקול דעת מורכב ויש לה קלט ותוצאה ברורים. קליטת לידים, יצירת משימה בעקבות טופס, ריכוז נתונים לדוח או שליחת התראה פנימית הן נקודות פתיחה טובות.
הימנעו בתחילת הדרך מתהליך שכולל כסף, מחיקה, מידע רגיש או עשרות מערכות. המטרה של האוטומציה הראשונה היא ללמוד כיצד הנתונים עוברים, כיצד Make מציגה הרצות ואיך מזהים תקלה, בלי לסכן תהליך מרכזי בעסק.
אם המטרה היא תקשורת אוטומטית בעקבות פנייה, אפשר להיעזר גם במדריך על בניית אוטומציה לוואטסאפ לעסק.
השורה התחתונה: האם כדאי לבנות מייק אוטומציות לעסק?
Make היא פלטפורמה חזקה לבניית אוטומציות עסקיות, חיבור אפליקציות ושילוב AI בתהליכי עבודה. היתרון הגדול שלה אינו רק בחיבור בין מערכות, אלא ביכולת לראות את זרימת המידע, להוסיף תנאים ומסלולים ולטפל בתהליכים מורכבים בלי לפתח הכול מאפס.
עם זאת, אוטומציה מוצלחת אינה נמדדת במספר המודולים. היא נמדדת בכך שהיא חוסכת זמן, מונעת טעויות, מתמודדת עם מידע בלתי צפוי ומאפשרת להבין במהירות מה קרה כאשר משהו נכשל. התחילו בתהליך קטן, בדקו אותו עם נתונים אמיתיים, הוסיפו טיפול בשגיאות ורק אז הרחיבו אותו.
ב-WorkWithAI תמצאו מדריכים מעשיים, השוואות ותהליכי עבודה שיעזרו לכם להפוך את Make, כלי AI ואוטומציות לחלק אמיתי מהעבודה. אם אתם רוצים לזהות אילו תהליכים כדאי להפוך לאוטומטיים ואיך לבנות אותם בלי לאבד שליטה, המשיכו למדריכים של WorkWithAI והתחילו מהמשימה החוזרת שגוזלת מכם הכי הרבה זמן.
שאלות נפוצות על Make אוטומציות
כן. אפשר לבנות ב-Make תהליכים רבים באמצעות ממשק חזותי, מיפוי שדות ומודולים מוכנים, ללא כתיבת קוד. עם זאת, בתרחישים מתקדמים ידע ב-API, JSON, ביטויים לוגיים ומבני נתונים מאפשר לפתור בעיות מורכבות יותר. לכן נכון לראות בה פלטפורמת No-Code שמציעה גם יכולות Low-Code.
כן. Make יכולה להעביר ולעבד טקסט בעברית כל עוד המערכות המחוברות והקידוד שלהן תומכים בכך. ממשק המערכת עצמו עשוי להיות באנגלית, אך ניתן למפות שמות, הודעות, מסמכים ותוכן בעברית. בשילוב AI חשוב לבדוק את איכות המודל בעברית ולא להניח שכל מודל יחזיר תוצאה זהה.
אפשר לבנות תהליכים בסיסיים ללא ידע בתכנות. כדי לעבוד באופן אמין צריך להבין טריגרים, מיפוי, תנאים והיסטוריית הרצות. תרחישים הכוללים APIs, מערכים, Webhooks או טיפול מתקדם בשגיאות דורשים למידה טכנית מסוימת, גם אם אינם דורשים פיתוח מלא.
כן. Make מציעה תוכנית חינמית עם הקצאת Credits חודשית ומגבלות מסוימות. היא יכולה להספיק ללמידה, לבדיקות ולאוטומציות בעלות נפח נמוך. מאחר שהתמחור וההקצאות עשויים להשתנות, כדאי לבדוק את עמוד התמחור הרשמי לפני בחירת חבילה.
ההתנהגות תלויה בסוג השגיאה ובהגדרות התרחיש. הרצה יכולה להיעצר, להישמר כ-Incomplete Execution או לעבור למסלול Error Handler. בתהליך חשוב מומלץ להגדיר שמירת פרטי כשל, התראה וניסיון חוזר מבוקר, ולא להסתמך על ברירת המחדל.
כן. אם למערכת יש API נגיש ומתועד, אפשר בדרך כלל להשתמש במודול HTTP כדי לשלוח בקשות. צריך להגדיר כתובת Endpoint, שיטת בקשה, Headers, אימות וגוף הבקשה. לפני ההפעלה יש לבדוק מגבלות קצב, מבנה שגיאות ואופן חידוש ההרשאות.
אפשר לחבר מספר מערכות באותו Scenario, אך לא תמיד כדאי לרכז הכול בתרחיש יחיד. ככל שמספר המודולים והמסלולים גדל, התחזוקה והאיתור של תקלות נעשים מורכבים יותר. תהליך גדול כדאי לפצל ליחידות לוגיות, ולעיתים להשתמש ב-Subscenarios.
כן. אפשר לחבר מודלים כמו ChatGPT ו-Claude לתרחישים, להשתמש בכלי AI מובנים ולבנות Make AI Agents. AI מתאים במיוחד לסיכום, סיווג, חילוץ ויצירת טיוטות. פעולות קריטיות צריכות להישאר תחת כללים קשיחים, בדיקות ואישור אנושי.
Make יכולה להחליף פעולות ידניות חוזרות, אך לא תפקיד אנושי שלם ברוב המקרים. היא טובה בהעברת מידע, בדיקות קבועות, תזמון והתראות. בני אדם עדיין נדרשים להגדרת התהליך, טיפול במקרים חריגים, קבלת החלטות ותחזוקה.
תרחיש בסיסי יכול להיבנות בתוך שעה, אך תהליך עסקי אמין עשוי לדרוש מספר שעות או ימים של אפיון, בדיקות ותיקונים. משך העבודה תלוי במספר המערכות, באיכות ה-API, במבנה הנתונים, בתנאים, בכמות החריגים ובדרישות האבטחה.
אפשר להפחית צריכה באמצעות תדירות תזמון נכונה, סינון מוקדם של מידע, צמצום חיפושים מיותרים, איחוד פעולות ועיבוד רק של רשומות שהשתנו. חשוב לבדוק בפועל כמה Bundles עוברים בכל מסלול, משום שמודול שרץ עבור כל פריט עלול להגדיל משמעותית את הצריכה.
Webhook מפעיל את התרחיש מיד כאשר מערכת חיצונית שולחת אירוע. תרחיש מתוזמן נפתח במרווחי זמן ובודק אם יש מידע חדש. Webhook מתאים לתגובה מהירה וחוסך בדיקות חוזרות, אך דורש שהמערכת השולחת תתמוך בו. תזמון מתאים למערכות שאין בהן התראות בזמן אמת או לתהליכים תקופתיים.
מייסד WorkWithAI
בונה תהליכי עבודה עם AI לעסקים ולעצמאים. בודק כל כלי בעבודה אמיתית לפני שממליץ עליו.
- אוטומציות
- כלי AI לעסקים
- עבודה בעברית


