ACHIYA שתי מערכות CRM. גרסת אמת אחת — בלי הזנה כפולה.
מקרה מבחן מאת אחיה כהן, מייסד אחיה אוטומציה
צוות אחד עובד ב-Monday, צוות אחר ב-Affinity — והנתונים חייבים להישאר זהים. מערכת סנכרון ב-Make עם לוגיקה עסקית אמיתית: לא רק מעתיקה שינויים, אלא בודקת את כל הבורדים, מאמתת תנאים ומעדכנת רק כשבאמת צריך.
- 3ענפים מקבילים בתרחיש המרכזי
- ↔סנכרון דו-כיווני
- לוגעדכונים וחריגים
שתי מערכות = שתי גרסאות אמת מערכת אחת, סנכרון דו-כיווני
לפני
- צוות מעדכן ב-Monday, צוות אחר ב-Affinity
- הזנה כפולה יוצרת עבודה חוזרת
- כל מערכת אמת אחרת — שגיאות, ויכוחים
- אין דרך לדעת מה הסטטוס האמיתי
אחרי
- שינוי ב-Monday מפעיל עדכון ב-Affinity לפי כללים
- שינוי ב-Affinity מפעיל עדכון ב-Monday לפי כללים
- לוגיקה עסקית מטפלת בקונפליקטים
- לוגים וחריגים מאפשרים לבדוק פערים בין המערכות
ככה זה נראה מבפנים
תיאור של כל פלואו, בלי פרטים מזהים.
חברה עוברת קבוצה במנדיי ← בדיקות ← עדכון באפיניטי
התרחיש המרכזי, בשלושה ענפים מקבילים. כשחברה מועברת לקבוצה אחרת ב-Monday, המערכת לא ממהרת לעדכן: היא בודקת את מצב החברה בכל שאר הבורדים, מפעילה את כללי העסק (כולל תנאים מיוחדים שאסור לדרוס), ורק אז מעדכנת את הרשומה ב-Affinity — כולל שליחת מייל אוטומטי כשצריך.
Monday webhookMulti-board checksBusiness rulesAffinity API
שינוי סטטוס ← משיכת נתונים ← סנכרון
כשסטטוס חברה משתנה ב-Monday לשלב חדש, התרחיש מושך את פרטי החברה, אורז אותם במבנה הנכון ומעדכן את השדות המתאימים ב-Affinity. כללי התרחיש קובעים אילו שדות יעודכנו ואילו חריגים דורשים בדיקה.
Monday triggerJSON transformArray aggregationAffinity update
המספרים שמרגישים ביום-יום
- ↔עדכון דו-כיוונישינויים עוברים בין המערכות לפי כללי הסנכרון
- בדיקהתנאים לפני עדכוןהלוגיקה בודקת את הבורדים לפני שינוי
- לוגבקרת חריגיםהעדכונים נשמרים כדי לאפשר איתור פערים
גם אצלכם שתי מערכות שלא מדברות?
CRM, ERP או גיליונות — אם הצוות מעתיק נתונים בין מערכות, אפשר לבנות סנכרון עם כללים, לוגים וטיפול בחריגים.
רוצים מערכת כזו אצלכם? עיינו בשירות בניית בוט הוואטסאפ או במחירים ומסלולים.
בואו נדבר
טלפון, וואטסאפ, או טופס — מה שנוח לך