Перенесення даних з RetailCRM в Бітрікс24: історія та лояльність
При перенесенні з RetailCRM в Бітрікс24 основна складність — різна модель даних: RetailCRM центрується на замовленнях, Бітрікс24 — на угодах. Без акуратного маппінгу губляться статуси, історія платежів та дані клієнтів. Ми стикалися з проектами, де через невірний маппінг статусів 30% угод опинялися в неправильних стадіях, а історія лояльності була втрачена. Наша команда за 6 років провела більше 50 міграцій, і ми знаємо, як обійти ці граблі. Ми використовуємо RetailCRM API v5 для вивантаження та REST API Бітрікс24 для запису. Для великих обсягів паралелимо запити з обмеженням 5 RPS, що дозволяє обробляти до 50 000 замовлень на день. Міграція через наш автоматизований конвеєр у 3 рази швидша за ручне перенесення через Excel.
Чому правильний маппінг — основа міграції з RetailCRM в Бітрікс24?
RetailCRM зберігає статуси в багаторівневій структурі з групами, а Бітрікс24 — у плоских стадіях угод. Без маппінгу «Скасовано» може стати «Успішно», а «В роботі» — «Програш». Ми автоматично зіставляємо статуси через StatusMapper, який враховує бізнес-логіку: наприклад, «Повернення» в RetailCRM маппиться в «Скасування угоди» зі збереженням причини. На одному з проектів клієнт втратив 30% угод через те, що статус «Доставлено» не був перенесений — після впровадження мапера втрати виключені.
Які дані ми переносимо?
RetailCRM будується навколо замовлень (Orders) як центральної суті, що відрізняє її від класичних CRM на кшталт Бітрікс24, орієнтованих на угоди:
- Order — замовлення зі складом, статусом, доставкою, оплатою
- Customer — покупець (фізична особа або компанія)
- Product — товар (з каталогу магазину)
- Task — завдання (вбудовані в інтерфейс)
- Note — коментарі до замовлень і покупців
- Segment — сегменти покупців (маркетингові)
- Loyalty — програма лояльності (бали, рівні)
Всі ці сутності ми переносимо у відповідні об'єкти Бітрікс24. Наприклад, замовлення стають угодами, покупці — контактами, а програма лояльності — кастомними полями контакту або модулем бонусних балів.
Як влаштована міграція: покроковий процес
- Аудит даних — вивантаження з RetailCRM, аналіз структури та обсягу (етап займає 1–3 дні).
- Проектування маппінгу — які поля відповідають яким, рішення для статусів і бізнес-процесів.
- Розробка скриптів міграції — на PHP з використанням RetailCRM API v5 та REST API Бітрікс24.
- Тестування на копії — перенесення даних на тестове середовище, звірка контрольних сум.
- Верифікація — порівняння сумарних показників (кількість замовлень за статусами, GMV).
- Запуск у продакшн — перенесення в робоче середовище, навчання співробітників.
Як переносити замовлення зі збереженням статусів?
RetailCRM має багаторівневу систему статусів з групами. У Бітрікс24 створюються відповідні стадії угоди. Ми автоматично маппимо статуси через StatusMapper, який враховує бізнес-логіку: наприклад, «Скасовано» в RetailCRM може стати «Програш угоди». Важливо також зберегти історію змін статусів — ми переносимо її в події таймлайну угоди.
Що робити з програмою лояльності?
Дані лояльності (бали, рівні, історія нарахувань) мігрують через кастомні поля контакту або модуль бонусних балів Бітрікс24. Ми розробляємо PHP-скрипт, який перераховує баланси на момент перенесення та завантажує історію операцій. Якщо в RetailCRM використовується система згорання балів, ми налаштовуємо агенти Бітрікс24 для автоматичного списання.
Маппінг замовлень: приклад
При інтеграції RetailCRM з Бітрікс24 маппінг замовлень залежить від того, чи є в компанії інтернет-магазин на Бітрікс.
Якщо магазин є: замовлення вже можуть бути синхронізовані — мігруємо лише покупців та історію. Якщо магазину немає: замовлення переносяться як Угоди, покупці — як Контакти та Компанії.
| RetailCRM | Бітрікс24 (без магазину) | Бітрікс24 (з магазином) |
|---|---|---|
| Customer | Контакт / Компанія | Користувач сайту |
| Order | Угода | Замовлення (b_sale_order) |
| Order Item | Позиція угоди | Позиція кошика |
| Task | Завдання | Завдання |
| Note | Коментар таймлайну | Коментар |
| Segment | Група користувачів | Сегмент CRM |
Типові терміни та окупність
| Обсяг | Термін |
|---|---|
| до 10 000 замовлень, до 5 000 покупців | 2–3 тижні |
| 10 000–100 000 замовлень | 4–8 тижнів |
| 100 000+ замовлень, лояльність, сегменти | 2–4 місяці |
Інвестиції в міграцію окупаються вже через 3–6 місяців за рахунок автоматизації рутинних операцій. Вартість розраховується індивідуально на етапі аудиту. Наші сертифіковані спеціалісти гарантують точний маппінг та збереженість даних.
Що входить в роботу
- Аудит даних — вивантаження структури RetailCRM, аналіз дублів та аномалій.
- Проектування маппінгу — детальна схема відповідності полів з урахуванням бізнес-процесів.
- Розробка скриптів — на PHP з використанням API, з можливістю кастомної логіки.
- Тестова міграція — на копії середовища, з верифікацією контрольних сум.
- Навчання співробітників — вебінар або очна зустріч по роботі з новими даними.
- Документація та вихідні коди — передаються замовнику.
- Пост-міграційна підтримка — 2 тижні моніторингу та виправлення помилок.
Як уникнути помилок при міграції?
Використовуйте тестове середовище. Наші інженери налаштовують клон Бітрікс24, де відпрацьовують сценарії перенесення. Тільки після підтвердження замовника дані переносяться в бойове середовище. Ми також пишемо скрипти зворотної сумісності на випадок відкату. Гарантуємо збереженість даних та відповідність 54‑ФЗ при передачі фіскальних даних. Всі вихідні коди та документація передаються замовнику.
Зв'яжіться з нами для попереднього аудиту — ми безкоштовно оцінимо обсяг та складність міграції. Отримайте консультацію сертифікованого спеціаліста.