Вашої CRM немає в списку. Як підключити месенджери через ApiX-Drive і Wepster

Готових інтеграцій більше 20, і вони закривають поширені системи. Але галузевих і локальних CRM у світі тисячі, і ймовірність зустріти свою в будь-якому списку невелика. Українському ринку це знайомо окремо — значна частина компаній працює на власних доробках, галузевих системах для аптек, автосервісів чи агробізнесу і на конфігураціях, які писали під конкретний склад. Відсутність у списку давно означає не «не можна», а «через проміжну ланку». Нижче порівняння 2 платформ, порядок налаштування зв’язки з розбором зіставлення полів і чесний перелік того, що втрачається під час роботи через посередника.

Головне зі статті:

• Відсутність вашої CRM розв’язується 3 способами — конектор ApiX-Drive, платформа Wepster або власна розробка через API

• ApiX-Drive перекладає дані між системами, Wepster додає власний шар роботи зі зверненнями

• Проміжна ланка додає затримку і залежність від третьої сторони, і це потрібно закладати в процес

• Помилки частіше виникають на зіставленні полів і на форматі номера телефона, а не на самому конекторі

• Повний цикл тесту вкладається в 7 безкоштовних днів і завершується роботою менеджера на реальних діалогах

• Через конектор не можна отримати переписку в інтерфейсі вашої CRM у тому вигляді, у якому її дає нативна інтеграція

Порівняння ApiX-Drive і Wepster

Таблицю зібрано нами за підсумками розбору можливостей обох платформ і типових сценаріїв їх застосування.

ApiX-Drive з’єднує системи за логікою події і дії

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

Для нашої задачі це 2 напрямки передачі. З CRM у месенджер ідуть вихідні повідомлення за подіями, з месенджера в CRM повертаються вхідні з прив’язкою до клієнта.

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

Wepster додає шар поверх систем, а не між ними

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

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

Вибір визначається тим, чи вміє ваша CRM вести діалог

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

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

Що втрачається і що зберігається під час роботи через посередника

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

Затримка, залежність і глибина інтеграції

Проміжна ланка додає затримку, зазвичай від секунд до хвилини залежно від налаштувань оновлення.

Збій у конектора виглядає для вашої команди як збій месенджера, і розбиратися доводиться в 3 місцях замість 2.

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

Основна цінність інтеграції досягається будь-яким із 3 способів

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

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

Порядок налаштування зв’язки

Спершу робочий номер, потім конектор

Підключіть номер у сервісі E-chat. Реєстрація, активація номера у Viber, Telegram або WhatsApp із підтвердженням на телефоні, синхронізація.

Без робочого номера налаштовувати зв’язку немає сенсу, бо половина помилок на цьому етапі виявиться не в конекторі.

Зіставлення полів дає більше помилок, ніж сама зв’язка

У платформі створюється зв’язок між системами. Зазначається джерело даних, приймач і відповідність полів. Саме тут найчастіше помиляються.

Номер телефона нормалізуйте до міжнародного формату на боці CRM до передачі. Якщо в базі номери лежать у 4 різних написаннях, прив’язка вхідних до клієнтів працюватиме через раз, і винним виявиться конектор, хоча причина в даних. Для української бази це особливо болюче — у ній зазвичай співіснують записи з кодом 380, з вісімкою на початку і взагалі без коду.

Після ввімкнення автооновлення обов’язкова перевірка на реальному діалозі, а не на тестовому записі.

3 рішення, які ухвалюють до запуску

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

Як обробляються дублі. Один клієнт може написати з 2 номерів, і без правила злиття в базі з’являться близнюки.

Де дивитися історію передач. Коли через місяць повідомлення загубиться, це буде єдине місце, де можна зрозуміти, де саме.

[H4] Окремий ризик при змінах на боці CRM

Ситуація, яка ламає зв’язку без жодного збою в конектора. Адміністратор перейменував поле або додав обов’язковий атрибут у картці, і передача починає падати з помилкою. Заведіть правило — будь-яка зміна структури картки супроводжується перевіркою зв’язки того самого дня.

Експертна врізка

Інтегратори, які регулярно ставлять такі зв’язки, відзначають одну закономірність. Замовник майже завжди просить перенести в CRM усе, включно з кожним повідомленням, кожним статусом прочитання і кожним вкладенням. Через 2 місяці з’ясовується, що більшу частину цих даних ніхто не відкриває, а зв’язка стала крихкою і ламається за будь-якої зміни з будь-якого боку. Робочий підхід зворотний — мінімальний набір на старті. Вхідне повідомлення з прив’язкою до клієнта і вихідне за 2–3 ключовими подіями. Це покриває основну цінність і майже не ламається. Розширювати має сенс лише тоді, коли за конкретними даними прийшла конкретна людина з конкретною задачею.

План тесту на 7 днів

3 критерії, за якими вирішують, чи оплачувати

Вхідне потрапляє в потрібну картку без ручного втручання більш ніж у 95% випадків.

Затримка від повідомлення до появи в CRM не перевищує хвилини.

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

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

3 ознаки, що конектор переріс себе

Затримки стали помітні менеджерам і клієнтам. Логіка маршрутизації перестала вкладатися в правила інтерфейсу. Кількість ручних виправлень у CRM зростає місяць від місяця.

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

Коли конектор не підходить

Подвійне зберігання історії створює невизначеність

Теза звучить зручно — підключаємо будь-яку CRM без розробки. Контртеза така. Під час роботи через платформу з власним інтерфейсом частина історії живе в ній, а частина в CRM, і на питання «де повна переписка» з’являється 2 відповіді.

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

Вимога до затримки нижче секунди виключає посередника

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

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

Чого ми не перевіряли

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

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

ЧаПи:

Питання: Чи можна підключити через конектор одразу кілька месенджерів

Відповідь: Так, кожен номер підключається окремо і передає дані в ту саму CRM. Звична конфігурація для компаній із клієнтами в різних країнах виглядає як 2–3 номери різних месенджерів під однією системою

Питання: Чи збережеться можливість писати клієнту першим

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

Питання: Що станеться при збої в конектора

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

Питання: Чи потрібен програміст для налаштування

Відповідь: Для типової зв’язки ні, обидва варіанти налаштовуються через інтерфейс. Технічний спеціаліст знадобиться, якщо в CRM потрібно створювати нестандартні події або обробляти дані до передачі

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

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