איך מחברים HubSpot ל-Priority? מתחילים מהמיפוי, לא מהטכנולוגיה. עוד לפני שבוחרים connector או שכבת אינטגרציה, מגדירים בכתב אילו אובייקטים עוברים בין המערכות - לקוחות ואנשי קשר, מוצרים, הזמנות, חשבוניות - לאיזה כיוון כל אחד מהם זורם, ומי מקור האמת לכל שדה. ברוב החברות החלוקה הנכונה פשוטה: HubSpot מנהל את תהליך המכירה ואת הקשר עם הלקוח, ו-Priority מנהלת את הכסף - הזמנות, חשבוניות ותשלומים. IV-LEAD, שותפת HubSpot ברמת Gold, בונה חיבורים כאלה לחברות B2B ישראליות, וזה המדריך שמראה איך עושים את זה בלי לשבור את הדוחות של אף אחד.
חמישה אובייקטים מכסים כמעט כל פרויקט. לכל אחד מהם קובעים מראש איפה הוא נולד, לאן הוא מסתנכרן, ומה קורה כשהוא משתנה:
| אובייקט | ב-HubSpot | ב-Priority | כיוון מומלץ | מקור האמת |
|---|---|---|---|---|
| לקוחות ואנשי קשר | Company + Contact | כרטיס לקוח | דו-כיווני, עם חוקי conflict | לפי שדה: קשר ושיווק ב-HubSpot, נתונים פיננסיים ב-Priority |
| מוצרים ומחירונים | Products | פריטים ומחירונים | מ-Priority ל-HubSpot | Priority |
| הזמנות | Deal או custom object | הזמנות מכירה | מ-Priority ל-HubSpot | Priority |
| חשבוניות | custom object | חשבוניות | מ-Priority ל-HubSpot | Priority |
| סטטוס עסקה | Deal stage | סטטוס הזמנה | לפי התהליך שלכם | מוגדר מראש, לא ״גם וגם״ |
שימו לב להבחנה שהכי הרבה פרויקטים מפספסים: העסקה (deal) ב-HubSpot היא לא ההזמנה ב-Priority. העסקה היא תמונת המכירה - סכום צפוי, שלב, בעלים - וההזמנה היא המסמך המחייב שנפתח אחרי החתימה. כשמנסים להפוך אותן לאותה רשומה, כל שינוי בהזמנה דורס את היסטוריית המכירה, והדוחות משני הצדדים מפסיקים להסתדר.
ההחלטה לא מתקבלת ברמת המערכת אלא ברמת השדה, ותמיד בכתב. הכלל שעובד כמעט תמיד: Priority היא הבעלים של האמת הפיננסית - פריטים, מחירים, הזמנות, חשבוניות ותשלומים - ו-HubSpot הוא הבעלים של אמת הקשר והמכירה: אנשי קשר, פעילות, משפך המכירות והתקשורת עם הלקוח. לכל שדה שעובר בין המערכות מגדירים בעלים אחד, כיוון סנכרון, ומה קורה כששני הצדדים השתנו באותו יום.
התוצר של השלב הזה הוא מסמך מיפוי שדות - טבלה אחת שכולם חתומים עליה עוד לפני שנכתבה שורת קוד. אצלנו זה כלל עבודה: בלי מסמך מיפוי, אין פרויקט. המדריך המלא באנגלית לכתיבת מסמך אפיון כזה נמצא כאן.
כפילויות הן הדרך המהירה ביותר להרוס את האמון בחיבור, ולכן מטפלים בהן לפני ההפעלה הראשונה, לא אחרי. שלושה מהלכים עושים את רוב העבודה: קובעים מזהה משותף - מספר הלקוח ב-Priority נשמר כשדה ייעודי בכל רשומת Company ב-HubSpot, כך שלכל לקוח יש עוגן אחד בשתי המערכות; מגדירים חוקי התאמה לרשומות שקיימות רק בצד אחד (לפי ח״פ או דומיין, לא לפי שם חופשי); ומריצים איחוד כפילויות בשתי המערכות לפני הסנכרון הראשון. מעבר לזה נשאר רק כלל ארגוני אחד - מי מוסמך לפתוח לקוח חדש ובאיזו מערכת - כדי שהבעיה לא תיוולד מחדש כל שבוע.
כי מסמכים פיננסיים נולדים במערכת שהכספים חיים בה, וכל ניסיון לייצר אותם מהצד של השיווק והמכירות מסתיים בהתאמות ידניות מול רואה החשבון. הכיוון הנכון ברוב הפרויקטים: ההזמנה והחשבונית נפתחות ב-Priority, ועותק מעודכן שלהן - סכום, סטטוס, תאריך - מסתנכרן אל רשומת הלקוח והעסקה ב-HubSpot. כך אנשי המכירות רואים אם החשבונית שולמה בלי לבקש הרשאות ל-Priority, ההנהלה רואה הכנסות אמיתיות ליד משפך המכירות, ואף אחד לא מקליד את אותו מסמך פעמיים.
סנכרונים נופלים בשקט - זה הטבע שלהם - ולכן מתכננים את הכישלון מראש. ארבעה רכיבים הופכים חיבור שביר למערכת שאפשר לסמוך עליה: מנגנון retry שמנסה שוב אוטומטית אחרי כשל זמני; תור שגיאות שאליו נופלות רשומות שלא הצליחו לעבור, במקום להיעלם; התראה אמיתית לבן אדם - לא שורה בלוג שאף אחד לא קורא - כשמשהו נכשל שוב ושוב; ודוח reconciliation קבוע שמשווה אחת לתקופה ספירות וסכומים בין המערכות, כדי לתפוס סטיות שקטות לפני שהן מגיעות לדוח הרבעוני. חשוב באותה מידה: כשל של רשומה אחת צריך לעצור את הרשומה, לא את כל הריצה.
אין connector native בין HubSpot ל-Priority, אז הבחירה היא בין שלושה מסלולים. שכבת אינטגרציה ייעודית כמו Engini היא המסלול הנפוץ בפרויקטים ישראליים, ומה שאנחנו עובדים איתו ברוב המקרים - היא כבר מכירה את האובייקטים של Priority ומביאה איתה retry וניטור מובנים. כלי iPaaS כללי כמו Make, או Zapier, מתאימים לפעולות פשוטות וחד-כיווניות - למשל פתיחת ליד - אבל הם לא תחליף לסנכרון דו-כיווני מלא עם חוקי conflict. ופיתוח API בהתאמה אישית שמור למקרים עם היקף או לוגיקה חריגים. העיקרון החשוב: את המסלול בוחרים אחרי שהמיפוי סגור, כי המיפוי הוא שקובע מה המסלול צריך לדעת לעשות - לא להפך. סקירה רחבה יותר של מי מחבר HubSpot ל-Priority או SAP B1 בישראל נמצאת כאן.
מי שנוקב במחיר לפני שראה את מודל הנתונים שלכם - מנחש. מה שבאמת קובע את ההיקף: כמה אובייקטים מסתנכרנים ובכמה כיוונים, כמה נקייה הדאטה (כפילויות היסטוריות הן כמעט תמיד המשימה הארוכה, לא הצנרת), וכמה מקרים חריגים יש בתהליך שלכם. פרויקט בריא מתחיל באפיון ומיפוי, עובר דרך הרצה ב-sandbox עם השוואת נתונים, ורק אז עולה מדורג לסביבה החיה - ולא בכיוון ההפוך.
כמעט תמיד כי שתי המערכות מתארות שני דברים שונים: העסקה היא תחזית המכירה, וההזמנה היא המסמך שאושר בפועל - אחרי הנחות, שינויי כמויות ותוספות. הפתרון הוא לא ליישר ידנית אלא להגדיר סנכרון של סכום ההזמנה בחזרה אל שדה ייעודי בעסקה, כך שרואים את שניהם זה לצד זה.
שלושת החשודים הקבועים: המזהה המשותף חסר או לא תואם, כך שלחשבונית אין רשומת לקוח להיקשר אליה; החשבונית נפלה לתור השגיאות ואף אחד לא הסתכל שם; או שהחיבור סונכרן רק קדימה ואף אחד לא הגדיר את הזרימה חזרה. בודקים קודם את תור השגיאות - ברוב המקרים התשובה כבר שם.
כן. העקרונות זהים - מיפוי אובייקטים, מקור אמת אחד לכל שדה, כיוון לכל אובייקט - אבל השדות והאובייקטים של SAP B1 שונים, ולכן הוא מקבל מסמך מיפוי משלו ולא העתקה של מיפוי Priority.
ארבעה אנשים, לא עשרים: בעלים עסקי שמכריע במחלוקות על מקור האמת, נציג כספים שמכיר את Priority מבפנים, מי שמנהל אצלכם את HubSpot, ואיש הקשר לספק ה-Priority שלכם כשנדרשים שינויים בצד ההוא.
לזה בדיוק נקבעים חוקי conflict מראש: לכל שדה מוגדר מי הבעלים, והמערכת הבעלים מנצחת. בלי הכלל הזה הסנכרון הדו-כיווני הופך למלחמת דריסות שקטה ששני הצדדים מפסידים בה.
גוף שמכיר לעומק את שני הצדדים - את מודל הנתונים של HubSpot ואת עולם ההזמנות והחשבוניות של Priority - ויודע להציג מסמך מיפוי לפני שהוא מציג הצעת מחיר. IV-LEAD מתכננת ומפעילה חיבורים כאלה לחברות B2B ישראליות, ולשינויים בצד Priority עובדים לצד ספק ה-Priority הקיים שלכם.
שותפת HubSpot ברמת Gold · דירוג 5.0 ב-HubSpot Solutions Directory · 30 הסמכות HubSpot · מעל 25 אינטגרציות חיות בפורטלים של לקוחות · עובדים עם חברות B2B ישראליות מ-2016 · Priority עצמה הפנתה אלינו לקוחות כשהאינטגרציה הצריכה עבודה רצינית. את כל התהליך - מהאפיון, דרך בניית האינטגרציה, ועד הניטור אחרי העלייה לאוויר - מוביל צוות אחד, דו-לשוני.