Оновлено: 2026. В e-commerce CRM без інтеграцій — це просто список контактів. Щоб реально підсилити продажі та сервіс, CRM має бачити весь ланцюжок: замовлення → оплата → доставка → повернення/рефанди → повторні покупки, зберігаючи UTM-атрибуцію та історію підтримки в одному місці.
Коротко: критичні інтеграції (P0–P2)
- P0 (must-have): Shopify/WooCommerce (замовлення+клієнти+статуси), платежі (paid/refund/chargeback), доставка/фулфілмент (трекінг+delivered/exception).
- P1 (високий вплив): UTM-атрибуція (first/last touch), підтримка/helpdesk (причини повернення/скасування, SLA, CSAT).
- P2 (етап масштабу): склад/ERP (залишки/ETA), фінанси (комісії/net), BI (LTV/ROMI/кохорти).
Зміст
- Які дані CRM має “бачити” в e-commerce
- Таблиця інтеграцій: що синхронізувати і навіщо
- Shopify → CRM: критичні поля та події
- WooCommerce → CRM: типові підводні камені
- Платежі → CRM: статуси, рефанди, чарджбеки
- Доставка/фулфілмент/повернення: трекінг і причини
- UTM-атрибуція: як не втрачати джерела
- Якість даних: дедуп, external IDs, ідемпотентність
- План впровадження
- Кому підійде, а кому ні
- FAQ
Які дані CRM має “бачити” в e-commerce
У магазині важливіше “Customer 360”, ніж одна картка угоди. Мінімум CRM має об’єднати профіль клієнта, замовлення, оплату, логістику, повернення/рефанди та звернення в підтримку.
- Клієнт: email, телефон, ім’я, мова/гео, згоди, first/last source.
- Замовлення: order_id/number, created_at, total, currency, знижки/купони, позиції, статуси.
- Оплата: payment_status, method, transaction_id, fee, net_amount, refunded_amount.
- Доставка: carrier, tracking_number, shipment_status, shipped_at, delivered_at, returned_at.
- Повернення/рефанд: частковий/повний, причина, позиції, сума, рішення (refund/replace/store credit).
- Підтримка: тікети, теги причин, SLA/час відповіді, CSAT/NPS.
Таблиця інтеграцій CRM для e-commerce
| Інтеграція | Що синхронізувати | Навіщо це потрібно | Пріоритет |
|---|---|---|---|
| Shopify/WooCommerce | Клієнти, замовлення, позиції, купони, статуси | Єдина база виручки та повторних покупок | P0 |
| Платежі | paid/failed, refunds (partial/full), chargebacks, fees | Правда про “оплачено” + коректний LTV/маржа | P0 |
| Доставка/Фулфілмент | трекінг, carrier, shipment_status, таймстемпи | Автоматизації після доставки + проактивна підтримка | P0 |
| UTM-атрибуція | first/last UTM, landing page, referrer, (за можливості) click IDs | ROMI/ROAS і прозорість каналів | P1 |
| Helpdesk/Чат | тікет, причини повернення/скасування, CSAT, SLA | Сегментація + менше повернень | P1 |
| Склад/ERP | залишки, ETA/backorder, COGS (якщо є) | Менше oversell + точніша маржа | P2 |
Shopify → CRM: що критично важливо
У Shopify недостатньо синхронізувати лише замовлення. Потрібні події життєвого циклу, які запускають автоматизації та дають правильну аналітику.
Must-have поля
- Клієнти: email, phone, consent, адреси, теги/сегменти.
- Замовлення: order_id/number, totals, discounts, taxes, shipping, currency.
- Позиції: sku/product_id, qty, price.
- Статуси: paid/unpaid, fulfilled/unfulfilled, cancelled (+ timestamps).
- Refunds: сума, позиції, час (partial/full).
Типові помилки
- Дублі клієнтів (email vs phone) через відсутність правил об’єднання.
- Refunds не синхронізуються → завищена виручка/LTV та “ламаються” сегменти.
- Немає delivered-event → не запускаються сценарії “після доставки” (відгук, допродаж, підтримка).
WooCommerce → CRM: типові підводні камені
WooCommerce часто має “зоопарк” плагінів, які змінюють статуси та логіку. Для стабільності краще нормалізувати події через webhooks (webhooks → інтеграційний шар → CRM).
- Мапінг статусів: processing/completed/cancelled/refunded (+ timestamps).
- Поля клієнта: billing/shipping email/phone, адреси.
- Порада: платіжний провайдер — джерело істини для “paid”.
Платежі → CRM: must-have
Платіжний провайдер — джерело істини для paid, refund (в т.ч. часткових), dispute та chargeback. Якщо брати “оплачено” лише з магазину, можна втрачати рефанди або не бачити комісії.
- Події: payment_succeeded, payment_failed, refund_partial/refund_full, dispute/chargeback.
- Поля: transaction_id, payment_method, amount, currency, fee, net_amount, refunded_amount.
Доставка/фулфілмент/повернення
Коли CRM бачить оновлення доставки, ви зменшуєте тікети “де моє замовлення?” і можете автоматизувати: delivered → запит відгуку, exception → проактивна підтримка, returned → retention-сценарій.
- Shipment: carrier, tracking_number, shipment_status, shipped_at, delivered_at, returned_at.
- Return: reason codes (розмір/дефект/запізнення), позиції, refunded_amount, рішення.
UTM-атрибуція: як не втрачати джерела
Мінімум — зберігати first і last UTM та переносити їх у замовлення. Інакше ROMI/ROAS перетворюється на здогадки, а “усе з Instagram” стає аргументом без доказів.
- first_utm_source/medium/campaign
- last_utm_source/medium/campaign
- landing_page, referrer, (за можливості) gclid/fbclid
Якість даних: дедуп, external IDs, ідемпотентність
- Дедуп: визначте ключ клієнта (часто email) + правила merge для телефону.
- External IDs: зберігайте Shopify/Woo customer_id та order_id у CRM.
- Ідемпотентність: зберігайте event_id/transaction_id, щоб не створювати дублікати при повторних webhooks.
План впровадження
- Визначте “джерела істини”: магазин, платежі, доставка.
- Встановіть ключ клієнта + правила merge + external IDs.
- Синхронізуйте Shopify/Woo → CRM (клієнти/замовлення/статуси).
- Синхронізуйте платежі → CRM (paid/failed/refund/dispute + fees).
- Синхронізуйте доставку → CRM (трекінг + таймлайн статусів).
- Додайте збір UTM і перенесення в замовлення.
- Підключіть helpdesk та причини повернення/скасування.
- Протестуйте кейси: часткові рефанди, split shipments, зміни адреси, дубль webhooks.
Кому підійде, а кому ні
Підійде
- магазинам із 20+ замовленнями/день або активною рекламою
- командам з менеджерами, де важливий контроль статусів та SLA
- бізнесам, які рахують ROMI/ROAS, LTV і хочуть масштабуватися
Не підійде (або не дасть ефекту)
- якщо продажі 1–2 на тиждень і немає реклами/операційного навантаження
- якщо команда не готова фіксувати статуси, причини відмов і працювати “по процесу”
- якщо немає відповідального за дані та інтеграції (хоча б на 2–4 год/тиждень)
FAQ
Чи потрібні webhooks з платежів, якщо Shopify вже показує “paid”?
Для операцій — інколи вистачає. Але для рефандів (особливо часткових), dispute/chargeback і комісій провайдера — webhooks з платежів набагато надійніші.
Мінімальний стек інтеграцій для малого магазину?
P0: платформа магазину + платежі + доставка. Далі додавайте UTM та підтримку, коли з’являється стабільний платний трафік і команда.
Що найчастіше ламає аналітику ROMI/ROAS?
Втрата UTM між сесією та замовленням, відсутність first/last атрибуції, не синхронізовані рефанди та дублікати клієнтів (email/phone).
Висновок: якщо ваша CRM “бачить” оплату, доставку, повернення та джерело трафіку, ви керуєте не лише замовленнями, а й прибутком. Почніть із P0-інтеграцій і поступово додавайте P1–P2 — так впровадження буде швидким і без болю.
М’який CTA: хочеш — підкажу, які саме поля/події варто передавати у твою CRM та як побудувати логіку webhooks, щоб не було дублів і “зниклих” UTM.