01 מי מריץ את הצמד הזה
Priority זה ה-ERP: הזמנות, מלאי, תמחור, חשבוניות, כרטיס לקוח מלא. HubSpot זה ה-CRM: פייפליין מכירות, אנשי קשר, הצעות מחיר, אוטומציית שיווק. בחברות תעשייה, יבוא והפצה בישראל זה הצמד הכי נפוץ שרואים: Priority כבר רץ שנים, HubSpot נכנס כשצוות המכירות גדל ומנהל המכירות מבקש פייפליין שאפשר לראות בו משהו.
הבעיה הרגילה: אנשי מכירות עובדים ב-HubSpot ובונים הצעות מחיר על סמך קטלוג ישן, כי אף אחד לא טרח לחבר את שני העולמות. המחירים מתעדכנים ב-Priority והצוות בשטח לא יודע.
02 חמש זרימות שכדאי לסנכרן
לא צריך לחבר הכל. ברוב המקרים חמש הזרימות האלה מכסות את רוב הכאב:
- פריטים ומחירים מ-Priority אל HubSpot: קטלוג המוצרים והמחירונים מסונכרנים לתוך Products ב-HubSpot, כך שהצעת מחיר שנבנית ב-CRM משתמשת במחיר האמיתי, לא בגיליון אקסל שמישהו שמר לפני חצי שנה
- זמינות מלאי כשדה על ה-Deal: כשנציג מכירות בונה עסקה, הוא רואה אם הפריט במלאי, בהזמנה, או אזל, לפני שהוא מבטיח ללקוח תאריך אספקה
- Deal שנסגר ב-HubSpot יוצר הזמנת לקוח ב-Priority: ברגע ש-Deal עובר ל-Closed Won, נפתחת הזמנה ב-Priority עם פרטי הלקוח, הפריטים והכמויות מההצעה שאושרה
- סטטוס הזמנה חוזר מ-Priority ל-HubSpot: אספקה חלקית, עיכוב, סגירה, מוצג כשדה על ה-Deal או כ-Ticket, כדי שהמכירות לא ישאלו את הלקוח שאלות שהם צריכים לדעת בעצמם
- היסטוריית רכש כמידע על ה-Company ב-HubSpot: מה הלקוח קנה, כמה פעמים, באיזה היקף, כדי שמכירות חוזרות ו-upsell יתבססו על נתונים אמיתיים ולא על זיכרון של איש המכירות
03 איך זה נבנה בפועל
Priority חושף API מבוסס REST/OData שמאפשר קריאה וכתיבה של רשומות: לקוחות, פריטים, הזמנות, מחירונים. HubSpot חושף API לאובייקטים סטנדרטיים (Deals, Contacts, Companies, Products) וגם Custom Objects כשצריך למדל משהו שלא קיים כברירת מחדל, כמו רמת מלאי בזמן אמת.
כיוון הסנכרון קובע איזו מערכת 'בעלים' על כל שדה. מחיר ומלאי: Priority בעלים, HubSpot קורא בלבד. שלב פייפליין ופרטי איש קשר: HubSpot בעלים. זה נשמע מובן מאליו אבל זו בדיוק הנקודה שרוב הפרויקטים נתקעים בה: מי מנצח כשהשדות סותרים.
תזמון: קטלוג ומחירים בדרך כלל מספיק לסנכרן פעם בלילה, הם לא משתנים כל דקה. יצירת הזמנה מ-Deal שנסגר צריכה להיות event-driven, כי הלקוח מחכה. מיפוי שדות צריך טבלה כתובה: כל שדה ב-Priority מול השדה המקביל ב-HubSpot, כולל מה קורה כשאחד מהם ריק.
נקודות שדורשות אישור אנושי לפני שהאוטומציה ממשיכה: יצירת לקוח חדש (למניעת כפילויות), כל הזמנה מעל סכום סף, וכל מקרה שבו המחיר שהוזן ב-HubSpot שונה מהמחיר ב-Priority. כסף לא זז לבד.
04 מה בדרך כלל משתבש
אלה התקלות שחוזרות על עצמן בכל פרויקט כזה:
- כפילויות לקוחות: אותו לקוח נוצר פעמיים כי החיפוש התבסס על שם ולא על ח.פ או מזהה קבוע, צריך כלל התאמה נוקשה, לא fuzzy matching
- קטלוג לא מעודכן: אם הסנכרון רץ פעם ביום, מכירות בשעות הבוקר עדיין רואות מחיר אתמול, צריך להחליט אם זה מקובל או שצריך event-driven
- שדות מע״מ ומטבע: הצעת מחיר ב-HubSpot לפעמים לא כוללת מע״מ, ההזמנה ב-Priority כן, אם המיפוי לא מטפל בזה מפורשות, הסכום שמגיע להזמנה שגוי
- קידוד עברית בשדות טקסט חופשי: שמות פריטים או הערות עם תווים מיוחדים נשברים כשהם עוברים דרך middleware שלא מוגדר נכון ל-UTF-8
- סנכרון דו-כיווני בלי כללי קונפליקט: אם שני הצדדים יכולים לערוך את אותו שדה, בלי כלל ברור מי מנצח, מקבלים לולאת עדכונים אינסופית או נתונים שדורסים אחד את השני
05 מה בדרך כלל משתבש (וכדאי לדעת מראש)
- התיאור מתאר דפוסי אינטגרציה ולא שמות שדות או endpoints מדויקים, אלה תלויי גרסת Priority ותצורת ה-tenant ונבדקים בפועל בשלב האפיון.
- Priority דורש הרשאות API שמנוהלות אצל ה-VAR או צוות ה-IT הפנימי; זה שלב תיאום שצריך זמן, לא רק עבודת פיתוח.
- סנכרון דו-כיווני אמיתי (לא רק קריאה) מוסיף מורכבות משמעותית בכללי קונפליקט. אם אפשר להסתפק בכיוון אחד, זה מוזיל את הבנייה משמעותית.
לפני שבונים את הסנכרון, ננתח מה באמת חוזר על עצמו
שיחת היכרות של 20 דקות. אם יש תשתית מסודרת, יוצאים משם עם רשימת זרימות מדורגת לפי החזר. אם צריך קודם לסדר תהליך ידני, סורק התפעול (₪4,900, שבועיים) מסתיים באוטומציה עובדת אחת, והעלות שלו יורדת במלואה מהספרינט אם ממשיכים תוך 60 יום.
לתיאום סריקת תפעול