Drift AI у продажах: де ламається обробка лідів
Вхідний потік у чаті майже ніколи не збігається з графіком відділу продажів. Звернення надходять уночі, у вихідні та в пікові години, а перша відповідь, як і раніше, залежить від того, чи є вільний менеджер біля екрана.
Людина, яка пише до двох-трьох компаній поспіль, залишається з тим, хто відповів раніше, — тому кожна хвилина очікування знижує шанс на діалог.
Найдорожча частина — втрата заявок поза робочим часом. Нічний запит потрапляє в чергу, чекає ранку, а на відкриття зміни частина таких звернень уже неактуальна: клієнт закрив питання сам або пішов до конкурента.
При цьому воронка виглядає рівною — втрат у звітах майже не видно, бо звернення формально отримано й лежить у CRM.
Друге вузьке місце — ручна кваліфікація запитів. Менеджер витрачає перші хвилини діалогу на уточнення задачі, регіону, обсягу й терміновості, а до суті доходить уже на третьому-четвертому повідомленні.
Якщо кваліфікація не описана формалізовано, швидкість першої відповіді просідає за будь-якого сплеску навантаження, а нецільові звернення з'їдають час нарівні з цільовими.
Drift AI закриває обидві точки: приймає звернення цілодобово, ставить уточнювальні питання й передає менеджеру вже розібраний запит із контекстом діалогу. Далі розбираємо, як це влаштовано і де саме ламається обробка вхідних лідів, якщо її залишити на ручному розборі.
Що змінюється після впровадження: вимірювані ефекти
Після запуску Drift AI метрики змінюються не одразу: перші тижні йдуть на налаштування сценаріїв кваліфікації за реальними діалогами. Далі ефект видно в чотирьох точках воронки, і щодо кожної є замір до й після.
Час реакції на запит
Перша відповідь надходить за 20–40 секунд у будь-який час доби: асистент підхоплює звернення, ставить уточнювальні питання, фіксує контекст у картці. До впровадження реакція займала від 15 хвилин до кількох годин, а у неробочий час — до ранку.
Частка кваліфікованих лідів
Сценарій кваліфікації відсіює звернення без вираженої потреби та повноважень ухвалити рішення до передачі менеджеру. Частка звернень, що доходять до розмови з людиною, зростає приблизно вдвічі — час іде на тих, хто готовий обговорювати умови.
Нічні та вихідні звернення
Заявка, залишена пізно ввечері, більше не чекає ранку: діалог починається одразу, а на початок робочого дня менеджер отримує листування з відповідями на типові питання. Це закриває клас втрат, який у звітах виглядав як низька конверсія каналу.
Навантаження та конверсія в угоду
Асистент веде первинний діалог і передає вже прогрітий контакт, тому на одного менеджера припадає у 2–3 рази більше одночасних діалогів без падіння якості.
Конверсія діалогу в угоду зростає завдяки швидкості відповіді та відсутності пауз; заміряємо ті самі метрики, які ви ведете зараз.
Порівняння режимів підключення до каналів продажів
Канали продажів підключаються до Drift AI по-різному, і вибраний режим визначає, що закривається налаштуванням в інтерфейсі, а що потребує розробки.
Це і є межа сумісності: сайт, месенджери та пошта зазвичай піднімаються штатними засобами під кожен канал комунікації, а нестандартні кроки процесу виносяться в код.
| Варіант впровадження | Коли підходить | Обмеження |
|---|---|---|
| Готові сценарії діалогу | Потік однотипних звернень: первинна кваліфікація, запис на зустріч, відповіді на часті питання | Розгалуження фіксоване; умови угоди та внутрішні правила не закладаються в нього без доопрацювання |
| Налаштування під процес продажів | Є воронка з етапами, правила розподілу за менеджерами, обмін даними з обліковою системою через штатні засоби | Працює в межах підтримуваних полів і подій; логіка одразу за кількома системами впирається в обмеження налаштування |
| Розробка під нестандартний процес | Кілька агентів в одному ланцюжку, власний скоринг, нестандартний канал або облікова система | Потрібні доступи до зовнішніх сервісів і тестовий контур; вищі вимоги до документації та супроводу |
Змішаний режим трапляється найчастіше: типові гілки беремо готовими, вузли з нестандартною логікою дописуємо окремо. Перехід між режимами не потребує переписувати діалоги заново — сценарії переносяться, змінюється лише спосіб розширення.
На старті фіксуємо канал і етап воронки, який закриваємо першим: це дає робочий результат без повної переробки процесу продажів.
Етапи впровадження: від аудиту сценаріїв до передачі
Аудит воронки продажів — це не інтерв'ю про цілі, а розбір фактичних даних. Ми вивантажуємо історію діалогів і угод, позначаємо, на якому кроці листування обривається, які питання повторюються найчастіше і де відповідь виходить за межі розумного часу очікування.
За цими точками й збирається схема діалогових сценаріїв: кожна гілка прив'язана до реального звернення, а не до формулювання з установчої зустрічі.
- Аудит воронки продажів. Розмічаємо етапи угоди, рахуємо частку звернень за кожним, знаходимо вузькі місця та типові заперечення. На виході — карта воронки з частотою та причинами обривів.
- Схема діалогових сценаріїв. Будуємо дерево: кваліфікація ліда, уточнювальні питання, робота із запереченням, пропозиція, передача менеджеру. Окремо прописуємо правила ескалації та заборону на обіцянки поза погодженим списком.
- Налаштування. Підключаємо джерела даних і CRM, задаємо тон і ролі, обмеження за темами, сценарії для повернення «мовчазного» діалогу.
- Тестування на реальних зверненнях. Проганяємо сценарії на архіві діалогів, потім вмикаємо на частині трафіку. Заміряємо частку звернень, закритих без людини, і час першої відповіді.
- Калібрування. Правимо формулювання за логами, налаштовуємо поріг передачі оператору, прибираємо гілки, які ведуть у глухий кут.
- Передача. Віддаємо доступи, документацію за сценаріями та регламент їх оновлення, навчаємо команду замовника.
Такий порядок дає передбачуваний результат: до запуску видно, які звернення підуть людині, а які закриються автоматично.
Що залишається у замовника після здачі проєкту
Ми не вважаємо проєкт із Drift AI закритим у той момент, коли бот упевнено відповідає на тестовому діалозі. Здача — це передача комплекту, за яким ваша команда сама змінює сценарії, розбирає спірні звернення й оновлює логіку без звернення до нас.
Кожен артефакт перевіряємо на прийманні: якщо за документом не можна відтворити налаштування з нуля на тестовому контурі, він не вважається зданим і йде на доопрацювання.
- Карта сценаріїв — усі гілки діалогу з умовами переходу: де система уточнює, де пропонує цільову дію, а де зобов'язана покликати оператора. Поруч — тексти реплік, змінні та правила їх підстановки.
- Правила маршрутизації звернень — кому надходить діалог за темою, мовою та ознаками клієнта, що відбувається поза робочим часом і за повторного звернення.
- Налаштовані інтеграції — з обліковою системою, каналами та телефонією: які поля передаються, що записується в картку, де ведеться журнал обміну.
- Документація щодо системи — схема логіки, довідник змінних, інструкції «як додати сценарій» і «як відкотити правку» з точним порядком дій.
- Регламент супроводу — які показники дивимося (частка діалогів без рішення, час першої відповіді, частка передач оператору), з якою періодичністю і хто відповідає за реакцію.
- Матриця доступів і ролі — хто править тексти, хто викочує зміни в продуктив, де зберігається історія версій і як розбирається розбіжність.
- Набір приймальних діалогів — сценарії для повторного прогону після кожної правки, щоб повернення попередньої поведінки ловилося до викочування.
Такий комплект дозволяє розвивати систему власними силами, а нас підключати точково — на нові сценарії та розбір складних випадків.
Кейс: обробка лідів на Drift AI до і після
Клієнт — постачальник промислового обладнання, близько 900 звернень на місяць із чату на сайті та в месенджерах. До проєкту діалоги вели менеджери вручну: відповідали лише у робочі години, а нічні заявки чекали ранку. Drift AI поставили першим контуром обробки, не замінюючи відділ продажів.
Що було до
38% звернень надходили поза робочим часом, і чотири з п'яти таких заявок закривалися взагалі без відповіді. Середній час першої відповіді в будні — близько шести годин, у нічних звернень — до середини наступного дня. Повторні торкання встигали робити приблизно для кожного п'ятого ліда, решта охолоджувалися мовчки.
Що змінили
Зібрали сценарії кваліфікації: уточнювальні питання про задачу, строки та конфігурацію йдуть до передачі менеджеру, тому в роботу надходить уже розібраний запит. Уночі система відповідає одразу, фіксує контакт і записує людину на дзвінок у робочі години.
Повторні торкання наступної доби й через три дні надходять автоматично за всіма незакритими діалогами.
Що стало
Перша відповідь займає 2-3 хвилини в будь-який час доби, частка звернень без відповіді впала з 31% до 4%. Кваліфікованих діалогів стало 29% проти 11%: позначається не швидкість сама собою, а те, що жоден лід не залишається без торкання.
Відділ продажів тим самим складом веде більше угод — рутина пішла в автовідповіді, а менеджери працюють із підготовленими запитами.
Що робити, якщо у нас уже розгорнуто чат-бот?
Чинний чат-бот не потрібно зупиняти, щоб підключити нову логіку. Обидва контури працюють одночасно й слухають один канал, а який обробник відповідає на конкретне звернення, вирішує маршрутизатор на вході — за типом запиту, каналом і ознакою клієнта.
Міграція сценаріїв відбувається по одному, а не одним великим перенесенням.
Кожен сценарій переноситься зі своїми умовами й формулюваннями, потім проганяється на записах реальних діалогів: відповіді нової логіки порівнюються з попередніми, розбіжності розбираються до того, як сценарій іде в бій.
Перемикання робимо частками трафіку — спочатку невелика частина звернень, потім розширення. Відкат — це зняття правила маршрутизації: старий обробник знову приймає весь потік. Простою не виникає, бо обидва контури тримають з'єднання паралельно і клієнт у чаті не помічає зміни.
Збереження історії діалогів вирішується на рівні схеми зберігання: звернення пов'язуються за ідентифікатором, а під час перемикання історія підтягується з попереднього сховища — нова логіка бачить попередні кроки й не перепитує те, що вже відомо.
Окремо перевіряємо розриви ниток і дублі, інакше клієнт отримує дві різні відповіді на одне повідомлення.
Готовність до повного переходу фіксуємо за вимірюваними ознаками: частка звернень, закритих без оператора, точність визначення наміру, час відповіді, коректність передачі контексту на живого співробітника. Так нова логіка на Drift AI вбудовується в наявний контур, а не замінює його наосліп.
Технічні сумніви перед стартом роботи
Технічні сумніви на старті майже завжди однакові: чи зрозуміє система сенс звернення, що буде зі складним питанням і де опиняться дані. Нижче — відповіді за цими пунктами стосовно Drift AI, без обіцянок «налаштуємо й запрацює».
Наскільки точно система розуміє сенс запиту?
Точність перевіряємо не «в середньому», а на розмітці ваших діалогів: окремо рахуємо частку правильно визначених намірів і ціну помилки. Хибна передача менеджеру та втрата ліда коштують по-різному, тому пороги впевненості налаштовуємо під ваш потік. Спірне формулювання потрапляє в розмітку й на донавчання, а не в «покращимо потім».
Що відбувається зі складним запитом?
Передача діалогу менеджеру — частина сценарію, а не збій: тригери за низькою впевненістю, емоційною лексикою, кількістю уточнень і явним проханням покликати людину. Менеджер отримує історію листування, зібрані поля та причину ескалації, тому не перепитує заново.
Уночі сценарій працює за окремими правилами: заявка фіксується, клієнт отримує зрозумілий строк відповіді.
Як це пов'язано з обліковою системою?
Інтеграція відбувається через інтерфейси облікової системи: статус заявки, залишки, ціни, створення угоди. Запити пишемо ідемпотентно, з журналом і повторними спробами, щоб обрив зв'язку не породив дублі.
Якщо облікова система недоступна, діалог не рветься: дані стають у чергу й надходять, коли зв'язок відновиться.
Хто відповідає за сценарії після запуску?
Сценарії — частина продукту, а не разове налаштування. Ми фіксуємо, які правки вносимо ми, а які залишаються у вашій зоні, і ведемо журнал змін із причиною кожної.
Перед викладкою сценарій проходить перевірку на тестовому наборі діалогів, щоб правка під одну ситуацію не зламала решту.
Чи можна перевірити це до повного запуску?
Так: спочатку тіньовий режим — система обробляє реальні звернення, але не відповідає клієнту, а її рішення порівнюються з роботою операторів. Так видно точність, вузькі місця та логіку ескалації без ризику для потоку. Далі вмикаємо поступово: частину каналів або частку трафіку, потім повністю.
Обговоримо задачу й повернемося з оцінкою та планом
Щоб оцінка спиралася на факти, а не на припущення, почнемо з двох речей: як сьогодні влаштовано потік звернень і хто ухвалює рішення щодо спірних діалогів.
Достатньо описати канали, типові питання, де губляться заявки і на якому кроці підключається людина — цього вистачає, щоб зібрати робочу постановку задачі.
У відповідь ви отримаєте конкретний пакет:
- схему сценаріїв під Drift AI: привітання, кваліфікація, передача менеджеру, повернення до діалогу після паузи, ескалація;
- постановку задачі з межами — які звернення закриваються автоматично, які надходять людям, що вважаємо відмовою;
- склад робіт за етапами: від розбору поточного процесу до запуску й передачі вашій команді;
- план впровадження з точками погодження та переліком того, що перевіряємо на кожному кроці;
- строки етапів із запасом на доопрацювання сценаріїв після перших реальних діалогів;
- вимоги до доступів, даних і регламенту супроводу після запуску.
Опишіть задачу у вільній формі — повернемося зі схемою сценаріїв, складом робіт і строками етапів. Далі вирішуєте ви: запускати частинами чи повністю.
