Zapier או Make: פעולה אחת יכולה להפוך לכמה יחידות חיוב

|כותב: מערכת QUASA|6 דק׳ קריאה
Zapier או Make: פעולה אחת יכולה להפוך לכמה יחידות חיוב

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

ב־Make מחייבים על פעולות המודולים באמצעות credits. לפי עמוד התמחור של Make, רוב הפעולות צורכות credit אחד, אך חלק מפעולות ה־AI צורכות יותר; מכסה של 10,000 credits קובעת גם מכסות להעברת נתונים, אחסון ותור webhooks. כדי לבחור לעסק, צריך לתרגם ליד, תמליל או שינוי רשומה למסלול זהה בשני השירותים, ורק אחר כך להשוות בין מחירי התוכניות.

מה סופרים בכל הרצה

נקודת המוצא היא אירוע עסקי, לא מספר האוטומציות המוגדרות בחשבון. ב־Zapier טריגר, פילטר ו־Paths אינם צורכים משימות; הפעולות המוצלחות במסלול שפעל הן שנספרות. פעולה שלא רצה מפני שתנאי עצר אותה אינה מוסיפה משימה. ב־Make קוראים גם ממקור נתונים, מחפשים, משנים וכותבים באמצעות מודולים, ופעולה של כל מודול כזה עשויה להוסיף credit. ה־Router עצמו אינו צורך credits, אך הפעולות שמופעלות בענפים שלו כן.

יש הבדל נוסף כאשר התהליך מתחיל בבדיקה מחזורית. Zapier אינה מחייבת במשימות על בדיקות של טריגר מסוג polling. לפי הסבר הפעולות של Make, מודול טריגר רץ פעם אחת כדי לבדוק או לקבל נתונים, גם אם הוא מחזיר כמה רשומות; מודולים בהמשך המסלול עשויים לרוץ בנפרד עבור כל רשומה. בדיקה מתוזמנת שלא מצאה מידע חדש עדיין מפעילה את מודול הטריגר וצורכת credit. לכן חודש עם מעט אירועים עשוי לכלול ב־Make גם חיוב על בדיקות שבהן לא הועברה רשומה ליעד.

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

ליד ל־CRM: מתי מוסיפים חיפוש

נניח תהליך מותנה שבו ליד נכנס דרך webhook, נבדק בתנאי ונוצר כאיש קשר ב־CRM. ב־Zapier הטריגר והפילטר אינם מוסיפים משימות, ולכן יצירת איש הקשר היא משימה אחת לכל ליד שהגיע לשלב הזה. ב־Make קריאת ה־webhook ויצירת הרשומה הן שתי פעולות מודול: שני credits לליד. אם 500 לידים עברו את התנאי ונכתבו בהצלחה, האומדן הוא 500 משימות מול 1,000 credits. אלה יחידות חיוב שונות, ולא מחירים שאפשר להשוות ישירות.

כעת נניח שהעסק צריך לחפש איש קשר קיים לפני יצירה או עדכון. ב־Make החיפוש מוסיף פעולת מודול, כך שליד שעובר קריאה, חיפוש וכתיבה צורך בדרך כלל שלושה credits. ב־Zapier החיפוש עשוי לצרוך משימה או לא לצרוך אותה, בהתאם להגדרה שקובעת אם להמשיך כשהרשומה לא נמצאה. לכן אי אפשר להוסיף משימה לכל חיפוש באופן אוטומטי. אם חלק מהלידים נפסלים בתנאי, פעולת ה־CRM לא תתבצע; ב־Make עדיין צריך להביא בחשבון את פעולת הקריאה שכבר בוצעה.

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

סיכום פגישה ב־AI: מדרגת המודל משנה את המשימות

נניח שתמליל פגישה נכנס כאירוע, צעד AI מפיק סיכום, והסיכום נשמר ב־CRM. לפי תעריפי הפעולות של Zapier, צעד AI by Zapier צורך משימה אחת במדרגת Standard, שלוש ב־Advanced וחמש ב־Premium. בתהליך המותנה הזה שמירת הסיכום מוסיפה משימה, ולכן הסכום לפגישה הוא שתיים, ארבע או שש משימות, לפי המדרגה שנבחרה. קריאת כלי שה־AI מבצע מתוך הצעד מחויבת בנפרד לפי מדרגת המודל; זהו מנגנון אחר מקריאה דרך Zapier MCP.

ב־Make צריך להבחין בין חיבור לחשבון של ספק AI חיצוני לבין שימוש בספק של Make. לפי כללי ה־credits של Make, מודול AI עם חיבור לספק חיצוני צורך בדרך כלל credit אחד לפעולה, והתשלום לספק על tokens נפרד. בשימוש ב־Make AI Provider, ה־credits תלויים גם במספר ה־tokens ובמודל. לכן בתהליך מותנה של webhook, מודול AI חיצוני ושמירת סיכום ב־CRM, אומדן הפלטפורמה הוא שלושה credits לפגישה ועוד עלות הספק; אי אפשר להחיל אותו אומדן קבוע על שימוש ב־Make AI Provider.

אם מעבדים 200 פגישות כאלה בחודש ללא קריאות כלי נוספות, החישוב המותנה ב־Zapier הוא 400, 800 או 1,200 משימות לפי מדרגת המודל, וב־Make הוא כ־600 credits עם ספק AI חיצוני. אורך התמליל והתשובה אינו משנה את מספר פעולות האוטומציה בדוגמה הזאת, אך הוא עשוי לשנות את חשבון ה־tokens של הספק. אם הצעד שואל כמה שאלות, מפעיל כלי או שומר את התוצאה בכמה יעדים, צריך למנות גם את הפעולות הנוספות.

סנכרון דו־כיווני: כל כיוון הוא מסלול עבודה

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

חיפוש אחד לפני כל כתיבה מוסיף בדוגמה הזאת 200 פעולות ב־Make, ומעלה את האומדן ל־600 credits. ב־Zapier התוצאה תלויה בהגדרת החיפוש: אם הוא נספר כמשימה, האומדן עולה ל־400 משימות; אם אינו נספר, פעולות הכתיבה נותרות המרכיב המחויב. בשני השירותים נדרשים גם כללים לזיהוי הרשומה המקבילה ולהכרעה כאשר אותה רשומה משתנה בשני הצדדים. בלי הכללים האלה, העתקת שינוי הלוך ושוב עלולה ליצור עדכונים חוזרים או כפילויות, וכל פעולת תיקון שרצה מוסיפה עבודה לחשבון.

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

איזה שירות מתאים לתהליך העסקי

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

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

שיתוף:

הירשמו לניוזלטר שלנו

קבלו את החדשות האחרונות על Web3, ‏AI וקריפטו ישירות לתיבת הדואר.

0