Інтеграція SendPulse, eSputnik чи Mailchimp з інтернет-магазином: автоматичні листи про кошик і замовлення

Автоматичні листи в інтернет-магазині рідко «ламаються» через шаблон чи текст. Найчастіше проблема в даних: подія про оплату приходить раніше за саму оплату, товар у листі вже закінчився, а клієнт, який купив годину тому, отримує нагадування про покинутий кошик. Тому інтеграція з інтернет-магазином – це не лише вибір сервісу, а й проєктування того, які події, коли і в якому вигляді передаються з магазину в платформу розсилок.

Нижче розбираємо, як підключити SendPulse, eSputnik або Mailchimp, які сценарії автоматизувати насамперед, які дані для цього потрібні та де найчастіше виникають технічні помилки.

Навіщо інтернет-магазину інтеграція з сервісом email marketing

Email marketing в eCommerce давно вийшов за межі щотижневих новин. Більшу частину регулярної комунікації з покупцем можна автоматизувати: привітати після реєстрації, нагадати про незавершену покупку, підтвердити замовлення, повідомити про відправку, попросити відгук і через певний час запропонувати повторне замовлення.

Ключова різниця між масовими і автоматичними листами – у тригері. Масова email-розсилка запускається маркетологом вручну для сегмента в конкретний момент. Автоматичні листи запускає поведінка конкретного користувача: подія на сайті, зміна статусу замовлення, відсутність активності протягом певного часу. Такі повідомлення приходять саме тоді, коли людина ще пам'ятає про магазин, тому зазвичай відкриваються краще за загальні розсилки.

Щоб тригерні розсилки працювали, сервісу email-розсилок потрібні дані магазину:

• контакт і профіль клієнта (email, телефон, ім'я, мова, місто, джерело реєстрації);

• поведінкові події: перегляди товарів і категорій, пошук, додавання в кошик;

• склад кошика і дані checkout;

• замовлення, статуси оплати та доставки;

• каталог товарів з актуальними цінами та наявністю;

• статус згоди на маркетингові комунікації.

Стандартних листів CMS вистачає, поки магазин надсилає лише системні повідомлення: «замовлення прийнято» і «пароль змінено». Коли з'являється потреба в сегментації, A/B-тестах, багатокрокових ланцюжках, товарних рекомендаціях або SMS і Viber як резервних каналах, вбудованих можливостей CMS стає замало. Кожну нову логіку доводиться програмувати в коді магазину, а маркетолог не може змінювати сценарії самостійно.

SendPulse, eSputnik і Mailchimp: що обрати для інтернет-магазину

Усі три платформи вміють надсилати email-розсилки за тригерами, але відрізняються фокусом, набором каналів і тим, наскільки глибоко працюють із даними eCommerce.

SendPulse: можливості для автоматизації email-розсилок

SendPulse – мультиканальна платформа з українським корінням, у якій поєднано email, SMS, Viber, web push, чат-боти в месенджерах і власну CRM. Для магазину ключовий інструмент – конструктор сценаріїв Automation 360: ланцюжки запускаються подією, зміною змінної контакту або датою. Платформа має зрозумілий інтерфейс українською, гнучкий REST API і SMTP для транзакційних листів, тому її часто обирають магазини, яким потрібно швидко запустити базові сценарії без окремої команди CRM-маркетингу.

eSputnik: автоматизація комунікацій для eCommerce

eSputnik від початку орієнтований на retention-маркетинг в електронній комерції. Окрім email, SMS, Viber, web push і мобільних push, платформа працює з товарним фідом, скриптом вебтрекінгу, динамічними товарними рекомендаціями та сегментами на основі поведінки. Більшість сценаріїв запускаються однією подією через API, в якій передаються всі потрібні параметри. Це зручно для магазинів зі складною логікою, але вимагає ретельнішого проєктування подій на старті.

Mailchimp: email marketing та Customer Journeys

Mailchimp – одна з найвідоміших світових email-платформ із великою кількістю шаблонів і зрілою аналітикою. Сценарії будуються в конструкторі Customer Journeys, який у новому інтерфейсі називається Automation Flows. Для магазинів доступні нативні підключення Shopify, WooCommerce, BigCommerce і PrestaShop, а для інших платформ – інтеграція через API як «custom store».

Порівняння Send Pulse, eSputnik і Mailchimp за ключовими можливостями

Який сервіс краще підходить малому, середньому та великому інтернет-магазину

Малому магазину з кількома сотнями замовлень на місяць зазвичай вистачає SendPulse або Mailchimp із готовим плагіном: welcome-серія, покинутий кошик, підтвердження замовлення. Середньому магазину, де важливі SMS і Viber, сегментація за історією покупок і рекомендації, частіше підходить eSputnik або SendPulse з інтеграцією через API. Великим магазинам із десятками тисяч SKU, кількома складами і програмою лояльності потрібна платформа, що працює з фідом і поведінковими подіями, а також кастомний шар інтеграції, який гарантує консистентність даних.

Як працює інтеграція SendPulse з інтернет-магазином

У пошуку платформу називають по-різному: «сенд пульс», «сент пульс», «сенпульс» або просто send pulse. Незалежно від написання, логіка інтеграції однакова: магазин створює й оновлює контакти, передає події та змінні, а Automation 360 запускає ланцюжки.

Які дані можна передавати в Сенпульс

У SendPulse можна передавати email і телефон, ім'я, мову, змінні контакту (сума покупок, дата останнього замовлення, кількість замовлень, улюблена категорія), а також події з довільним набором параметрів: склад кошика, номер замовлення, суму, статус, посилання на товари.

Інтеграція SendPuls через API, модуль CMS або готовий конектор

Для популярних CMS існують готові модулі, які синхронізують підписників і базові події. Якщо магазин працює на власному рушії або потрібно передавати статуси з облікової системи, інтеграцію роблять через REST API: бекенд надсилає події в момент зміни даних. Для системних листів (відновлення пароля, рахунки) використовують SMTP або транзакційний API.

Створення контактів, списків і сегментів у Send Puls

Контакти зберігаються в адресних книгах. Окремі книги варто створювати для принципово різних аудиторій, а всередині однієї книги – розділяти клієнтів сегментами за змінними. Корисно одразу передавати джерело реєстрації (сайт, застосунок, офлайн-точка), щоб будувати окремі сценарії для кожного каналу.

Налаштування автоматичних ланцюжків у SendPulse Automation

Тут є нюанс, який часто пропускають. Якщо сценарій запускається тригером «зміна змінної», контакт треба оновлювати саме методом зміни значення змінної, а не повторним додаванням email до адресної книги. Інакше дані в картці оновлюються, але сценарій не стартує. Також потрібно передавати нове значення: якщо магазин надсилає ту саму суму або дату, що вже збережена, зміни для платформи немає. Ще один момент безпеки: SMTP- і API-ключі мають зберігатися в менеджері секретів, а не в коді, щоб їх можна було швидко замінити в усіх середовищах, якщо провайдер оголосить примусову ротацію.

Які події магазину використовувати як тригери для розсилки

Базовий набір: реєстрація, підписка, додавання в кошик, початок checkout, створення замовлення, підтвердження оплати, зміна статусу доставки, отримання товару. Для кожної події заздалегідь фіксують назву, обов'язкові параметри і момент генерації в коді магазину. Окремо варто логувати кожен виклик API: що саме було надіслано, коли і з якою відповіддю. Коли маркетолог скаже, що лист конкретному клієнту не прийшов, такий журнал дозволить за кілька хвилин зрозуміти, де загубилася подія: на боці магазину, у черзі чи вже в платформі.

Інтеграція eSputnik з інтернет-магазином

Серед користувачів трапляються варіанти «е спутник» і e sputnik, але йдеться про одну платформу з глибшою, ніж у більшості email-сервісів, роботою з поведінкою покупців.

Передача товарів, контактів, замовлень і поведінкових подій в eSputnik

Інтеграція складається з кількох шарів: товарний фід із каталогом, скрипт вебтрекінгу для подій на сторінках, API-виклики для контактів і замовлень. Події мають чітку специфікацію: наприклад, для сторінки товару передається ознака наявності, а пошуковий запит часто варто відправляти лише тоді, коли пошук не дав результатів, щоб запускати сценарій «не знайшли – допоможемо». Важливо, щоб категорії в подіях збігалися з категоріями у фіді, інакше рекомендації та сегменти працюватимуть некоректно.

Як підключити Е Спутник через API або готову інтеграцію

Для поширених CMS існують готові модулі, але для магазину з власною логікою частіше обирають API. Під час масового вивантаження бази варто враховувати ліміти на кількість контактів в одному запиті: одна кнопка «експортувати всіх» для великої бази має розбивати дані на пакети, а не відправляти все одним викликом.

Сегментація покупців за історією переглядів і покупок

Після налаштування трекінгу можна будувати сегменти: переглядали категорію, але не купили; купували понад N разів; середній чек вищий за поріг; давно не заходили на сайт. Це основа для персоналізованих сценаріїв і товарних рекомендацій.

Тригерні розсилки та сценарії омніканальної комунікації

Один сценарій в eSputnik може поєднувати email, push, SMS і Viber з умовами переходу між ними. Наприклад, якщо лист про покинутий кошик не відкрили за добу, надіслати web push, а покупцям із високим середнім чеком – Viber-повідомлення.

Коли eSputnik доцільно використовувати замість простого email-сервісу

Коли у магазину великий асортимент, важливі динамічні рекомендації, є мобільний застосунок або потрібно вести покупця через кілька каналів в одному сценарії. Для 3–4 базових листів така глибина може бути надмірною: на налаштування фіду, трекінгу і специфікації подій піде більше часу, ніж на самі сценарії. Варто також оцінити, чи є в команді людина, яка регулярно працюватиме із сегментами та рекомендаціями, адже без цього розширені можливості платформи залишаться невикористаними.

Як підключити Mailchimp до інтернет-магазину

У запитах можна зустріти «мейлчімп», «мейлчимп» або mail chimp, але сценарій підключення від написання не залежить.

Інтеграція Mailchimp з WooCommerce та іншими eCommerce-платформами

Для WooCommerce, Shopify, BigCommerce і PrestaShop є нативні інтеграції, які підключаються в кілька кроків. Для OpenCart, Magento, власних рушіїв і конструкторів магазин підключається через Marketing API як custom store: бекенд сам створює клієнтів, товари, кошики і замовлення через відповідні ендпоінти.

Синхронізація аудиторій, товарів і замовлень

Після підключення Mailchimp отримує клієнтів, продукти, замовлення і кошики. Синхронізація контактів і синхронізація замовлень дають змогу будувати сегменти за сумою покупок, датою останнього замовлення і купленими товарами. Під час першого підключення конектор вивантажує історичні дані, і для великого магазину це може тривати довго: поки синхронізація не завершена, сегменти за покупками неповні. Також перевірте, як обробляються гостьові замовлення: покупець без позначки про підписку має потрапляти в аудиторію як транзакційний контакт, а не як підписник маркетингових розсилок.

Налаштування Customer Journeys у Мейлчімп

Готові шаблони Customer Journeys покривають welcome-серію, покинутий кошик, подяку після першої покупки і повернення неактивних клієнтів. Розширені сценарії з розгалуженнями доступні на платних тарифах.

Автоматичні email-кампанії на основі поведінки клієнта

Mailchimp підтримує тригери за подіями магазину, тегами та кастомними подіями через API, а також рекомендації товарів на основі історії покупок.

Обмеження Mail Chimp для українського eCommerce

Mailchimp не має українського інтерфейсу та україномовної підтримки, тарифи виставляються в доларах, а SMS-маркетинг доступний лише в обмеженому переліку країн, до якого Україна не входить. Viber і нативних інтеграцій з українськими службами доставки, платіжними сервісами та обліковими системами немає, тому для таких зв'язків доведеться робити кастомну інтеграцію.

Автоматичні листи про покинутий кошик

Лист про покинутий кошик – найочевидніший і зазвичай найприбутковіший тригерний сценарій. Але й помилок у ньому найбільше.

Як система визначає покинутий кошик

Кошик вважається покинутим, якщо після додавання товару за заданий час не з'явилось замовлення. Для цього сервіс має знати контакт користувача: email із профілю, форми підписки або поля checkout. Якщо email невідомий, сценарій не запуститься, тому корисно зберігати контакт уже на першому кроці оформлення.

Які дані повинні передаватися в SendPulse, eSputnik або Mailchimp

Ідентифікатор кошика або сесії, email, перелік товарів з ID, назвою, ціною, кількістю, зображенням і посиланням, загальна сума та валюта, а також посилання для відновлення кошика.

Через скільки часу надсилати перший лист про покинутий кошик

Типова практика – перший лист через 1–3 години. Менша затримка може «наздогнати» людину, яка ще порівнює варіанти, а більша знижує шанс повернення. Оптимальний інтервал варто визначати A/B-тестом для конкретного магазину.

Сценарій із двох або трьох нагадувань про незавершену покупку

1. Нагадування з товарами з кошика через кілька годин.
2. Лист із відгуками, умовами доставки або повернення через добу.
3. За потреби – персональна пропозиція через 2–3 дні.

Перед кожним кроком сценарій має перевіряти, чи не оформив клієнт замовлення.

Як персоналізувати лист товарами, ціною та посиланням на кошик

Товарний блок має підтягувати актуальні ціну та наявність, а не значення на момент додавання. Посилання на кошик повинно працювати незалежно від браузера і сесії: якщо воно прив'язане до cookie, користувач, який відкрив лист на телефоні, побачить порожній кошик або помилку 404. Надійніше використовувати підписаний токен кошика з обмеженим строком дії.

Чи варто додавати промокод або знижку в автоматичну розсилку

Знижка в першому листі привчає клієнтів чекати на неї. Краще залишати промокод для останнього кроку або для сегментів із великим чеком, а також обмежувати строк дії та генерувати унікальний код для кожного кошика.

Автоматичні листи після оформлення замовлення

Транзакційні листи (transactional email) клієнт очікує і відкриває охоче. Їхнє завдання – зняти тривогу після покупки та зменшити кількість звернень у підтримку.

Підтвердження отримання замовлення. Номер, склад, сума, спосіб оплати і доставки, контакти магазину. Лист має прийти за хвилини після оформлення. Маркетингові блоки на кшталт рекомендацій можна додати внизу, але вони не повинні відволікати від головної інформації, а відписка від маркетингових розсилок не має вимикати службові листи про замовлення.

Лист про успішну або неуспішну оплату. Важливо, щоб подія «оплачено» генерувалась лише після підтвердження від платіжного провайдера через callback, а не в момент переходу на сторінку оплати. Інакше клієнт отримає підтвердження і навіть цифровий товар ще до того, як заплатив. Для неуспішної оплати варто надсилати лист із повторним посиланням на оплату.

Повідомлення про зміну статусу замовлення. Статуси «в обробці», «зібрано», «скасовано» мають передаватися з того джерела, де вони реально змінюються: з CMS або з облікової системи.

Лист про передачу замовлення службі доставки. Номер ТТН, посилання на відстеження, орієнтовна дата отримання.

Розсилка після отримання товару. Інструкції з використання, умови гарантії та повернення.

Запит відгуку та рекомендація супутніх товарів. Через кілька днів після отримання – прохання оцінити товар і підбірка аксесуарів чи витратних матеріалів.

Які ще тригерні розсилки варто автоматизувати

• Welcome-серія після реєстрації або підписки: 2–4 листи про переваги магазину, бестселери, програму лояльності.

• Нагадування про переглянуті товари: для тих, хто дивився картку, але не додав товар у кошик.

• Повідомлення про зниження ціни: для товарів, які клієнт переглядав або додавав в обране.

• Лист про появу товару в наявності: підписка «повідомити, коли з'явиться» на картці товару.

• Повторна покупка для товарів із прогнозованим циклом споживання: корм, косметика, фільтри, кава – нагадування за кілька днів до очікуваного завершення запасу.

• Реактиваційна розсилка для неактивних клієнтів: для тих, хто не купував 3–6 місяців, з добіркою новинок або персональною пропозицією.

• Персональні рекомендації на основі історії покупок: блоки «вам може сподобатися» в регулярних листах і після замовлення.

Які дані потрібні для коректної роботи email-автоматизації

Дані користувача та контактна інформація. Email, телефон, ім'я, мова, місто, дата народження, джерело реєстрації, внутрішній ID клієнта. Зовнішній ID обов'язковий для коректного об'єднання профілів.

Перегляди товарів, категорій і пошукові запити. Дають матеріал для поведінкових розсилок і рекомендацій.

Дані кошика та checkout. Склад, сума, крок оформлення, на якому користувач зупинився.

Інформація про замовлення, оплату та доставку. Номер, склад, суми, статуси, ТТН, дата отримання.

Каталог товарів і актуальні ціни. Фід має оновлюватися достатньо часто. Якщо дані на сайті та у фіді розходяться, важливо заздалегідь визначити, яке джерело має пріоритет.

Згода користувача на маркетингові розсилки. Окремий прапорець для кожного каналу (email, SMS, Viber, push) з датою і джерелом отримання згоди. Закон України «Про електронну комерцію» прямо пов'язує поширення комерційних електронних повідомлень зі згодою адресата і вимагає можливості відмовитися від подальшого отримання.

Варіанти технічної інтеграції сервісу розсилок з магазином

Готовий модуль або плагін для CMS. Найшвидший старт. Модуль синхронізує контакти, кошики і замовлення, але обмежений стандартними подіями та полями.

Інтеграція через API. Бекенд магазину сам формує події та оновлює контакти. Це дає повний контроль над тим, що і коли передається, але потребує розробки, логування і підтримки.

Webhooks для передачі подій у реальному часі. Webhooks зручні, коли статус змінюється в зовнішній системі: платіжний провайдер повідомляє про оплату, служба доставки – про отримання посилки. Обробник webhook має бути ідемпотентним, адже провайдери нерідко надсилають ту саму подію кілька разів.

Інтеграція через CRM, CDP або ERP. Якщо замовлення живуть в обліковій системі, а профіль клієнта – в CRM, логічно передавати дані в платформу розсилок саме звідти, щоб не дублювати логіку в кількох місцях.

Коли потрібна кастомна інтеграція SendPulse, eSputnik або Mailchimp. Коли статуси формуються в ERP, є кілька вітрин, власна програма лояльності, мобільний застосунок або нестандартні сценарії на кшталт подарункових сертифікатів із відкладеною датою надсилання.

Як побудувати логіку автоматичних розсилок

Подія як старт тригерного сценарію. Кожен сценарій має чітку стартову подію з фіксованою назвою і набором параметрів. Подія повинна генеруватися один раз на бізнес-факт: одне замовлення – одна подія з усіма товарами, а не окрема подія для кожної позиції.

Умови, фільтри та сегменти. Хто входить у сценарій: лише клієнти зі згодою, лише певна мова або регіон, лише перша покупка.

Затримки між повідомленнями. Дату й час у параметрах подій варто передавати у форматі ISO 8601 із часовим зсувом, наприклад 2026-10-05T14:00:00+03:00. Без зсуву платформа може інтерпретувати час як UTC, і лист із відкладеною відправкою прийде на кілька годин пізніше.

Перевірка покупки перед наступним листом. Перед кожним кроком ланцюжка – умова «чи було замовлення після старту сценарію».

Виключення клієнтів зі сценарію. Відписка, скарга на спам, оформлення замовлення, потрапляння в інший пріоритетний сценарій.

Персоналізація контенту за даними магазину. Ім'я, товари, ціни, рекомендації, статус у програмі лояльності. Персоналізація листів працює лише тоді, коли дані повні та актуальні.

Email, SMS, Viber і web push: як поєднувати канали

Коли достатньо email marketing. Для листів із великим обсягом інформації: підтвердження замовлення, welcome-серія, підбірки та рекомендації.

Коли варто доповнювати лист SMS або Viber-повідомленням. Для термінових і важливих подій: замовлення готове до видачі, оплата не пройшла, посилка чекає у відділенні. SMS-розсилки і Viber-розсилки дорожчі за email, тому їх варто використовувати як резервний канал, якщо лист не відкрили.

Push-повідомлення для повернення клієнта на сайт. Web push підходить для зниження ціни, появи товару і нагадування про кошик для анонімних відвідувачів, які дали дозвіл на сповіщення. Пояснення перед системним запитом дозволу реалізується на боці сайту чи застосунку.

Як не перевантажити користувача розсилками?  Встановіть ліміт частоти: наприклад, не більше одного маркетингового повідомлення на добу в усіх каналах разом. Транзакційні листи під цей ліміт не підпадають. Пріоритет сценаріїв визначте заздалегідь: якщо клієнт оформив замовлення, він має вийти з ланцюжка покинутого кошика, а не отримати обидва листи.

Типові помилки під час інтеграції SendPulse, eSputnik або Mailchimp

Дублювання контактів і замовлень. Буває, що подія замовлення спрацьовує кілька разів: на кожен товар окремо або з кількох обробників. Клієнт отримує 2–4 однакові листи. Рішення – один зовнішній ID замовлення, перевірка ідемпотентності і генерація події в одній точці коду.

Некоректна передача статусів замовлення. Найнебезпечніший варіант – лист про успішну оплату до її фактичного підтвердження. Для цифрових товарів і подарункових сертифікатів це прямі фінансові втрати.

Відсутність перевірки, чи завершив клієнт покупку. Людина вже оплатила, а отримує нагадування про кошик. Це руйнує довіру і збільшує кількість відписок.

Застарілі дані про товари та ціни в листах. Фід оновлюється раз на добу, а ціна змінилась уранці. Клієнт переходить за листом і бачить іншу суму або статус «немає в наявності».

Розсилки без сегментації аудиторії. Одна і та сама реактиваційна пропозиція для всіх знецінює знижку і підвищує частку скарг.

Неправильне налаштування домену та email-аутентифікації. Без записів SPF, DKIM і DMARC для домену відправника листи потрапляють у спам або відхиляються. Типова ситуація: DKIM пройдено, але запису DMARC немає взагалі, і перевірка на кшталт mail-tester одразу знижує оцінку.

Як перевірити інтеграцію перед запуском

Перехід зі стандартних листів CMS на сервіс розсилок краще робити поетапно. Різке перемикання всіх листів в один день часто закінчується відкатом до старої схеми. Надійніше спочатку запустити події в тестовому режимі, коли листи отримує лише технічна скринька, і порівнювати їх із листами CMS.

Тест реєстрації нового користувача. Контакт з'являється в платформі з усіма полями, стартує welcome-серія.

Тест покинутого кошика. Додайте товар, залиште сайт, перевірте затримку, склад листа і роботу посилання з іншого пристрою.

Тест нового та оплаченого замовлення. Лист про оплату приходить лише після реального підтвердження платежу, неуспішна оплата обробляється окремо.

Перевірка персоналізації та динамічних товарних блоків. Ціни, зображення, валюта, порожні поля, довгі назви товарів.

Перевірка відписки та налаштувань згоди. Відписка в листі змінює статус у магазині, і навпаки. Видалення або анонімізація профілю на сайті має коректно оброблятися і в платформі, навіть якщо контакту там вже немає.

Контроль доставки листів і потрапляння у спам. Тест на основних поштових сервісах, перевірка заголовків аутентифікації та посилання для відписки в один клік.

Як оцінювати ефективність автоматичних email-розсилок

Delivery Rate та Bounce Rate. Частка доставлених листів і частка відхилених. Високий bounce – сигнал прибрати неіснуючі адреси та перевірити аутентифікацію домену.

Open Rate і Click Rate. Open Rate показує інтерес до теми, але через захист приватності в поштових клієнтах він завищений, тому для рішень надійніше спиратися на Click Rate.

Конверсія з автоматичних листів. Частка отримувачів, які оформили замовлення після переходу з листа. Для коректного підрахунку потрібні UTM-мітки й наскрізна аналітика.

Дохід від покинутих кошиків. Сума замовлень, оформлених після сценарію повернення кошика, з урахуванням вікна атрибуції.

Частка повторних покупок. Показує, чи працюють сценарії утримання і рекомендацій.

Як порівнювати ефективність різних сценаріїв автоматизації. Порівнюйте дохід на одного отримувача і конверсію з урахуванням контрольної групи, яка не отримує листів. Інакше частину продажів, які відбулися б і без розсилки, ви припишете автоматизації.

Готова інтеграція чи кастомна розробка: що обрати

Коли достатньо стандартного плагіна. Магазин на популярній CMS, кілька базових сценаріїв, статуси замовлень змінюються в самій CMS. Але порівнювати варто не лише вартість старту, а й TCO: плагін безкоштовний чи дешевий, проте кожне оновлення CMS або модуля може змінити передачу полів, а обійти обмеження стандартних подій без доопрацювань неможливо.

Для яких магазинів потрібна інтеграція через API. Власний рушій, облікова система як джерело статусів, мобільний застосунок, нестандартні товари на кшталт сертифікатів, підписок або передзамовлень.

Що врахувати при великому каталозі та високій кількості замовлень. Події варто надсилати через асинхронну чергу з повторними спробами, а не прямим викликом у момент оформлення замовлення. Якщо API платформи тимчасово недоступний, покупець не повинен бачити помилку, а подія має доставитися пізніше. Для черги потрібні моніторинг і алерти на помилки, а масові синхронізації варто розбивати на пакети.

Інтеграція email-платформи з CRM, ERP та програмою лояльності. Бали, рівень клієнта і баланс сертифікатів мають передаватися з того джерела, де вони рахуються. CRM інтеграція дозволяє менеджерам бачити історію комунікацій поруч з історією замовлень.

Як підготувати технічне завдання на інтеграцію. У ТЗ зафіксуйте:

• перелік сценаріїв і тригерних подій;

• специфікацію кожної події: назва, параметри, типи даних, джерело, момент генерації;

• джерело істини для статусів, цін і наявності;

• правила роботи зі згодою і відпискою;

• обробку помилок, повторів і дублікатів;

• план тестування і критерії приймання.

FAQ