Налаштування маршрутизації дзвінків у Bitrix24: повний посібник

Чому маршрутизація дзвінків у Битрикс24 дає збої

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

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

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

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

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

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

Що дає продумана схема розподілу викликів

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

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

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

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

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

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

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

Режими розподілу викликів: порівняння варіантів

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

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

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

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

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

Етапи робіт у Битрикс24: аудит, схема, налаштування, передача

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

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

Комплект документації та налаштувань після впровадження

Налаштування маршрутизації дзвінків у Битрикс24 закінчується не ввімкненням черги, а передачею робочого комплекту. Без нього через місяць ніхто не пам'ятає, чому при недодзвоні виклик іде на другу лінію, і будь-яка правка починається з розбору логіки заново. Нижче — те, що залишається у вашої команди після здачі.

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

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

Кейс: відділ продажів перестав втрачати вхідні виклики

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

У час пік та в обід дзвінки йшли в нікуди — на ранок у звітах залишалося 30-40% пропущених, а відновити, хто і коли не передзвонив, було нічим: історія дзвінків не пов'язувалася з карткою клієнта. Частина звернень зависала між менеджерами — кожен вважав, що клієнта веде колега.

Що змінили

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

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

Що стало

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

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

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

Що робити, якщо телефонія налаштована, але виклики губляться?

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

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

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

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

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

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

Часті технічні питання перед налаштуванням телефонії

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

Як налаштовуються часові пояси?

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

Записи розмов не перевантажать систему?

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

Що з навантаженням на лінію?

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

Обговорімо вашу схему обробки викликів

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

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

Достатньо надіслати:

• Структуру підрозділів і ролі: хто телефонує, хто відповідає на вхідні, де потрібні чергові лінії.
• Чинні правила розподілу: черги, групи, пріоритети, час очікування і що відбувається при недодзвоні.
• Канали зв'язку: міські та мобільні номери, месенджери, додаткові — із позначкою, які вже підключені до Битрикс24.
• Графіки роботи та винятки: перерви, вихідні, свята, переадресація на чергового.
• Куди потрапляють підсумки розмови: картка угоди, звіт, зовнішня система, вимоги до журналу дзвінків.
• Обмеження: права операторів, доступи, інтеграція з 1С або обліковою системою, вимоги до запису розмов.

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