Розробка AI SDR — цифрового менеджера з продажів

Чому AI SDR не закриває ліди: де ламається воронка

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

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

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

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

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

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

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

Що дає цифровий менеджер з продажу: ефект за етапами

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

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

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

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

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

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

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

Режими роботи AI SDR: порівняння підходів та обмеження

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

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

Що обмежує автоматизацію

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

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

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

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

Етапи впровадження

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

Що залишається у замовника: сценарії, політики, документація

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

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

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

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

Кейс: як зросла частка кваліфікованих лідів

Клієнт — постачальник промислового обладнання з довгим циклом угоди. Вхідні звернення розподілялися вручну: чергу розбирали двічі на день, тому перша відповідь ішла через 4–6 годин, а частина заявок залишалася без дотику до наступного ранку.

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

Що змінили в схемі

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

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

Метрики до і після

• Час першої відповіді: 4–6 годин → 40 секунд, включно з нічними та вихідними зверненнями.
• Відвал лідів на першому кроці: 38% → 11% — частину відсіву взяла на себе кваліфікація.
• Частка діалогів, доведених до передачі менеджеру, зросла в 2,4 раза.
• Конверсія в зустріч: 6% → 14% за того ж потоку вхідних.

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

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

Чим цифровий менеджер відрізняється від чат-бота на сайті?

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

Цифровий менеджер з продажу (AI SDR) влаштований інакше. Сценарій залишається, але не як маршрут, а як рамка: які дані про задачу потрібно зібрати, що запропонувати, за яких умов зупинитися.

Сам діалог веде мовна модель — вона розуміє переформулювання і тримає мету розмови, а не номер кроку.

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

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

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

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

Сумніви інженера: доступи, дані, контроль якості

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

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

Що робити з неповною базою або дублями?

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

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

Хто затверджує формулювання і що агент не має права говорити?

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

Де зберігаються дані і хто їх бачить?

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

Обговоримо вашу задачу: оцінка, план і чек-лист старту

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

Що корисно підготувати до першої зустрічі:

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

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