מלאי ושימוש
אנחנו רושמים כל Zap או תרחיש, עם הטריגר, האפליקציות, השלבים, בעל ההרשאות והשימוש בפועל, ומסמנים תהליכים שאינם בשימוש, כפילויות ותהליכים קריטיים.
אם החיוב שלכם ל-Zapier או ל-Make גדל עם כל שלב שאתם מוסיפים, כדאי לבדוק מה n8n יכול לחסוך. אנחנו מבצעים את המעבר בשיטתיות: מלאי, בנייה מחדש והחלפה.
מעבר מ-Zapier או Make ל-n8n פירושו לתעד את תהליכי העבודה שלכם, לבנות אותם מחדש ב-n8n ולהריץ אותם לצד המקוריים לפני שמכבים דבר. אנחנו מלווים את כל התהליך מרחוק, לחברות שכבר עובדות עם אוטומציות ורוצות שליטה בעלות לכל הרצה. אפשר להתחיל בניסיון של 7 ימים, שבו מעבירים תהליך עבודה אחד מייצג.
אנחנו רושמים כל Zap או תרחיש, עם הטריגר, האפליקציות, השלבים, בעל ההרשאות והשימוש בפועל, ומסמנים תהליכים שאינם בשימוש, כפילויות ותהליכים קריטיים.
אנחנו מתכננים כל תהליך מחדש לפי הדרך שבה n8n עובד, עם עיבוד טבעי של רשימות פריטים, במקום להעתיק אותו שלב אחר שלב. אפליקציות בלי צומת ייעודי מתחברות דרך צומת HTTP Request.
כל תהליך חדש רץ במקביל למקור, מול יעדי בדיקה. כשהתוצאות תואמות, אנחנו מעבירים את כתובות ה-webhook ומשהים את המקורי, ושומרים אותו כגיבוי.
לא הכול מתאים אחד לאחד. אלה ההתאמות שמופיעות הכי הרבה.
התהליכים רצים על שרת שאתם משלמים עליו, n8n Cloud או VPS משלכם, והוא כלול בהצעת המחיר מהיום הראשון.
בוחרים יחד את התהליך בעל השימוש הגבוה או הקריטי ביותר, ובונים אותו מחדש ב-n8n. במהלך הניסיון הוא רץ לצד המקורי, ואנחנו משווים את התוצאות הרצה אחר הרצה. אם הוא עומד במבחן, ממשיכים לשאר המלאי. ההיקף, התאריכים והתנאים נכתבים לפני שמתחילים.
לא. תהליכי העבודה המקוריים נשארים פעילים בזמן שאנחנו בונים ובודקים את החדשים. ההחלפה מתבצעת כשהתוצאות תואמות: כתובות ה-webhook מתעדכנות, וה-Zap או התרחיש הישן מושהה ולא נמחק, למקרה שתצטרכו לחזור אחורה בהרצות הראשונות.
זה תלוי בשימוש שלכם, ולכן איננו מציעים מספר מראש. Zapier סופר משימה על כל פעולה שהושלמה, ו-Make גובה לפי המודולים שהוא צורך. n8n Cloud סופר הרצות מלאות של תהליכי עבודה, ואם אתם מריצים את גרסת הקהילה על VPS משלכם, משלמים על השרת ולא לפי הרצה. המלאי משווה בין האפשרויות לפי הנתונים שלכם.
ההרשאות לא ניתנות לייצוא: כל חיבור מאושר מחדש ב-n8n, ואנחנו משתמשים בשלב הזה כדי להעביר אותו לחשבון של החברה ולא לחשבון של עובד. היסטוריית ההרצות גם היא אינה עוברת. אם אתם צריכים אותה, נבדוק לפני ההחלפה מה התוכנית שלכם מאפשרת לייצא.
אם לאפליקציה יש API ציבורי, נחבר אותה דרך צומת HTTP Request או צומת קהילתי שנבדק. אם היא עובדת ב-Zapier או ב-Make רק דרך אינטגרציה פרטית, נסמן זאת במלאי ונחפש פתרון אחר: ייצוא, אפליקציה אחרת, או השארת התהליך במקומו.
ספרו לנו באיזו פלטפורמה אתם משתמשים ואילו תהליכים מטרידים אתכם, ונשלח הצעה בכתב לניסיון של 7 ימים, עם תהליך אחד שמועבר ונבדק לצד המקור.