Підключення WhatsApp до Бітрікс24: де губиться листування
Клієнт пише у WhatsApp — це найшвидший канал, який він обирає сам. Менеджер відповідає з особистого номера, і в Бітрікс24 залишається лише позначка «дзвінок відбувся». Листування з клієнтом у месенджері живе в телефоні співробітника, а не в картці угоди.
Далі починається тиха втрата звернень. Клієнт повертається із питанням, яке обговорювали тиждень тому, а підняти історію нічим: повідомлення в чужому телефоні, вкладення в чужій галереї, домовленості ніде не зафіксовані. Під час передачі угоди колега бачить порожню картку й ставить клієнту ті самі питання знову.
Окрема ціна — звільнення. Особистий номер менеджера йде разом із ним: зникає все листування за активними угодами, а клієнти продовжують писати в той самий чат і не отримують відповіді. Відновити це з Бітрікс24 неможливо — там цих даних просто не було.
Технічно розрив пояснюється тим, що в месенджера й CRM немає спільної точки входу. Повідомлення не прив’язуються до контакту й угоди, у клієнта немає єдиного ідентифікатора — та сама людина заводиться в базі кілька разів, а відповідального менеджера доводиться визначати вручну.
Підключення WhatsApp до Бітрікс24 закриває саме цю точку: номер стає корпоративним, листування потрапляє в картку, історія залишається в компанії, а не в співробітника. Розбираємо, як це влаштовано і що змінюється в роботі відділу.
Що змінюється після перенесення листування в картку угоди
Діалоги з месенджера потрапляють не в телефон менеджера, а в картку угоди в Бітрікс24 — і далі працюють як частина клієнтської історії. Нижче — що змінюється у вимірюваних величинах, а не у відчуттях.
Єдине вікно листування замість особистих телефонів
Звернення з усіх каналів сходяться в одному місці з прив’язкою до клієнта й угоди. Частка діалогів зі збереженою історією наближається до 100% — незалежно від того, хто відповідав і чи змінювався відповідальний під час листування.
Час першої відповіді перестає бути сліпою зоною
Раніше показник ніхто не рахував: відповідь ішла з особистого месенджера, слідів не залишалося. Тепер у кожного листування є позначка першого дотику — видно не лише середнє, а й хвіст: скільки діалогів висіло без відповіді довше години.
Історія звернень живе в угоді, а не в телефоні
Під час зміни відповідального, звільнення співробітника або повернення клієнта через місяць контекст залишається на місці — від першої заявки до останньої домовленості. Зникають повторні уточнення й втрата обіцянок, які дали клієнту в листуванні.
Розподіл діалогів за правилами, а не за удачею
Маршрутизація налаштовується за напрямом, навантаженням і графіком змін: діалог іде вільному співробітнику, а не тому, хто першим помітив повідомлення. Покинутих діалогів стає менше, а клас відмов «клієнт писав, але ніхто не побачив» зникає зі статистики.
Канали зв’язку з клієнтом: офіційний доступ і сторонні шлюзи
Підключення WhatsApp до Бітрікс24 вкладається в три сценарії, і вибір між ними диктує не інтерфейс, а вимоги до робочого номера й обсягу листування.
Офіційний канал зв’язку йде через провайдера платформи: бізнес-акаунт проходить верифікацію, номер закріплюється за компанією, а діалог із клієнтом потрапляє в картку угоди.
Обмеження інтеграції задає сама платформа: вихідні поза відкритим вікном діалогу йдуть лише за заздалегідь затвердженими шаблонами, а на номер накладено ліміт нових звернень.
Сторонній шлюз-посередник, наприклад Wazzup, верифікацію обходить, але працює через неофіційний клієнт — статуси доставки й шаблони недоступні, а номер живе під ризиком блокування.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Офіційний доступ через провайдера | Регулярні вихідні, кілька операторів, потрібна звітність за діалогами | Верифікація бізнес-акаунта, затвердження шаблонів, окремий робочий номер |
| Сторонній шлюз-посередник | Швидкий старт, вхідний потік, перевірка гіпотез за каналом | Немає статусів доставки й шаблонів, ризик блокування номера, розрив у підтримці |
| Ручне перенесення листування | Поодинокі звернення, менеджер веде діалог із телефону | Історія не потрапляє в картку повністю, немає прив’язки до угоди й загальної картини за навантаженням |
Робочий номер — головний ресурс у цій схемі: окрема лінія під канал переживає зміну оператора й не тягне за собою особисте листування співробітників. Ручне перенесення залишається тимчасовим заходом на період запуску, а не постійною схемою роботи відділу.
Порядок впровадження каналу зв’язку в Бітрікс24
Підключення каналу — не встановлення віджета, а узгодження того, хто і за який час відповідає на звернення. Спочатку розбираємо, як діалоги йдуть зараз: які номери задіяні, які запити йдуть у месенджер, де листування губиться між відділами.
- Аудит сценаріїв звернень. Перелік номерів, типових запитів і точок передачі — від першого повідомлення до угоди. Відокремлюємо те, що доцільно вести в месенджері, від пошти й телефонії.
- Схема маршрутизації діалогів. Розподіл за лініями й відповідальними, ескалація, робота поза графіком. Узгоджуємо до ввімкнення — інакше діалоги йдуть у загальну чергу й губляться.
- Налаштування каналу. Прив’язуємо номер через офіційний API або провайдера-інтегратора Wazzup, проходимо верифікацію, задаємо шаблони й правила відповіді за межами відкритого вікна листування.
- Налаштування прав доступу. Ролі й видимість діалогів, доступ до вкладень та історії, зв’язок листування з карткою клієнта й угодою.
- Приймальна перевірка на живих діалогах. Проганяємо гілки тестовими зверненнями: новий і повторний клієнт, неробочий час, недоступний оператор, вкладення. Дивимося, що доходить до угоди без втрат.
- Навчання й передача. Регламент відповідей, інструкції операторам, розбір частих помилок; супроводжуємо перші дні роботи каналу.
Далі канал живе на підтримці: правки маршрутизації, нові шаблони й розбір інцидентів вносимо без зупинки листування з клієнтами.
Комплект постачання: шаблони, права доступу, регламенти
Робота закінчується не повідомленням «канал підключено», а пакетом налаштувань і документів, з яким відділ працює далі без нас. Нижче — що саме залишається в замовника на руках після здачі й що ми перевіряємо на прийманні.
- Налаштовані канали й черги. Офіційний API і Wazzup розведені за номерами, діалоги розподіляються за лініями й відділами; переадресація в неробочі години й при переповненні черги задана й перевірена на тестових зверненнях.
- Матриця доступу. Ролі описані за принципом мінімально потрібних прав: оператор бачить лише свої лінії, старший зміни — усі діалоги відділу, шаблони й правила правлять один-два адміністратори. Права видані групам, тому при звільненні доступ знімається разом з обліковим записом, а не вручну по кожному каналу.
- Шаблони повідомлень. Привітання, відповідь у неробочий час, статуси за заявкою, запит відсутніх даних і згод — із підстановкою полів з картки, щоб оператор не набирав текст вручну й не втрачав час на однотипних відповідях.
- Регламент ескалації. Зафіксовано, що вважаємо пропущеним діалогом, скільки часу дається на першу відповідь, коли підключається старший зміни й кому йде повідомлення; канал ескалації продубльовано поза месенджером.
- Інструкція для співробітників. Короткий документ зі скриншотами: як прийняти діалог, надіслати шаблон, зафіксувати результат в угоді, що робити при помилці надсилання. Лежить у базі знань Бітрікс24, оновлюється разом із правилами.
- Дії при збоях. Описано порядок при закінченні токена, зміні номера й блокуванні з боку месенджера: хто отримує повідомлення, як переключити лінії на резервний канал і не втратити відкриті діалоги.
- Історія та вивантаження. Зазначено, де зберігається листування, як долучити його до угоди й як вивантажити для розбору спірних випадків.
Комплект передаємо в робочому вигляді: проганяємо сценарії на тестових зверненнях, перевіряємо потрапляння повідомлень у картки й лише після цього закриваємо здачу.
Кейс: листування з месенджера переїхало в картки угод
До впровадження
Замовник — оптова компанія з відділом продажів із кількох людей. Звернення в WhatsApp ішли на особисті телефони менеджерів: клієнт писав тому, чий номер зберіг, а діалог жив поза системою.
Під час відпустки або звільнення співробітника листування залишалося в його телефоні, і клієнт губився — за оцінкою керівника, без відповіді залишалася приблизно половина звернень.
Що змінили
Робочі номери підключили через офіційний API і прив’язали до Бітрікс24. Вхідне повідомлення створює угоду або чіпляється до наявної за номером телефону, чергування розподіляє діалоги з правилом переадресації, якщо відповіді немає довше заданого часу. Типові питання закривають шаблони, уся історія листування залишається в картці.
Що вийшло
Час першої відповіді скоротився з кількох годин до хвилин, а частка звернень без відповіді — з половини до нуля: у кожного діалогу є власник і строк реакції.
Менеджери більше не перемикаються між особистим телефоном і карткою, тому один співробітник веде більше діалогів без зростання навантаження.
Контроль якості став вимірюваним: керівник бачить усі діалоги, а не лише ті, що вирішили показати. Вибіркова перевірка відповідей і звіт за часом реакції показують, де просідає регламент — раніше оцінка будувалася на словах співробітників.
Чим офіційний канал відрізняється від стороннього шлюзу?
Обидва шляхи заводять листування в Бітрікс24, але влаштовані по-різному. Офіційний канал — підключення через провайдера-партнера: номер верифікується на боці WhatsApp і отримує підтверджений профіль компанії.
Сторонній шлюз тримає відкриту сесію веб-клієнта й пише від імені номера так, як це робив би оператор у браузері.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Офіційний канал | Розсилки, кілька операторів, зв’язка з угодами | Верифікація бізнесу й узгодження шаблонів, запуск займає тижні |
| Сторонній шлюз | Пілот, малий потік діалогів, швидка перевірка гіпотези | Сесія живе до перезапуску пристрою, при масовому надсиланні номер іде в блокування |
Ризик блокування — головна розбіжність. Офіційний канал не скасовує скарг отримувачів, але працює за опублікованими правилами: є попередження, обмеження швидкості й шлях відновлення.
Шлюз вимикає автоматика й мовчки — у логах лише розрив сесії, а разом із номером губиться історія діалогів.
За строками запуску розрив у рази: шлюз піднімається за години, офіційний канал — тижні на верифікацію й шаблони.
Зате підтримка влаштована зворотним чином: шлюз лагодять після кожного оновлення веб-клієнта й заново авторизують номери, офіційному каналу це не потрібно — зусилля йдуть на якість шаблонів, а не на утримання сесії.
Обираємо за задачею: пілот із невеликим потоком перевіряємо на шлюзі, а розсилки, кілька операторів і зв’язку з угодами ведемо через офіційний канал — інакше економія на старті обертається втраченим номером і повторним запуском.
Технічні сумніви перед стартом: розбір частих питань
Перед стартом керівник напряму зазвичай перевіряє кілька речей: чи не загубиться історія діалогів, як уживуться кілька номерів, хто відповідає за чергу і що робити з уже працюючою інтеграцією. Відповіді нижче визначають обсяг робіт і порядок запуску.
Чи перенесеться історія листування?
При підключенні через офіційний API діалоги потрапляють у картку клієнта: видно, з якого номера писали, що обговорювали, які файли надсилали.
Глибину вивантаження канал обмежує, тому старий масив листування переносимо окремим архівом і пов’язуємо з контактами — менеджер бачить контекст, а угода не починається з чистого аркуша.
Чи можна підключити кілька номерів?
Так, кожен номер заводиться окремим каналом зі своїми правами, шаблонами й підписом. Діалоги не змішуються: клієнт бачить, на який номер писати, а оператор — з якої лінії надійшов запит.
Номери можна розвести за напрямами, регіонами або юрособами, зберігши загальну звітність в одному вікні.
Як налаштовуються черги й відповідальні?
Черга описується правилами: спочатку відповідає менеджер, закріплений за клієнтом, якщо відповіді немає — запит іде в загальну лінію й піднімає повідомлення керівнику. У кожного діалогу з’являється власник, а навантаження розподіляється за змінами без ручного контролю.
У нас уже налаштована інтеграція — усе переробляти?
Не обов’язково. Спочатку розбираємо поточну схему: якщо вона тримається на неофіційному каналі, переносимо номери, шаблони й сценарії на офіційний API поетапно, залишаючи стару лінію в резерві до перевірки на живих діалогах. Боти, воронки й бізнес-процеси при цьому зберігаються.
Обговоримо задачу й повернемося з оцінкою та планом робіт
Щоб ми повернулися зі схемою підключення й планом робіт, а не із загальними словами, достатньо вихідних даних за вашим контуром. Опишіть у вільній формі, як зараз влаштована робота зі зверненнями: які номери задіяні, хто відповідає, на якому кроці клієнт найчастіше зникає. Цього достатньо, щоб зібрати робочу схему, а не типову.
- Поточні номери та їхній статус: особистий номер, прив’язаний до акаунта, або бізнес-профіль із підтвердженням — від цього залежить маршрут підключення й строки.
- Сценарії звернень: приймання заявок, статуси угоди, нагадування, розсилки по базі — які шаблони потрібні й де відповідь має йти без оператора.
- Ролі співробітників: хто володіє діалогом, хто бачить листування, хто закриває угоду — звідси будується розподіл звернень усередині системи.
- Точки контролю: швидкість першої реакції, якість відповідей, ескалація при мовчанні клієнта — їх фіксуємо в плані як критерії приймання.
- Доступи на вашому боці: хто видає права на акаунт і погоджує тексти шаблонів, щоб не стати на середині робіт.
- Обмеження: що не можна змінювати в поточних процесах і які інтеграції вже працюють і чіпати їх не можна.
Далі ми описуємо схему підключення цілком: приймання повідомлень, зв’язку з CRM, зберігання історії листування, регламент шаблонів і порядок відкату, якщо сценарій піде не так.
План робіт розбиваємо на етапи з точками контролю на кожному — результат перевіряємо до старту наступного, а не в кінці проєкту.
Опишіть задачу — повернемося з оцінкою, схемою підключення й планом робіт за етапами.
