Налаштування мультиканального обслуговування Бітрікс24

Мультиканальне обслуговування в Битрикс24: де губляться звернення

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

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

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

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

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

Мультиканальне обслуговування в Битрикс24 збирає канали в єдине вікно оператора. Відкриті лінії приймають повідомлення, ставлять їх у чергу й розподіляють за правилами між вільними співробітниками.

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

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

Що дає мультиканальне обслуговування: ефект і метрики

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

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

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

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

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

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

Порівняння способів підключення каналів в єдине вікно

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

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

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

Що враховувати при виборі

На практиці схему збирають змішаною: відкриті канали тримають потік, зворотний дзвінок і чат закривають перший контакт, пошта та закриті лінії — персональну відповідь.

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

Етапи впровадження: від аудиту потоків до передачі в підтримку

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

1. Аудит потоків звернень. Вивантажуємо історію за всіма каналами за порівнянний період: частки каналів, пікові години, частка повторних і покинутих діалогів, час першої відповіді, точки, де звернення губиться. На виході — карта потоків із вузькими місцями.
2. Схема маршрутизації. Визначаємо правила розподілу: відповідальний за типом питання, черга очікування, ескалація за таймером мовчання, робота поза графіком. Схему погоджуємо до налаштування — правки на папері дешевші за правки в бою.
3. Налаштування каналів. Зводимо канали в єдине вікно, налаштовуємо склейку звернень одного клієнта за телефоном і адресою пошти, шаблони відповідей, автоправила та передачу звернення відповідальному. Окремо перевіряємо права за ролями та журнал дій.
4. Тестовий прогін. Проганяємо сценарії на обмеженому колі: типовий запит, повторне звернення, відмова каналу, ескалація, відповідь поза робочим часом. Дивимося, що відбувається зі зверненням при збої — воно має стати в чергу, а не зникнути.
5. Регламенти та навчання. Інструкції операторам, карта ескалацій, порядок зміни правил маршрутизації.
6. Передача в підтримку. Передаємо схему, налаштування, дашборд і регламент правок, вмикаємо контроль черг і сповіщення про збої, щоб відхилення були видні до скарг клієнтів.

Конфігурація, схеми та регламенти після здачі проєкту

Після здачі проєкту в замовника має залишитися не набір скриншотів «як було налаштовано», а робочий контур: документи, за якими новий оператор виходить на лінію, а керівник розуміє, куди йде кожне звернення. Нижче — комплект артефактів, який ми передаємо разом із доступом до системи.

• Карта каналів — перелік підключених точок входу з відповідальним за кожним: пошта, чат на сайті, месенджери, телефонія, соцмережі. Окремо фіксуємо поведінку в неробочі години та правило склейки, щоб один клієнт не заводив три паралельні діалоги.
• Схема маршрутизації — матриця «тип звернення → черга → група операторів → строк реакції» з гілками ескалації при простроченні та правилами перерозподілу при перевантаженні лінії.
• Регламент обробки звернень — етапи від першого дотику до закриття, обов’язкові поля картки, порядок передачі між лініями, умови повторного відкриття та розбір спірних випадків.
• Права доступу операторів — ролі та рівні видимості: хто працює лише зі своїми діалогами, хто бачить усю історію клієнта, хто змінює маршрути й шаблони. Доступ до звітності видаємо окремо від робочого.
• Інструкції для операторів — сценарії на одну-дві сторінки: як відповідати на типовий запит, що робити при конфлікті, кому й у який момент передавати діалог.
• Регламент змін і версії — як погоджуються нові канали та правки маршрутів, де зберігається історія налаштувань, щоб через пів року було зрозуміло, чому правило виглядає саме так.
• План дій при відмові каналу — кому телефонувати, як перемикати потік на резервну лінію, як повідомляти операторів і клієнтів.

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

Кейс: як скоротили час першої відповіді та втрати звернень

Точка відліку

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

У пікові години час першої відповіді сягав 40 хвилин, а частка втрачених звернень — тих, на які не відповіли того ж дня, — трималася на рівні 12%.

Що налаштували і що вийшло

Зібрали єдине вікно на Битрикс24: підключили відкриті лінії до чату на сайті, месенджерів, пошти та соцмереж, задали маршрутизацію за темою й поточним навантаженням операторів.

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

Через два місяці час першої відповіді в робочі години скоротився до 3-4 хвилин, частка втрачених звернень — до 1,5%. Повторні звернення знизилися приблизно на третину: питання закривалося в першому ж діалозі.

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

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

Що робити, якщо частина каналів уже підключена вручну

Ручне підключення каналу — не проблема: складність у тому, що історія листування, права операторів і правила розподілу залишаються в старому контурі. При грубому переключенні клієнт втрачає контекст звернення, а оператор — чергу.

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

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

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

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

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

Часті технічні сумніви перед стартом проєкту

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

Чи збережеться історія листування при перенесенні з поточної системи?

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

Як розподіляться звернення між операторами та змінами?

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

Чи витримає інфраструктура пікове навантаження?

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

Обговоримо задачу та повернемося з планом впровадження

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

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

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

• Порядок підключення каналів — від простого до складного: форма на сайті та пошта, потім месенджери, далі телефонія та соціальні мережі. Кожен наступний підключається на вже працюючій схемі, без зупинки обслуговування.
• Єдина стрічка звернень: лист, повідомлення та дзвінок потрапляють в одну картку клієнта з наскрізною історією листування.
• Маршрутизація: черги за темами, навантаженням і графіком, ескалація звернення, якщо відповідь не надано в заданий строк.
• Шаблони відповідей і автосценарії: привітання, уточнювальні питання, передача профільному спеціалісту, закриття з оцінкою.
• Ролі та права доступу: оператор бачить свої діалоги, керівник — навантаження за каналами, строки першої відповіді та частку пропущених.
• Точки контролю: після кожного каналу звіряємо, що звернення не дублюються й не губляться при передачі між співробітниками, заміряємо час першої відповіді до і після.
• Регламент підтримки: хто вносить правки в маршрути й шаблони після запуску, як швидко розбираються зі збоями з’єднань між системами.

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