Handoff to human: як бот передає розмову так щоб клієнт не відчув відмови

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

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

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

Коли handoff необхідний — і коли бот може впоратись сам

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

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

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

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

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

Коли НЕ треба передавати: клієнт дає неточний запит («типу завтра ввечері», «щось недороге»). Тут бот уточнює — «Вам ближче до 18 чи 20 годин?», «Маєте на увазі ціну до 500 грн?». Уточнення — не handoff.

Як handoff має виглядати для клієнта

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

Два варіанти тексту:

Погано:

На жаль, я не можу відповісти на це питання. Зверніться до менеджера.

Добре:

Це питання краще вирішити особисто — надішлю вашу розмову команді. Хтось зв'яжеться з вами протягом [час відповіді]. Поки чекаєте, якщо є ще питання — пишіть.

Різниця в трьох речах:

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

Час відповіді людини — важливий момент. Не обіцяйте «найближчим часом». Або конкретна цифра («протягом 2 годин у робочий час»), або чесне «відповімо в робочий час: Пн-Сб 10:00-19:00».

Механіка handoff в Telegram

Технічно у Leadmlyn handoff працює так:

Тригер. Бот визначає момент для передачі — або за правилом (explicit запит, кількість спроб), або через LLM-сигнал (емоційний тон, тема поза KB).

Сповіщення власнику / менеджеру. Надходить push у Telegram з резюме розмови: хто написав, що питав, де зупинились. Не «є нова розмова», а «Клієнт Олена запитала про корпоратив на 25 осіб з власним декором, бот не зміг дати умови».

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

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

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

Handoff як сигнал для покращення KB

Кожен handoff — це дані. Конкретно: питання або ситуація, з якою бот не впорався. Це прямий список кандидатів для оновлення KB.

Практичний процес:

Раз на тиждень відкрийте список розмов, що завершились handoff. 10-15 хвилин. Для кожної відповідайте на питання: «Якби в KB був правильний запис, бот міг би впоратись?»

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

Типова динаміка: на старті добре налаштований бот має 15-20% handoff rate. Через 6-8 тижнів регулярного аналізу і оновлень KB — 8-12%. Різниця — це десятки розмов на місяць, які бот вирішує самостійно.

Зв'язок handoff rate з KPI бота: escalation rate — це по суті ваш handoff rate. Тримайте його в полі зору щотижня.

Помилки при handoff: чого уникати

Бот каже «я не знаю» і нічого більше. Клієнт отримав порожню відповідь і не знає що робити далі. Завжди має бути наступний крок — навіть якщо це просто «напишіть нам на [номер]».

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

Відсутність сповіщення власнику. Handoff відбувся, клієнт чекає, власник не знає. Через 2 години клієнт пішов. Handoff без сповіщення — це не handoff, це ігнорування.

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

Handoff на все підряд. Якщо бот йде в handoff при кожному незрозумілому питанні — він не вирішує проблему, він її делегує. Handoff має бути свідомим, не дефолтним.

---

Якщо ви ще думаєте над тим чи потрібен бот взагалі — матеріал про AI-сценарії для leisure-бізнесу показує конкретні ситуації де бот реально заощаджує час, і ті де краще без нього. Handoff — це не ознака слабкості бота, це ознака що система продумана.