Клієнти пишуть у месенджери (Telegram, WhatsApp та інші) із запитаннями про товар і замовлення, але менеджери не встигають відповідати в пік, вночі та у вихідні, а оформлення часто розпадається на кілька розрізнених повідомлень.
Зібрали AI-консультанта зі спільним ядром для різних каналів: модель веде розмову і підбирає товар за каталогом і базою знань, а суму, адресу, рахунок і підтвердження оплати рахує окремий детермінований код; складні й нетипові випадки передаються менеджеру разом із резюме діалогу.
Типові запитання про наявність, ціну й оформлення обробляються автоматично в будь-який час доби, а в CRM і до менеджера надходить уже зібране замовлення - сума, адреса, склад, без ручного розбору переписки.
Клієнт пише тоді, коли менеджера може не бути
Значна частина покупців інтернет-магазину починає вибір не на сайті, а в месенджері. У Telegram, WhatsApp та інших каналах вони питають, чи є товар, скільки він коштує, який варіант підійде, як оплатити і коли прийде доставка Україною через Нову Пошту.
У пік менеджери не встигають відповідати всім. Уночі та у вихідні питання може лишитися без відповіді, а до робочого ранку клієнт уже піде в інший магазин. Навіть коли менеджер на місці, добір забирає час: потрібно знайти відповідну модель, перевірити варіацію та залишок, потім зібрати з переписки контакти, адресу і склад замовлення.
Оформлення часто розпадається на кілька повідомлень. В одному клієнт назвав товар, в іншому - місто, у третьому - відділення, а підтвердження оплати надіслав ще пізніше. Автоматизувати таку розмову однією формою не можна: людина пише вільно, уточнює, змінює рішення і повертається за кілька годин.
Для цього потоку зібрали одного AI-консультанта зі спільним ядром для різних каналів. Він веде розмову і допомагає обрати. Усе, де помилка впливає на гроші, доставку чи склад замовлення, винесено у звичайний передбачуваний код або передається менеджеру.
Одна переписка проходить через кількох виконавців
Візьмемо клієнта, який питає про товар та його варіанти. Модель розуміє питання і вирішує, які дані їй потрібні. Вона може звернутися до каталогу, перевірити наявність, прочитати умови з бази знань і повернути картки з фотографією, ціною та посиланням.
Якщо клієнт визначився, розмова переходить у контур оформлення. Код рахує суму, перевіряє адресу, створює рахунок і формує структуровані дані для CRM. Якщо приходить фото, голосове чи нетипове питання, автовідповідь у цій переписці зупиняється і підключається людина.
Модель тут не сценарний бот із гілкою "натиснув А - отримав Б". Вона сама обирає інструмент під зміст репліки. Але інструмент - це не абзац у промпті, а функція над реальними даними магазину з визначеним входом і результатом.
Основна інженерна робота тому була не в підключенні готової моделі до чату. Потрібно було вирішити, які функції дати агенту, які аргументи дозволити, у якому вигляді повертати дані і як пояснити моделі межу між схожими діями. Пошук товару, уточнення конкретної варіації та відповідь із бази знань можуть виглядати для клієнта як одна розмова, але всередині це різні інструменти з різними джерелами правди.
Після виклику інструмента модель читає його відповідь і вирішує, чи достатньо даних для повідомлення клієнту. Один запит може потребувати кількох звернень: спершу знайти групу товарів, потім уточнити конкретну варіацію і лише після цього сформулювати рекомендацію.
Інструкції налагоджувалися на повідомленнях, написаних так, як люди дійсно пишуть у месенджерах: з пропущеними словами, неточними назвами і кількома намірами в одній репліці. Агент мав обрати потрібну функцію і не сплутати знання про правила магазину з фактом про наявність конкретного товару.
Каталог довелося підготувати раніше за агента
У сирому вивантаженні товари не утворюють акуратну таблицю "розмір плюс колір". В однієї категорії є розмір і матеріал, в іншої - власна вісь характеристик, у третьої частина властивостей узагалі відсутня. Варіації динамічні, і універсального набору колонок для всього асортименту немає.
Однакові моделі в різних виконаннях згрупували в одну картку. Інакше клієнт отримував би два десятки майже однакових результатів замість зрозумілого товару з варіантами. Це групування не призначали автоматично: його показували замовнику і правили, поки структура не збіглася з тим, як магазин сам розуміє асортимент.
Таке узгодження важливе, бо технічно схожі позиції не завжди є варіантами одного товару з погляду магазину. Система не намагалася самостійно винайти товарну структуру за збіжними назвами. Замовник підтверджував групи, а вже після цього вони ставали основою пошуку і карток у переписці.
Для товарів підготували описи та пошукові ознаки. З каталогу зібрали компактну карту, яку агент використовує для швидкого орієнтування. Точну ціну, характеристики конкретної варіації та залишок він усе одно запитує в бази в момент відповіді.
Послідовність пошуку принципова: спершу система лишає тільки позиції в наявності, потім шукає серед них за змістом запиту. Модель не отримує відсутній товар як допустимий результат і не може впевнено порекомендувати те, чого зараз немає на складі.
Так підготовка каталогу стає частиною якості консультанта. Акуратні групи, ознаки та актуальні залишки дають моделі матеріал для корисної відповіді, а їх відсутність нічим не компенсується.
Сильна мовна модель поверх хаотичних карток лише переконливіше переказує хаос.
Кожне суворе правило виросло з конкретної помилки
Вільний діалог робить модель корисною, але її відповіді недетерміновані. На схожі репліки вона може реагувати трохи по-різному, а невелике відхилення під час роботи з товаром іноді перетворюється на хибний кошик чи вигаданий ідентифікатор.
Агента проганяли через десятки нормальних, погано сформульованих і безглуздих повідомлень. Виправляти одну невдалу відповідь було недостатньо: після кожного класу помилок з'являлося обмеження, яке працює і в наступних діалогах.
| Спіймана помилка | Як обмежили поведінку |
|---|---|
| Модель посилалася на неіснуючий товар або ідентифікатор | Показувати й оформлювати дозволено лише позиції, які повернула база |
| У кошик потрапляла не та варіація | Після додавання агент звіряє результат із вибором, відкочує помилкову позицію і додає правильну |
| Відповідь будувалася за застарілим фрагментом пам'яті | Ціна і наявність щоразу запитуються в актуального джерела |
| Повідомлення "я оплатив" сприймалося за підтвердження | Факт оплати приходить лише від платіжного сервісу |
Клієнт цієї самоперевірки не бачить. Агент виправляє кошик і продовжує розмову далі, не перетворюючи власну помилку на окреме повідомлення і зайву тривогу.
Ці правила не роблять модель детермінованою цілком. Вони обмежують області, де свобода формулювання здатна зашкодити замовленню, і лишають гнучкість там, де вона допомагає зрозуміти людину.
Паралельно агент зберігає стан розмови: клієнт ще обирає, уже готовий оформити замовлення чи чекає на менеджера. Це не декоративна позначка. Від стану залежить допустимий наступний крок: продовжити уточнення, перейти до коду оформлення або зупинити автоматичну відповідь після передачі людині.
Суму, оплату і доставку модель не вирішує
У консультації допустимі різні формулювання: два хороші продавці теж дадуть відповідь не однаковими словами. У замовленні така свобода небезпечна. Помилка в сумі, складі чи відділенні доставки означає вже не незручну фразу, а зіпсовану покупку.
Тому система розділена на два контури:
| Завдання | AI-консультант | Детермінований код |
|---|---|---|
| Зрозуміти вільне питання | ✓ | ✗ |
| Дібрати товар і пояснити варіанти | ✓ | Отримує дані з каталогу |
| Порахувати суму | ✗ | Рахує за складом замовлення |
| Перевірити місто і відділення | ✗ | Перевіряє існування та обмеження доставки |
| Створити рахунок | ✗ | Повертає посилання на повну оплату чи передоплату |
| Підтвердити оплату | ✗ не вірить повідомленню клієнта | Отримує факт від платіжного сервісу |
| Передати замовлення | Формує контекст розмови | Надсилає поля "що, куди, кому" менеджеру і в CRM |
Для великогабаритного товару підходить не будь-яке відділення. Якщо клієнт назвав звичайне, код перевіряє обмеження і пропонує найближче вантажне. Модель не вгадує, яке відділення малося на увазі, і не підміняє перевірку красивою впевненою відповіддю.
Рахунок також створюється поза AI. Код підтримує повну оплату і передоплату, віддає посилання клієнту і чекає на підтвердження платіжного сервісу. Репліка в чаті лишається реплікою, поки зовнішнє джерело не повідомило про фактичний платіж.
Після оформлення CRM і менеджер отримують готову структуру замовлення, а не набір повідомлень, який ще потрібно розбирати вручну. AI доводить клієнта до вибору; подальші дії повторюються однаково незалежно від того, як саме була сформульована розмова.
Жорсткий кінець є і у циклі інструментів, і в пам'яті діалогу
Агент працює ітераціями: викликає інструмент, отримує результат, вирішує, чи потрібен наступний. Без обмежень він здатний застрягнути в цьому циклі і продовжувати звертатися до функцій замість відповіді клієнту.
У кожного інструмента тому є власний лічильник викликів, а в усього діалогу - спільна межа ітерацій. На останньому дозволеному кроці інструменти вимикаються. Модель зобов'язана сформувати текст із уже зібраного контексту і не може почати ще один виток.
Так технічне "мислення" отримує передбачувану межу за часом і кількістю звернень. Клієнт бачить відповідь, а витрата на модель не зростає через нескінченний внутрішній цикл.
Друга межа проходить по пам'яті. Історія в месенджері може тягнутися тижнями. Якщо щоразу передавати її повністю, відповіді стають дорожчими і повільнішими, а старі відомості продовжують впливати на новий вибір після зміни цін та асортименту.
Після паузи контекст стискається: інтерес клієнта і суттєві рішення лишаються, службові деталі та повтори відкидаються. Приблизно через добу колишня переписка відв'язується від активного контексту агента. Для клієнта вона все ще видима в чаті, але модель починає свіжу розмову без довгого хвоста.
Це водночас обмежує вартість токенів і захищає від застарілої пам'яті. Навіть якщо в короткому контексті збереглася назва товару, актуальну ціну і наявність консультант знову запитує в бази.
Обидва ліміти працюють разом. Ні довга переписка, ні складний запит не перетворюють наступну відповідь на безконтрольно зростаюче звернення до моделі.
Рушій і канал можна замінити окремо
Мовна модель підключена через адаптер і не є незамінною частиною ядра. Зараз використовуються два рушії. Сильніший обирається для складних формулювань, неоднозначних запитів і акуратного тону; дешевший закриває типові консультації за близької якості на простих діалогах.
Якщо зовнішній провайдер дорожчає, втрачає доступність або гірше справляється із завданням, рушій змінюється без переписування поведінки консультанта. Архітектура не прив'язана до конкретного тарифу: ціни й можливості моделей змінюються швидше, ніж правила магазину.
Інші рушії поки не підключалися, бо практичної потреби не було. Це не обмеження архітектури: новий провайдер входить через той самий адаптер, якщо наявні варіанти перестають влаштовувати за ціною, доступністю чи якістю. Вибір лишається операційним рішенням, а не причиною переробляти агента.
Месенджери підключені за тим самим модульним принципом. Канал приносить повідомлення у спільне ядро і повертає відповідь користувачу; каталог, база знань і правила замовлення лишаються спільними. Для нового каналу не потрібно збирати окремого консультанта зі своєю логікою.
Три уривки складаються в одну думку клієнта
Люди пишуть у месенджері не абзацами. Клієнт надсилає "привіт", потім "а таке є" і за кілька секунд "і скільки". Формально це три повідомлення, за змістом одне питання.
Поки агент обробляє поточну репліку, нові повідомлення накопичуються і переходять у наступний крок. Він не запускає три паралельних відповіді на три уривки і повертає зв'язну реакцію на думку клієнта.
Менеджер підключається разом із контекстом
Зараз агент працює з текстом. Фото і голосове він не намагається інтерпретувати навмання. Для такої переписки автовідповідь вимикається, менеджер отримує сповіщення і продовжує розмову без конкурентних повідомлень від бота.
Передача відбувається і для нетипових випадків, які не закриваються інструментами і базою знань. Людина підключається не до порожнього чату: система збирає коротке резюме про те, що клієнт шукав, які варіанти обрав чи відкинув і наскільки далеко просунувся до замовлення.
У резюме лишається й оцінка інтересу, щоб менеджер відрізнив випадкове питання від клієнта, який уже обирав конкретну варіацію. Навіть коли замовлення ще не створене, розмова продовжується з досягнутої точки, а людині не доводиться повторно питати назву товару і заново з'ясовувати потребу.
Передача менеджеру дійсно зупиняє AI у конкретній переписці. Це захищає клієнта від ситуації, коли людина і бот одночасно відповідають різне.
Навіть якщо покупка не відбулася, менеджер отримує зацікавленого клієнта з історією, а не знеособлене сповіщення "хтось щось запитав".
Незавершений кошик повертається в той самий канал
Акаунт у месенджері пов'язується з акаунтом клієнта на сайті. Якщо в кошику лишився товар, через заданий інтервал консультант може нагадати про незавершену покупку.
Повідомлення приходить туди, де клієнт спілкувався востаннє. Користувачу WhatsApp не надсилають такий самий текст ще й у Telegram. Інтервали і самі повідомлення налаштовуються в адміністративній частині.
Налаштування потрібне не лише заради тону повідомлення. Магазин визначає паузу перед наступним контактом і довжину всієї серії, не змінюючи код консультанта. Канал обирається за останньою активністю клієнта, тому один кошик не створює кількох паралельних ланцюжків нагадувань.
Серія нагадувань скінченна. Після заданої кількості спроб клієнт отримує статус неактивного, і система припиняє писати. Повернення кошика не перетворюється на нескінченний автоматичний спам.
Невдалий діалог поповнює базу знань
Якщо консультант не знайшов відповідь і передав питання менеджеру, цей випадок лишається матеріалом для покращення. Адміністрація переглядає проблемні діалоги, бачить, якого знання не вистачило, і додає його в базу.
За наступного схожого питання агент отримує нову відповідь через той самий інструмент і вже не викликає людину. Поведінка покращується через зміст бази знань, без зміни програмного коду і перенавчання моделі на кожному новому питанні.
Так межа автоматизації поступово зсувається за реальними зверненнями. Команда не намагається заздалегідь вигадати всі можливі питання, а доповнює знання там, де клієнт дійсно знайшов прогалину.
Магазин отримує консультацію будь-коли, але не автономного продавця
Типові питання, пошук за наявністю і первинний добір перестають залежати від робочого графіка менеджерів. Людина включається у складний випадок, медіа чи готове замовлення, а не повторює одні й ті самі умови доставки в кожному чаті.
Межа рішення лишається явною. AI не рахує гроші, не підтверджує оплату, не вгадує адресу і не продовжує діалог після передачі менеджеру. Він консультує в межах доступних інструментів і бази знань. Код оформлює те, що має повторюватися однаково.
Зараз медіа від клієнта лишається за людиною. Можливі наступні кроки - навчити систему розбирати такі повідомлення і глибше аналізувати діалоги. Ці функції можуть підключатися до наявних каналів і спільного ядра, але не вважаються вже реалізованою частиною проєкту.
Олександр
Замовник дозволив показати цей кейс із технічними подробицями, тож розкриваємо більше, ніж зазвичай. Але ім'я замовника та його комерційні деталі ми все одно не називаємо - лише технічний бік рішення.