בעת מעבר מ-RetailCRM ל-Bitrix24, הקושי העיקרי הוא מודל הנתונים השונה: RetailCRM ממוקד בהזמנות, בעוד ש-Bitrix24 ממוקד בעסקאות. ללא מיפוי קפדני, סטטוסים, היסטוריית תשלומים ונתוני לקוחות הולכים לאיבוד.
נתקלנו בפרויקטים שבהם, עקב מיפוי סטטוסים שגוי, 30% מהעסקאות הגיעו לשלבים הלא נכונים, והיסטוריית הנאמנות אבדה. הצוות שלנו ביצע יותר מ-50 מעברים במשך 6 שנים, ואנחנו יודעים כיצד להימנע מהמלכודות הללו.
אנו משתמשים ב-RetailCRM API v5 לייצוא וב-Bitrix24 REST API לכתיבה. עבור נפחים גדולים, אנו מבצעים במקביל בקשות עם מגבלה של 5 RPS, מה שמאפשר עיבוד של עד 50,000 הזמנות ביום. מעבר דרך הצינור האוטומטי שלנו מהיר פי 3 מהעברה ידנית דרך Excel.
מדוע מיפוי נכון הוא הבסיס להגירה מ-RetailCRM ל-Bitrix24?
RetailCRM שומר סטטוסים במבנה רב-רמתי עם קבוצות, בעוד Bitrix24 משתמש בשלבי עסקה שטוחים. ללא מיפוי, "מבוטל" יכול להפוך ל"הצלחה", ו"בתהליך" יכול להפוך ל"אבוד".
אנו מתאימים סטטוסים אוטומטית באמצעות StatusMapper, שלוקח בחשבון את ההיגיון העסקי: לדוגמה, "החזרה" ב-RetailCRM ממופה ל"ביטול עסקה" תוך שמירה על הסיבה.
בפרויקט אחד, לקוח איבד 30% מהעסקאות מכיוון שהסטטוס "נמסר" לא הועבר — לאחר יישום הממפה, האבדות בוטלו.
אילו נתונים אנחנו מעבירים?
RetailCRM בנויה סביב הזמנות (Orders) כישות מרכזית, מה שמבדיל אותה מ-CRM קלאסיים כמו Bitrix24 שמוכוונים לעסקאות:
- Order — הזמנה עם פריטים, סטטוס, משלוח, תשלום
- Customer — קונה (יחיד או חברה)
- Product — מוצר (מהקטלוג של החנות)
- Task — משימות (מובנות בממשק)
- Note — הערות על הזמנות ולקוחות
- Segment — פלחי לקוחות (שיווק)
- Loyalty — תוכנית נאמנות (נקודות, רמות)
אנחנו מעבירים את כל הישויות האלה לאובייקטים המתאימים ב-Bitrix24. לדוגמה, הזמנות הופכות לעסקאות, לקוחות הופכים לאנשי קשר, ותוכנית הנאמנות הופכת לשדות מותאמים אישית של אנשי קשר או למודול נקודות בונוס.
כיצד בנויה ההעברה: תהליך שלב אחר שלב
- ביקורת נתונים — ייצוא מ-RetailCRM, ניתוח המבנה והנפח (שלב זה נמשך 1–3 ימים).
- תכנון מיפוי — אילו שדות תואמים לאילו, פתרון לסטטוסים ולתהליכים עסקיים.
- פיתוח סקריפט ההעברה — ב-PHP באמצעות RetailCRM API v5 ו-Bitrix24 REST API.
- בדיקות על עותק — העברת נתונים לסביבת בדיקה, התאמת סכומי ביקורת.
- אימות — השוואת מדדים מסכמים (מספר הזמנות לפי סטטוס, GMV).
- הפעלה בסביבת הייצור — העברה לסביבת הייצור, הדרכת עובדים.
כיצד להעביר הזמנות תוך שמירה על הסטטוסים?
ל-RetailCRM יש מערכת סטטוסים רב-שכבתית עם קבוצות. שלבי עסקה מתאימים נוצרים ב-Bitrix24. אנו ממפים סטטוסים באופן אוטומטי באמצעות StatusMapper, שלוקח בחשבון את הלוגיקה העסקית: לדוגמה, "Canceled" ב-RetailCRM יכול להפוך ל-"Deal lost". כמו כן חשוב לשמר את היסטוריית שינויי הסטטוסים — אנו מעבירים אותה לאירועי ציר הזמן של העסקה.
מה לעשות עם תוכנית הנאמנות?
נתוני נאמנות (נקודות, רמות, היסטוריית צבירה) מועברים באמצעות שדות איש קשר מותאמים אישית או מודול נקודות הבונוס של Bitrix24. אנו מפתחים סקריפט PHP המחשב מחדש יתרות בזמן ההעברה ומעלה את היסטוריית העסקאות. אם RetailCRM משתמש במערכת תפוגת נקודות, אנו מגדירים סוכני Bitrix24 לניכוי אוטומטי.
מיפוי הזמנות: דוגמה
בעת שילוב RetailCRM עם Bitrix24, מיפוי ההזמנות תלוי בשאלה האם לחברה יש חנות מקוונת ב-Bitrix. אם החנות קיימת: ייתכן שההזמנות כבר מסונכרנות — אנו מעבירים רק לקוחות והיסטוריה. אם אין חנות: ההזמנות מועברות כעסקאות (Deals), ולקוחות — כאנשי קשר וחברות.
| RetailCRM | Bitrix24 (ללא חנות) | Bitrix24 (עם חנות) |
|---|---|---|
| לקוח | איש קשר / חברה | משתמש אתר |
| הזמנה | עסקה (Deal) | הזמנה (b_sale_order) |
| פריט הזמנה | פריט עסקה | פריט סל קניות |
| משימה | משימה | משימה |
| הערה | תגובת ציר זמן | תגובה |
| סגמנט | קבוצת משתמשים | סגמנט CRM |
לוחות זמנים והחזר השקעה טיפוסיים
| נפח | לוח זמנים |
|---|---|
| עד 10,000 הזמנות, עד 5,000 לקוחות | 2–3 שבועות |
| 10,000–100,000 הזמנות | 4–8 שבועות |
| 100,000+ הזמנות, נאמנות, סגמנטים | 2–4 חודשים |
ההשקעות במיגרציה מחזירות את עצמן תוך 3–6 חודשים באמצעות אוטומציה של פעולות שגרתיות. העלות מחושבת באופן אישי בשלב הביקורת. המומחים המוסמכים שלנו מבטיחים מיפוי מדויק ושלמות נתונים.
מה כלול בעבודה
- ביקורת נתונים — ייצוא מבנה RetailCRM, ניתוח כפילויות וחריגות.
- תכנון מיפוי — סכמת התאמת שדות מפורטת תוך התחשבות בתהליכים עסקיים.
- פיתוח סקריפט — ב-PHP באמצעות APIs, עם אפשרות להוספת לוגיקה מותאמת אישית.
- מיגרציית בדיקה — על עותק של הסביבה, עם אימות סכומי ביקורת.
- הדרכת עובדים — וובינר או פגישה פרונטלית על עבודה עם הנתונים החדשים.
- תיעוד וקוד מקור — מועברים ללקוח.
- תמיכה לאחר מיגרציה — שבועיים של ניטור ותיקון באגים.
איך להימנע מטעויות במהלך ההעברה?
השתמשו בסביבת בדיקה. המהנדסים שלנו מגדירים שיבוט של Bitrix24 שבו הם מתרגלים תרחישי העברה. רק לאחר אישור הלקוח הנתונים מועברים לסביבת הייצור. אנו גם כותבים סקריפטים לתאימות לאחור במקרה של rollback.
אנו מבטיחים שלמות נתונים ועמידה בדרישות 54-FZ בעת העברת נתונים פיסקאליים. כל קודי המקור והתיעוד מועברים ללקוח.
צרו קשר לבדיקה מקדימה — נעריך את היקף ומורכבות ההעברה. קבלו ייעוץ עם מומחה מוסמך.