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