Синхронізація замовлень з маркетплейсів у CRM без ручного перенесення
Покрокова інструкція, як налаштувати синхронізацію замовлень з Prom, Rozetka і Kasta у CRM — без копіювання вручну і без втрачених заявок.
Якщо ви продаєте одночасно на Prom, Rozetka і Kasta, менеджер щодня заходить у три-чотири особисті кабінети, переписує нові замовлення в CRM або в Excel вручну. Це займає час, і рано чи пізно хтось пропустить замовлення або переплутає статус. Питання, яке мені ставлять найчастіше: як зробити так, щоб замовлення з маркетплейсів самі падали в CRM, а менеджер тільки обробляв їх далі.
Відповідь — через API кожного майданчика і налаштоване правило обробки нових замовлень. Нижче — як я це роблю в реальних проєктах, крок за кроком.
Крок 1. Перевірте, що у маркетплейсу є API для замовлень
Prom.ua і Rozetka (через Rozetka Marketplace) дають API з доступом до списку замовлень, їх статусів і товарних позицій. Kasta теж надає API для партнерів, хоча процедура підключення там трохи складніша й потребує погодження з менеджером майданчика.
Перше, що я роблю на старті проєкту — не відкриваю CRM, а йду в документацію API потрібного майданчика. Там одразу видно, які дані доступні: чи є номер телефону покупця, чи передається спосіб доставки, чи можна отримати статус оплати. Це визначає, що взагалі можна автоматизувати, а що доведеться доробляти вручну.
Буває, що продавець підключений до маркетплейсу через стороннього інтегратора (наприклад, через сервіс синхронізації залишків), і тоді прямого доступу до API може не бути — потрібно уточнювати в самого інтегратора. Це той момент, де половина планів на автоматизацію зависає ще на старті, тому його варто закрити першим.
Крок 2. Оберіть, де відбуватиметься логіка синхронізації
Тут є два шляхи. Перший — якщо CRM (найчастіше це PlanFix у моїй практиці) має готовий конектор або достатньо гнучке API, можна написати пряму інтеграцію. Другий — поставити між маркетплейсом і CRM проміжний шар на n8n, який раз на кілька хвилин опитує API маркетплейсу, забирає нові замовлення і створює задачі чи угоди в CRM.
Я майже завжди обираю другий варіант, коли маркетплейсів більше одного. Замість трьох окремих інтеграцій ви отримуєте один сценарій у n8n, який обробляє Prom, Rozetka і Kasta паралельно, а в CRM все потрапляє вже в єдиному форматі. Якщо завтра підключите четвертий майданчик, додаєте ще одну гілку сценарію, а не переписуєте всю логіку заново.
Крок 3. Налаштуйте правила мапінгу полів
Це найнудніший, але найважливіший крок. У кожного маркетплейсу своя структура замовлення: де лежить телефон, як називається поле з адресою доставки, у якому форматі приходить сума. Потрібно прописати відповідність: поле замовлення з Prom → поле угоди в CRM, поле з Rozetka → те саме поле угоди, і так для кожного майданчика.
Окремо варто продумати, що робити з товарними позиціями всередині замовлення — чи потрібні вони в CRM як список, чи достатньо суми і кількості позицій. У складському обліку я зазвичай тягну повний список товарів, бо без нього неможливо правильно сформувати відвантаження.
Крок 4. Пропишіть логіку статусів і уникнення дублів
Замовлення на маркетплейсі змінює статус: нове, підтверджене, відправлене, скасоване. CRM має отримувати ці зміни, а не тільки факт створення замовлення. Інакше менеджер однаково лізе в кабінет маркетплейсу перевіряти, чи оплатили.
Другий момент — дублі. Якщо сценарій синхронізації запускається кожні кілька хвилин, він не повинен створювати нову угоду для замовлення, яке вже є в CRM. Рішення просте: перед створенням угоди перевіряти наявність замовлення за його унікальним номером з маркетплейсу і, якщо воно вже є, тільки оновлювати статус.
Найчастіша причина, чому синхронізація "ламається" за кілька тижнів після запуску — зміна формату відповіді API на боці маркетплейсу без попередження. Сценарій тихо перестає створювати нові угоди, а команда помічає це тільки тоді, коли клієнт сам пише, що замовлення ніхто не обробив.
Крок 5. Додайте моніторинг і людину, що відповідає за збій
Автоматизація без контролю — це відкладена проблема. Потрібен простий механізм: якщо сценарій синхронізації не відпрацював або отримав помилку від API, хтось має отримати сповіщення в Telegram одразу, а не через три дні.
У своїй практиці я завжди додаю окремий крок у сценарій n8n, який у разі помилки відправляє повідомлення відповідальному менеджеру чи в технічний чат. Це займає хвилин двадцять на налаштування, але рятує від ситуацій, коли замовлення з маркетплейсу просто зникають з поля зору на кілька днів.
Коротко про головне
Синхронізація замовлень з маркетплейсів у CRM будується на чотирьох речах: доступ до API майданчика, проміжний шар логіки (найчастіше n8n), чіткий мапінг полів і обробка статусів без дублів. Окремо потрібен моніторинг збоїв — без нього автоматизація рано чи пізно почне мовчки губити замовлення. Це типова робота для CRM-проєкту середньої складності, яка окупається тим, що менеджери перестають вручну копіювати дані між трьома-чотирма кабінетами щодня.
Чек-лист перед запуском синхронізації: 1) перевірено доступ до API кожного маркетплейсу; 2) обрано, де живе логіка — пряма інтеграція чи n8n; 3) прописано мапінг усіх потрібних полів, включно з товарними позиціями; 4) є захист від дублів за унікальним номером замовлення; 5) налаштовано сповіщення про збій синхронізації.
Є питання по вашому випадку?
30 хвилин — і зрозумієте, що реально зробити у вашій компанії.
Записатись на аудит