סנכרון monday.com עם פריוריטי: איפה זה באמת נשבר

הצירוף הזה נפוץ מאוד בישראל: צוות המכירות עובד ב-monday.com, התפעול והכספים יושבים בפריוריטי, ומישהו מבקש "שהמערכות ידברו". הבקשה נשמעת פשוטה. היא נכשלת כמעט תמיד באותו מקום, ומסיבה אחת שאפשר להימנע ממנה בהחלטה אחת בתחילת הדרך.

המדריך מניח היכרות עם ה-API של monday.com ועם ה-API של פריוריטי.

הטעות: "שהמערכות יסתנכרנו"

הבקשה הטבעית היא סנכרון דו-כיווני: שינוי ב-monday יתעדכן בפריוריטי, ושינוי בפריוריטי יתעדכן ב-monday. זה נשמע סימטרי ונכון, וזה מייצר שלוש בעיות שאין להן פתרון נקי:

1. קונפליקטים. אם שני הצדדים עדכנו את אותו שדה בין שתי הרצות סנכרון - מי מנצח? כל תשובה שתיתן תהיה שגויה במקרים מסוימים.
2. לולאות. עדכון בפריוריטי מפעיל סנכרון ל-monday, שמפעיל webhook, שמפעיל סנכרון חזרה. צריך מנגנון שמזהה "זה שינוי שאני עצמי גרמתי לו", וזה קוד עדין שנשבר בשקט.
3. אמון. ברגע שהמשתמשים לא יודעים איזו מערכת צודקת, הם מפסיקים לסמוך על שתיהן ומתחילים לנהל אקסל בצד. זה הכישלון האמיתי.

הפתרון: נקודת מסירה אחת

במקום לסנכרן, יש להגדיר נקודת מסירה - רגע אחד שבו הבעלות עוברת ממערכת למערכת. ברוב העסקים זה הרגע שבו עסקה נסגרת.

המפתח הוא השורה האחרונה: מה שחוזר מפריוריטי ל-monday הוא לקריאה בלבד. עמודות סטטוס שאיש המכירות רואה אבל לא יכול לערוך. ברגע שהן לקריאה בלבד, אין קונפליקט, אין לולאה, ואין ויכוח מי צודק.

מבחינה מעשית: לנעול את העמודות האלה בלוח, או לפחות לתת להן שם שמסמן את זה - למשל תחילית קבועה. עמודה שנראית עריכה תיערך.

הבעיה שגוזלת הכי הרבה זמן: זהות

לשתי המערכות מודל זהות שלא מתיישב:

• ב-monday ליד הוא פריט בלוח. הוא מזוהה בשם שאיש המכירות הקליד. אין אילוץ ייחודיות. "חברת ישראל בע\"מ", "ישראל בעמ" ו"Israel Ltd" הם שלושה פריטים.
• בפריוריטי לקוח הוא כרטיס עם מספר, לרוב עם ח\"פ, ועם אילוצים אמיתיים.

המסקנה: צריך טבלת מיפוי מפורשת - שורה שקושרת מזהה פריט ב-monday למספר לקוח בפריוריטי. לא להסתמך על התאמת שמות, לא על מייל, לא על היוריסטיקה.

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

אם יש ח\"פ בשני הצדדים - זה המפתח הטוב ביותר, וכדאי להפוך אותו לשדה חובה בלוח לפני שמתחילים.

המלכודת הטכנית: תקציב המורכבות של monday

הדפוס הנאיבי הוא לרוץ כל כמה דקות על כל הלוחות, לשלוף את כל הפריטים עם כל ערכי העמודות, ולהשוות. ב-monday זה מת מהר.

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

שלוש הנחיות:

• לסנן לפי לוח וסטטוס. לשלוף רק פריטים בסטטוס "נסגר" שטרם סונכרנו, לא את כל הלוח.
• לבקש רק את השדות שצריך. זה גם מה שקובע כמה נקודות תשלם.
• למדוד לפני שמרחיבים. להוסיף את שדה complexity לשאילתה, להריץ על לוח קטן ולהכפיל בגודל הצפוי. זה ההבדל בין סנכרון שמחזיק לבין אחד שנופל ביום שהלקוח מוסיף 5,000 פריטים.

מהצד השני, בפריוריטי, המגבלה שונה: אצווה מוגבלת ל-100 בקשות בקריאה אחת. אם כתבת ייבוא שמסתמך על 1,000 - זו הייתה המגבלה לפני גרסה 21.0, והיא כבר לא.

טריגרים: מה מפעיל את הסנכרון

ל-monday יש webhooks, ולפריוריטי יש webhooks דרך כללי BPM. בשני המקרים כדאי להשתמש בהם - אבל לא לסמוך עליהם כמנגנון היחיד:

• webhook של monday נורה על שינוי בלוח, אבל שינוי סטטוס דרך אוטומציה פנימית לא תמיד מתנהג כמו שינוי ידני. יש לבדוק את זה בפועל בלוח האמיתי, לא להניח.
• לwebhooks של פריוריטי אין מדיניות retry מתועדת, ויומן השגיאות נשמר 7 ימים בלבד.

לכן: תהליך התאמה יומי הוא חובה. לרוץ פעם ביום, לשלוף מ-monday את כל מה שנסגר ב-48 השעות האחרונות, ולוודא שיש לו מקבילה בפריוריטי. זה מה שיתפוס את מה שהאירועים החמיצו, וזה גם מה שיאפשר לך לישון.

מתי בכלל לא לבנות את זה

שווה לשאול לפני שמתחילים: כמה עסקאות נסגרות בחודש? אם התשובה היא עשרים, הקלדה ידנית של עשרים לקוחות בפריוריטי עולה פחות מהפיתוח, מהתחזוקה ומהבאגים - ובעיקר, היא לא מייצרת כפילויות שקטות.

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