Людина пише боту: «1 не актуально, 6 теж можна закрити». Бот відповідає: «Зрозумів, більше не згадуватиму». У наступному зведенні обидва пункти знову на місці. Так у нашому внутрішньому Telegram-боті й було: багаторядкову відповідь не розпізнавав потрібний обробник, а запасний підтверджував дію, якої не виконав. Ми зафіксували цю помилку й змінили поведінку: якщо бот не може визначити пункти, він перепитує.
Це хороший тест для будь-якої пропозиції «AI-бот замінить менеджера». Поки демонстрація показує лише правильні запитання, усе виглядає блискуче. Справжня якість з’ясовується, коли людина пише не так, як передбачав сценарій. Що бот зробить тоді? Промовчить, вигадає відповідь чи передасть розмову тому, хто може допомогти?
Чат-бот - це програма, яка приймає повідомлення в месенджері або на сайті й виконує частину розмови за заданими правилами. Вона може підтвердити отримання, поставити кілька запитань, показати перевірену інформацію та передати звернення людині. AI іноді допомагає розуміти вільний текст, але сам факт використання AI не робить відповідь достовірною. Для малого бізнесу я б спочатку визначив вузьку роботу й межу відповідальності, а вже потім вибирав технологію.
1. Три рівні: від відповіді до AI-асистента
Готова автоматична відповідь не веде розмову. Вона каже, що повідомлення отримано, коли повернеться людина і де подивитися базові умови. Якщо команда працює до 18:00, фраза «Ми побачимо запит завтра до обіду» корисніша за імітацію нічного менеджера. Такий варіант часто закриває потребу без окремого бота. Ми вже розбирали, як прибрати повторні питання без складної системи.
Сценарний бот ставить запитання в певному порядку. Наприклад, з’ясовує тему звернення, місто, контакт і час для дзвінка. Після цього створює запис для менеджера. Кожна гілка має завершуватися зрозуміло: відповідь, заявка або передача людині. Кнопка «Інше», після якої немає дії, є особливо ввічливим способом загубити клієнта.
AI-асистент може інтерпретувати повідомлення, яких немає в меню, шукати в базі знань і складати відповідь природною мовою. Тут з’являються нові можливості, але й нові помилки. Якщо джерело цін застаріле, асистент упевнено назве стару ціну. Якщо він не має доступу до розкладу, не можна дозволяти йому самостійно підтверджувати вільний час. Більш гнучка розмова потребує суворішої перевірки фактів і дій.
Для всіх трьох рівнів питання однакове: що отримає клієнт, якщо запит не вкладеться в очікуваний шаблон? Відповідь «передамо людині з контекстом» зазвичай цінніша за ще один ефектний приклад генерації тексту.
2. Що можна автоматизувати, а що краще залишити людині
| Завдання | Що бот може зробити | Умова або межа |
|---|---|---|
| Підтвердити отримання | Назвати канал і очікуваний час відповіді | Не обіцяти миттєву відповідь, якщо чергового немає. |
| Дати адресу, години, перелік послуг | Показати дані зі схваленого актуального джерела | Хтось має відповідати за оновлення джерела. |
| Зібрати первинну заявку | Запитати лише потрібне, передати дані й тему | Треба перевірити доставку заявки до відповідального. |
| Спрямувати за темою | Створити задачу, запис у CRM або чергу підтримки | Помилки маршрутизації мають бути видимими. |
| Повідомити статус | Взяти статус із системи, якщо він справді оновлюється | Не відповідати «готово» лише тому, що повідомлення відправлено. |
| Назвати ціну, наявність, умови | Показати лише перевірені актуальні дані | Якщо даних немає або є суперечність, передати людині. |
| Погодити виняток, повернення грошей чи конфлікт | Зібрати контекст і покликати відповідального | Рішення та відповідальність залишаються за людиною. |
Список не означає, що кожному бізнесу потрібні всі рядки. Якщо звернень мало й кожне особливе, звичайна відповідь менеджера може бути швидшою та дешевшою. Якщо питання повторюються сотні разів, але правила змінюються щодня, спочатку наведи лад у джерелі цих правил. Бот, під’єднаний до хаосу, відповідає швидше, але не краще.
3. Дві помилки, які ми побачили на власних ботах
Першу описано на початку. Внутрішнє зведення мало пункти з номерами. Людина відповідала списком у кілька рядків, щоб закрити ті, що вже неактуальні. Розпізнавання не доходило до правильного маршруту, і старий обробник писав «більше не згадуватиму». Пункти лишалися відкритими. В історії версій зафіксовано повторення 1, 4 і 6 жовтня 2026 року. Виправлення не зводилося до красивішого тексту відповіді: ми навчили обробник працювати з кількома номерами, діапазоном і варіантами людських формулювань, а там, де номери неясні, перепитувати. Це приклад, чому підтвердження має йти після фактичної зміни стану.
Друга помилка стосувалася темпу розмови. У робочому чаті людина написала три короткі повідомлення протягом хвилини, а бот запустив три паралельні ходи й дав три відповіді. Для людини це одна думка, розділена на кілька повідомлень; для неузгодженої автоматики це три окремі запити. Ми додали коротку паузу, щоб серія потрапила в один контекст, і чергу на розмову з тією самою людиною. Це не «AI став розумнішим». Це нормальне проєктування поведінки месенджера.
Обидва випадки внутрішні. Вони не доводять результат клієнтського чат-бота і не дають підстав обіцяти певну економію часу. Але вони показують конкретні місця, які варто тестувати до того, як автоматичну відповідь побачить покупець: нерозпізнане повідомлення, кілька повідомлень поспіль і дія, яка не виконалася.
4. Що показує Klar, і чому це інший тип системи
Ми маємо опублікований кейс Klar. Це система тріажу робочої пошти, не клієнтський чат-бот. У внутрішньому пілоті вона обробляла п’ять поштових скриньок трьох компаній. 615 листів було розібрано за 12–26 червня 2026 року, а 91 задачу створено за окремий період 13 червня – 8 липня 2026 року. AI допомагав класифікувати вхідне та формувати наступну дію, а люди зберігали контроль над відповідями. Дані описують пропускну здатність внутрішнього процесу; вони не вимірюють продажі, години економії чи результат чат-бота.
Цей приклад корисний саме межею автоматизації. Система може добре сортувати й передавати роботу, не видаючи себе за людину, яка ухвалила рішення або відповіла клієнту. Такий самий принцип варто застосовувати до месенджера: прийняти запит, зберегти контекст і довести його до відповідального. Якщо звернення губляться між чатами, спершу прочитай наш розбір CRM і таблиці для заявок.
Наразі в GrandMa немає опублікованого кейсу клієнтського чат-бота. Я не хочу підміняти його цифрами поштового тріажу. Для нового бота результат доведеться виміряти в його власному маршруті: доставлені звернення, правильність відповідей, швидкість передачі, кількість розмов, які людина справді забрала.
5. Сценарій прийому заявки за шість кроків
Візьмемо звичайну задачу: людина написала в месенджер і хоче зв’язку з компанією. Не треба починати з двадцяти гілок. Спершу опиши основний шлях і випадок «не зрозумів».
- Пояснити роль. «Я автоматичний помічник. Допоможу передати запит команді». Людина відразу знає, з ким говорить і чого чекати.
- З’ясувати тему одним запитанням. Запропонувати короткі варіанти та вільну відповідь «інше». Не змушувати читати каталог послуг, якщо людина вже описала проблему своїми словами.
- Взяти мінімальний контекст. Запитати лише те, без чого менеджер не зможе відповісти: наприклад, про яку послугу йдеться та як зручно зв’язатися. Не збирати запасом паспорт, адресу й дату народження для першої консультації.
- Повторити суть перед передачею. Показати людині короткий запис, що саме піде команді. Дати можливість виправити помилку або не продовжувати.
- Створити запис і перевірити результат. Передати заявку в CRM чи робочу чергу, отримати технічне підтвердження й лише після цього сказати «передав». Якщо запис не створився, не казати «готово»: запропонувати інший контакт або викликати людину.
- Назвати очікувану відповідь. Повідомити реальний графік, канал і, за можливості, ідентифікатор заявки. Зберегти історію для менеджера, щоб він не починав розмову з «а що у вас сталося?».
Гілка «не зрозумів»: після одного невдалого уточнення бот формулює просте питання ще раз. Якщо знову немає певності, він передає оригінальне повідомлення людині. Якщо менеджер недоступний, прямо каже коли його чекати та як звернутися іншим шляхом. Це редакційний шаблон для проєктування, а не універсальний технічний протокол. Кількість спроб, терміни й винятки залежать від конкретного бізнесу.
Telegram Bot API дає програмний спосіб отримувати повідомлення й надсилати відповіді. Він не визначає, що слід вважати успішною заявкою. Правило «повідомити лише після підтвердженої дії» і маршрут передачі людині треба спроєктувати самим.
6. Як перевірити бота до першої розмови з клієнтом
Я б узяв 20 реальних повідомлень із попередніх звернень, прибрав особисті дані та розділив їх за складністю. Не копіюй живі приватні чати в сторонній сервіс без належної підстави та контролю доступу. Мета тесту - побачити різні формулювання, які люди дійсно використовують, а не красиві репліки з презентації підрядника.
Збірка може містити п’ять коротких типових питань, п’ять неточних або неповних, п’ять повідомлень із кількома темами та п’ять складних випадків: прохання змінити або скасувати щось, скарга, відсутня ціна, суперечлива умова. Додай окрему перевірку серії з двох-трьох повідомлень за хвилину. Число 20 - робочий стартовий набір, не гарантія якості після запуску.
Для кожного повідомлення заздалегідь запиши очікувану дію: відповісти з конкретного джерела, уточнити або передати людині. Потім перевір чотири речі: що бот сказав; що реально змінилося в системі; чи побачила заявку команда; чи отримала людина правдиве повідомлення про результат. Помилка в останньому пункті буває небезпечнішою за незручну фразу. Людина вірить, що запис скасовано або заявку прийнято, і перестає діяти.
Після запуску потрібен журнал помилок із прикладами, відповідальним і терміном виправлення. Тестувати лише демо «поставити три передбачені питання» недостатньо. Корисний спосіб приймати такі системи ми описали в статті про перевірку AI-агента за результатом.
7. Що попросити в підрядника перед оплатою
Попроси показати не слайд із можливостями моделі, а карту одного звернення. Від першого повідомлення до запису, який бачить відповідальний. На карті мають бути місця, де бот бере відповідь, які поля записує, як перевіряє успіх дії та що показує людині при помилці. Якщо відповідь звучить «AI сам розбереться», запитай, хто дізнається про випадок, коли він не розібрався. Без цього покупець стане безкоштовним тестувальником.
У домовленості окремо запиши, хто підтримує базу знань після запуску. Компанія змінила графік чи ціну, а бот досі цитує стару сторінку? Це вже не технічний баг моделі, а невизначений власник даних. Так само потрібні людина для складних розмов, доступ до журналу помилок і спосіб зупинити автоматичні відповіді, якщо вони шкодять. Демо може працювати ідеально п’ять хвилин; щоденна підтримка вирішує, чи буде бот корисним за місяць.
Першу оплату зручно прив’язати до перевірюваного сценарію, наприклад до двадцяти тестових повідомлень, запису заявок і передачі винятків. Це не гарантує успіху в усіх майбутніх розмовах, зате дає підставу прийняти конкретну роботу або назвати дефект без суперечки про те, чи бот «достатньо розумний».
8. Дані, прозорість і право на людину
Чесно назви бота ботом. Це допомагає клієнту правильно оцінювати відповідь. Для систем, що безпосередньо взаємодіють із людьми в ЄС, стаття 50 AI Act встановлює вимоги до інформування про взаємодію з AI; Єврокомісія вказує, що ці положення застосовуються з 2 серпня 2026 року. Які саме обов’язки має конкретний постачальник і бізнес, що використовує систему, треба оцінювати за ролями та ринком. Для звичайної сценарної автовідповіді питання правового режиму може відрізнятися, але вводити людину в оману все одно погана ідея.
Запитуй лише потрібні дані, пояснюй мету й термін зберігання відповідно до свого процесу, обмежуй доступ до історії. Кнопка «передати менеджеру» має справді передавати розмову, а не відкривати ще одне меню. Якщо AI не має надійного джерела про ціну, наявність або юридично значущу умову, нехай скаже «уточнить людина».
Якщо хочеш автоматизувати такий маршрут, почни не з назви моделі. Принеси п’ять типових звернень, опиши, куди зараз потрапляє кожне, і покажи, де губиться відповідь. На сторінці GrandMa про автоматизацію та AI-системи є наш формат роботи з такими процесами. Чесний перший результат - одна перевірена передача заявки, а не обіцянка замінити відділ продажів.