אינטגרציות API ואוטומציה בין מערכות
כשכל מערכת מחזיקה גרסה משלה של הלקוח, מישהו בצוות הופך לכבל שמעתיק נתונים ביניהן. זה איטי, וכל העתקה היא הזדמנות לטעות. אנחנו מחברים את המערכות דרך API, קובעים איזו מערכת אחראית על כל נתון, ובונים את החיבור כך שרואים מתי משהו נכשל.
מתי צריך אינטגרציה, ומתי שירות אחר
אינטגרציה מעבירה נתונים בין שתי מערכות או יותר: לקוח שנוצר בחנות מופיע ב־CRM, הזמנה שעודכנה במערכת אחת מתעדכנת בשנייה, או ממשק חדש שקורא וכותב למערכת קיימת. זה התחום של העמוד הזה.
אם כל מה שצריך הוא שטפסי האתר ייכנסו ל־CRM, זה חיבור האתר למערכת CRM, פרויקט קטן וממוקד יותר. אם הנתונים כבר במקום אחד וצריך כללים כמו ״כשנכנסת פנייה, שלח אישור ופתח תזכורת״, זו אוטומציה של תהליכי עבודה בתוך המערכת. אם צריך להעביר היסטוריה ממערכת ישנה פעם אחת, זה מעבר CRM. ואם הקלט הוא טקסט חופשי שצריך להבין, זה שילוב AI.
קודם מחליטים מי מקור האמת
הטעות הנפוצה בחיבור בין מערכות היא לסנכרן הכול לכל הכיוונים. אחרי כמה שבועות כבר לא ברור איזה מחיר נכון, ואיזו כתובת עדכנית. לכן לפני שכותבים שורת קוד אחת, קובעים לכל נתון מערכת אחת שאחראית עליו.
דוגמה מ־Hot House
באפיון של Hot House קבענו שהחנות ב־WooCommerce אחראית על מוצרים, מחירים, מלאי, תשלום וסטטוס הזמנה. GoHighLevel אחראית על כרטיס הלקוח, השיחות, הזמנות העבודה ומכירות הייעוץ. החיבור מעביר אירועים מהחנות ל־CRM, אבל אף אחד לא עורך מוצרים מתוך ה־CRM. לקוח מהחנות מזוהה מול איש הקשר לפי טלפון או מייל, והמזהים של שתי המערכות נשמרים זה לצד זה.
כיוון הסנכרון
לכל חיבור מגדירים כיוון: חד־כיווני, דו־כיווני, או קריאה בלבד. ברירת המחדל שלנו היא הכיוון המצומצם ביותר שעושה את העבודה, כי כל הרשאת כתיבה נוספת היא עוד מקום שבו משהו יכול להשתבש.
Meduza Ops: ממשק משלכם מעל GoHighLevel
לפעמים הבעיה היא לא שהמערכות לא מדברות, אלא שהממשק של ה־CRM מורכב מדי לצוות. ב־Hot House בנינו את Meduza Ops: פאנל תפעול בעברית לעובדי המשרד, עם הרשאות לפי תפקיד, חיפוש מהיר וקליטת פניות ישירה מטפסי האתר. הפאנל רץ על Railway עם בסיס נתונים PostgreSQL, ומסונכרן ל־GoHighLevel דרך ה־API שלה.
שני דברים למדנו שם ואנחנו מיישמים בכל אינטגרציה. הראשון: ל־API של GoHighLevel יש מגבלות קצב, ולכן תהליכים ארוכים נבנים כך שאפשר לעצור אותם ולהמשיך מאותה נקודה. השני: לא כל פעולה שנראית פשוטה בממשק אפשרית דרך ה־API, וכדאי לגלות את זה בבדיקת היתכנות ולא באמצע הפיתוח.
אנחנו בונים גם מערכות משלנו. Meduza OS, מערכת הניהול הפנימית של הסוכנות, נכתבת ב־Next.js, NestJS ו־PostgreSQL ונמצאת בפיתוח. כשצריך מערכת שלמה ולא חיבור בין מערכות, זה פיתוח מערכות ויישומי Web.
למי זה מתאים ולמי לא
מתאים אם
- עסק שעובד עם כמה מערכות (אתר, חנות, CRM, מערכת פנימית) שמחזיקות את אותו לקוח בגרסאות שונות.
- צוות שמעתיק נתונים ידנית בין מערכות כל יום.
- עסק שה־CRM שלו חזק אבל הממשק מסורבל לעובדים, וצריך מעליו ממשק פשוט בעברית.
- עסק שרוצה דשבורד אחד שמושך נתונים מכמה מקורות.
פחות מתאים אם
- עסק עם מערכת אחת בלבד. שם בדרך כלל מספיקה אוטומציה בתוך המערכת.
- מי שצריך רק לחבר טופס ל־CRM. זה חיבור אתר ל־CRM, פשוט וזול יותר.
- מי שמחפש פיתוח מערכת חדשה מאפס. זה פרויקט פיתוח מערכת נפרד.
מה מקבלים
- מיפוי של המערכות, הנתונים בכל אחת והאנשים שמשתמשים בהן.
- טבלת מקור אמת: איזו מערכת אחראית על כל נתון.
- הגדרת כיוון הסנכרון והתדירות לכל חיבור.
- פיתוח החיבור דרך API ו־Webhooks. כשאין Webhook זמין, סנכרון תקופתי שבודק שינויים.
- הרשאות מינימליות: לחיבור יש גישה רק למה שהוא צריך.
- תיעוד לכל פעולה, כך שאפשר לבדוק מה עבר ומתי.
- טיפול בכשלים: עצירה כשמערכת מסרבת לבקשה או חוסמת אותה, ואפשרות להמשיך מנקודה ידועה.
- מתגים לכיבוי כתיבה, כדי שאפשר לעצור פעולה בלי לעצור את כל המערכת.
- תיעוד קצר של החיבור, למי שיעבוד עליו אחרינו.
יש לכם שתי מערכות שמחזיקות את אותו לקוח, ומישהו מעתיק ביניהן כל יום? ספרו לנו אילו מערכות, ונבדוק מה אפשר לחבר.
בדיקת היתכנות לחיבוראיך עובדים
- אפיון ממפים את המערכות, את הנתונים ואת התהליך. מכם אנחנו צריכים גישה למערכות, ומישהו שמכיר את העבודה היומיומית.
- בדיקת היתכנות בודקים מול ה־API של כל מערכת מה באמת אפשרי: אילו נתונים אפשר לקרוא, מה אפשר לכתוב, ואילו מגבלות יש. מכאן יוצאת תכנית בכתב.
- פיתוח בסביבת בדיקה בונים ובודקים מול נתוני בדיקה, לא מול הלקוחות האמיתיים שלכם.
- הפעלה הדרגתית מתחילים בקריאה בלבד, ומפעילים כתיבה רק אחרי שבדיקה על קבוצה קטנה עברה. כך הפעלנו את Meduza Ops ב־Hot House.
- אחרי ההשקה מערכות משתנות, וגם ה־API שלהן. תחזוקה נעשית בהיקף מוגדר מראש. רישיונות של המערכות ועלויות שימוש ב־API משולמים בנפרד.
כלי חיבור מוכן או פיתוח ייעודי
כלים כמו Zapier או Make מתאימים להרבה חיבורים. פיתוח ייעודי מתאים כשהלוגיקה מורכבת או כשצריך ממשק משלכם.
| כלי חיבור מוכן | פיתוח ייעודי | |
|---|---|---|
| זמן עד שזה עובד | קצר | ארוך יותר |
| לוגיקה מורכבת וזיהוי כפילויות | אפשרי עד גבול מסוים | ללא מגבלה מעשית |
| ממשק משתמש משלכם | לא | כן, כמו Meduza Ops |
| עלות שוטפת | מנוי לכלי, שעולה עם כמות הפעולות | שרת ותחזוקה |
| שליטה בנתונים | עוברים דרך צד שלישי | עוברים בשרת שנבחר לפרויקט |
איפה זה יושב בתמונה הגדולה
אינטגרציה היא בדרך כלל השלב השני. קודם יש CRM על GoHighLevel או מערכת אחרת שעובדת, ואז מחברים אליה את שאר המערכות. את כל השירותים בתחום, מהקמה ועד AI, אפשר לראות בעמוד CRM, אוטומציה ו־AI.
שאלות נפוצות
מה ההבדל בין API לאוטומציה?
API מחבר מערכות ומעביר ביניהן נתונים. אוטומציה מגדירה מה קורה ומתי, בתוך מערכת אחת או אחרי שהנתונים הגיעו. הרבה פרויקטים צריכים את שניהם.
ומה אם למערכת שלנו אין API?
בודקים אפשרויות אחרות: ייצוא קבצים קבוע, ייבוא מתוזמן או Webhooks. אם אין דרך יציבה לחבר, נגיד את זה לפני שמתחילים.
החיבור יכול לפגוע בנתונים הקיימים?
לכן מתחילים בקריאה בלבד, עם הרשאות מינימליות ותיעוד לכל פעולה. כתיבה מופעלת רק אחרי בדיקה על קבוצה קטנה.
מה קורה כשאחת המערכות מתעדכנת ומשנה את ה־API?
החיבור צריך תחזוקה. אנחנו מגדירים מראש היקף תחזוקה, והתיעוד לכל פעולה עוזר לגלות מהר מה השתנה.
יש עלויות מעבר לפיתוח?
כן. רישיונות של המערכות, שימוש ב־API ושרת, אם צריך, משולמים בנפרד. נפרט אותם בהצעה.
אתם בונים גם מערכת שלמה?
כן, אבל זה שירות אחר: פיתוח מערכות ויישומי Web. כאן מחברים בין מערכות קיימות או בונים ממשק מעליהן.
ספרו לנו אילו מערכות צריכות לדבר
כתבו לנו אילו מערכות יש לכם, מה מועתק ביניהן ידנית ומי עושה את זה. נחזור עם בדיקת היתכנות ותכנית בכתב.
ספרו לנו על המערכות שלכם