Сайт + соцмережі: як зібрати всі заявки в одному місці

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

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

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

П’ять точок, де губляться заявки

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

1. Доставка листів із форми

Найпоширеніша схема – форма надсилає лист на пошту через стандартну функцію відправлення на хостингу. Без налаштованих SPF, DKIM і DMARC такі листи часто потрапляють у спам або взагалі не доходять. Ніхто про це не дізнається: форма показала «Дякуємо», а заявки немає.

2. Збій між сайтом і CRM

Форма відправляє дані у CRM, але сервер CRM відповів помилкою чи не відповів через таймаут. Якщо сайт не повторює запит і не зберігає заявку в себе, вона зникає безслідно.

3. Асинхронні канали без сповіщень

Коментарі під рекламою, відповіді на сторіс, лід-форми в рекламному кабінеті. Вони не «дзвонять», як Direct, тому їх перевіряють нерегулярно. А людина, яка написала «ціна?» під рекламою, чекає відповіді так само, як і в Direct.

4. Втрата атрибуції

UTM-мітки є лише на першій сторінці, куди прийшов користувач. Якщо він переглянув кілька сторінок чи повернувся наступного дня, мітки вже немає. У CRM заявка падає з джерелом «невідомо», і бюджет на рекламу розподіляють наосліп.

5. Дублі й «нічийні» ліди

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

Модель даних: що саме ми збираємо

Фраза «зібрати всі заявки в одному місці» звучить просто, але за нею стоїть конкретна модель даних. Варто розрізняти три сутності:

• Контакт – людина. Один на всі канали, ідентифікується за нормалізованим номером телефону у форматі E.164 (+380…), а за потреби – за email чи ID у соцмережі.
• Звернення – кожен окремий вхідний сигнал: заявка з форми, повідомлення в Direct, коментар, лід із реклами. Має джерело, час і канал.
• Угода чи замовлення – те, у що звернення перетворюється, з товарами, сумою й статусом.

Коли ці сутності змішані, наприклад кожне повідомлення створює новий «контакт», звіти брешуть, а менеджери плутаються. Коли розділені, видно повну історію клієнта: звідки він прийшов уперше, скільки разів звертався й що купив.

Як надійно підключити сайт

Спосіб підключення залежить від стеку й від того, наскільки критична кожна заявка. Ось чотири основні варіанти.

Спосіб	Коли підходить	Головний ризик
Готова інтеграція з CMS	WooCommerce, Shopify, Хорошоп та інші популярні платформи	Обмежений набір полів
Webhook із форми	Лендинги й конструктори сайтів	Заявка зникає, якщо приймальна сторона недоступна
Пряма інтеграція через API	Самописні сайти, нестандартна логіка	Потрібен розробник і підтримка коду
No-code конектор	Немає розробника, потрібен швидкий старт	Ще одна ланка, яка може дати збій

Готова інтеграція: почніть із неї

Якщо магазин працює на популярній CMS, спершу перевірте готові інтеграції. Наприклад, у CRM для онлайн-магазинів SITNIKS замовлення з популярних платформ і маркетплейсів підтягуються автоматично, без коду. Це закриває більшість сценаріїв за кілька хвилин налаштування.

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

Webhook і API: як не втратити заявку

Саме тут найчастіше губляться звернення. Кілька правил, які варто закласти в код:

• Відправляйте дані з бекенду, а не з браузера. Клієнтський запит обривається, якщо користувач закрив вкладку або в нього заблоковані скрипти.
• Спочатку збережіть, потім відправляйте. Запишіть заявку в базу сайту, а вже потім передавайте в CRM. Так у вас завжди є оригінал.
• Черга з повторами. Якщо CRM не відповіла, повторіть спробу з наростаючою затримкою (exponential backoff), а не губіть заявку після першої помилки.
• Ключ ідемпотентності. Під час повторів передавайте унікальний ID заявки, щоб CRM не створила дубль.
• Перевірка підпису для вхідних webhook. Якщо CRM надсилає події на ваш сайт, перевіряйте HMAC-підпис, щоб ніхто сторонній не підкидав фейкові дані.
• Антиспам без тертя. Замість капчі, яка знижує конверсію, використайте honeypot-поле й обмеження частоти запитів.

Атрибуція: зберігайте джерело до самої заявки

Щоб у CRM було видно, звідки прийшов клієнт, джерело треба «донести» до моменту відправлення форми:

1. На першому вході збережіть UTM-мітки й click ID (gclid, fbclid, ttclid) у cookie на 30–90 днів.
2. Окремо фіксуйте перше й останнє джерело (first touch і last touch): вони відповідають на різні питання.
3. Підставляйте збережені значення в приховані поля форми або додавайте на бекенді під час відправлення.

Мінімальний набір полів

• ім’я та нормалізований телефон (+380…);
• сторінка й назва форми;
• UTM-мітки, click ID, first і last touch;
• товар чи послуга, кошик, якщо є;
• згода на обробку персональних даних і на комунікацію;
• унікальний ID заявки.

Не забувайте про інфраструктуру

Система збору заявок надійна настільки, наскільки надійний сайт. Стабільний хостинг, валідний SSL, налаштовані SPF і DKIM для листів, фонові задачі (cron або воркер черги) і моніторинг доступності – така сама частина ланцюжка, як і CRM. Корисна практика – щодня автоматично відправляти тестову заявку й перевіряти, що вона дійшла до системи.

Соцмережі й месенджери: офіційні API та їхні обмеження

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

Instagram і Facebook

Підключайте професійні акаунти через офіційний API Meta. Тоді в систему потрапляють не лише особисті повідомлення, а й коментарі під постами та рекламою.

Два нюанси, які варто знати:

• Вікно відповіді. Meta дозволяє бізнесу вільно відповідати в Direct і Messenger протягом 24 годин після останнього повідомлення клієнта. Пізніше можливості писати обмежені. Тому швидкість першої відповіді тут – не побажання, а технічна вимога.
• Коментарі. Коментар під рекламою – такий самий лід, як повідомлення в Direct. Якщо коментарі не потрапляють у загальний список, їх перевіряють раз на день, і клієнт іде до конкурента.

Лід-форми в рекламі

Ліди з форм Meta Ads і TikTok Ads за замовчуванням лежать у рекламному кабінеті. Підключіть їх через webhook або готову інтеграцію, щоб кожна заявка за секунди потрапляла в систему. Окрема перевага: можна одразу бачити, з якої кампанії й оголошення прийшов лід.

TikTok

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

Viber і Telegram: особистий номер чи бізнес-акаунт

• Особистий номер менеджера. Швидкий старт, але переписки належать менеджеру, а не компанії. Масові розсилки з особистого номера ризикують блокуванням, а історія клієнтів зникає, якщо менеджер іде.
• Бізнес-акаунт або бот. Акаунт належить компанії, переписки зберігаються в системі. Про Viber для бізнесу детальніше розповімо нижче.

Як це працює на практиці: приклад SITNIKS

Щоб не говорити абстрактно, розберемо, як інтеграції з соцмережами й месенджерами влаштовані в SITNIKS – українській CRM для онлайн-магазинів, які продають у чатах.

Усі канали в одному списку чатів

У SITNIKS кожен канал підключається окремим модулем, але всі звернення падають в один розділ «Чати»:

• Instagram – Direct і коментарі під постами й рекламою;
• Facebook – Messenger, коментарі й заявки з Facebook Leads;
• TikTok – Direct і заявки з TikTok Ads;
• Telegram – особистий номер і бот;
• Viber – особистий номер, бот і офіційний бізнес-акаунт;
• WhatsApp – особистий номер.

Менеджер бачить біля кожного чату іконку джерела, статус і відповідального. Коментар «ціна?» під рекламою стоїть у тому ж списку, що й повідомлення в Direct, тож його не пропустять.

Від повідомлення до відправлення без перемикання вікон

Далі все відбувається прямо з картки чату:

1. Менеджер створює замовлення з переписки, контакт клієнта підтягується автоматично.
2. Надсилає в чат платіжне посилання через власний платіжний модуль SITNIKS Pay.
3. Після оплати статус сам змінюється на «Оплачено», фіскальний чек формується через Checkbox чи Вчасно.Каса й іде клієнту в чат.
4. ТТН Нової Пошти створюється з того ж замовлення.

Паралельно подія покупки передається в Meta через Conversions API. Реклама в Instagram і Facebook навчається на реальних продажах із чатів, а не лише на заявках.

Офіційний Viber для бізнесу

SITNIKS – офіційний партнер Viber for Business, тому бізнес-акаунт Viber працює всередині CRM. Ось чим він відрізняється від особистого номера чи бота:

• Верифікований акаунт. Клієнт бачить назву й логотип магазину з синьою галочкою, а не невідомий номер. Довіри до повідомлень більше.
• Можна писати першим. На відміну від бота, на якого клієнт має підписатися, бізнес-акаунт може надіслати повідомлення клієнту, який дав згоду на комунікацію. Шаблони таких повідомлень попередньо проходять модерацію Viber.
• Чат-сесії. Коли клієнт пише сам, відкривається сесія на 24 години, у межах якої менеджер відповідає без оплати за кожне повідомлення.
• Транзакційні повідомлення з CRM. ТТН, статуси замовлень і нагадування про оплату надсилаються автоматично з картки замовлення.
• Акаунт належить бізнесу. Переписки й база залишаються в компанії, навіть якщо менеджер звільниться.

Це закриває обмеження, про яке ми говорили вище: в Instagram і Facebook вікно для відповіді обмежене правилами Meta, а у Viber бізнес може повернутися до клієнта через погоджений шаблон, наприклад із нагадуванням про кошик чи новою пропозицією.

Повторні продажі по базі

Коли всі заявки зібрані в одному місці, база стає активом. У SITNIKS вбудований RFM-аналіз ділить клієнтів на сегменти за давністю, частотою й сумою покупок. Менеджер бачить, кому варто запропонувати повторну покупку, надсилає пропозицію через Viber для бізнесу, а замовлення й оплата знову проходять у тому ж чаті.

Мобільний застосунок

Усе описане доступне й у мобільному застосунку для iOS та Android: чати, замовлення, ТТН і платіжні посилання. Для невеликих команд, які продають з телефона, це часто головний аргумент перейти з особистих месенджерів у систему.

Правила обробки, без яких інтеграції не працюють

Навіть ідеально підключені канали не врятують, якщо в системі немає правил. Ось що варто закласти одразу.

Дедуплікація за чіткими правилами

Визначте, за яким ключем система об’єднує звернення в один контакт. Найнадійніший варіант – нормалізований телефон. Для соцмереж, де телефону ще немає, контакт прив’язують до ID акаунта, а коли клієнт залишає номер, картки об’єднуються. Головне – щоб правило було одне для всіх каналів.

Маршрутизація й відповідальний

Кожне нове звернення має одразу отримати відповідального: за чергою (round robin), за каналом чи за мовою клієнта. «Хтось відповість» на практиці означає «ніхто не відповість».

Статуси з обов’язковою причиною відмови

Статуси показують, де застрягли клієнти. А обов’язкова причина відмови («дорого», «немає в наявності», «не відповідає») за місяць дає аналітику, яку не отримати з жодного звіту реклами.

Метрики, за якими варто стежити

• Час першої відповіді. Встановіть внутрішній стандарт, наприклад відповідь протягом 15 хвилин у робочий час, і налаштуйте нагадування, коли його порушено.
• Частка звернень без відповіді за день.
• Частка заявок без джерела. Якщо вона росте, десь зламалася передача UTM-міток.
• Конверсія зі звернення в замовлення окремо по кожному каналу.

Чек-лист: як зібрати всі заявки в одному місці

Аудит

1. Випишіть усі точки входу: форми, кошик, Direct, коментарі, месенджери, лід-форми в рекламі.
2. Для кожної визначте, куди зараз потрапляють дані і хто їх перевіряє.

Сайт

3. Підключіть готову інтеграцію з CMS або налаштуйте відправлення з бекенду.
4. Зберігайте кожну заявку в базі сайту до відправлення в CRM.
5. Додайте чергу з повторами й ключ ідемпотентності.
6. Зберігайте UTM-мітки й click ID у cookie та передавайте їх разом із заявкою.
7. Налаштуйте SPF, DKIM і DMARC для листів із сайту.

Соцмережі й месенджери

8. Підключіть Instagram, Facebook, TikTok через офіційні API, включно з коментарями.
9. Інтегруйте лід-форми з рекламних кабінетів.
10. Переведіть комунікацію з особистих номерів на бізнес-акаунти.

Процеси

11. Визначте єдине правило дедуплікації.
12. Налаштуйте маршрутизацію й статуси з причинами відмови.
13. Встановіть стандарт часу першої відповіді.
14. Налаштуйте щоденну тестову заявку й моніторинг доступності сайту.

Висновок

Зібрати всі заявки в одному місці – це не про вибір «правильної» CRM, а про надійний конвеєр даних. Кожна заявка має гарантовано дійти до системи, отримати джерело, потрапити до відповідального й не задублюватися.

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