ШІ-асистент для інтернет-магазину: від пошуку товару до підтримки після покупки

Покупець заходить в інтернет-магазин і пише: «Потрібні легкі водостійкі кросівки для подорожі, бюджет до 4 000 гривень». Звичайний пошук намагається знайти точний збіг слів у назвах і описах. ШІ-асистент може уточнити розмір, сезон та умови використання, підібрати релевантні товари, перевірити наявність і пояснити різницю між моделями.

З боку користувача це виглядає як проста розмова. З боку бізнесу — як робота декількох систем: каталогу, пошуку, залишків, цін, кошика, CRM, доставки та бази знань. Саме тому AI shopping assistant не можна зводити до віджета чат-бота, який відповідає на загальні запитання.

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

Чим ШІ-асистент відрізняється від звичайного чат-бота

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

ШІ-асистент може:

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

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

Архітектура AI shopping assistant

Практичну архітектуру можна представити як ланцюжок:

Чат або голос → визначення наміру → каталог і пошук → ціни та залишки → кошик → CRM/підтримка → аналітика.

Кожен етап має окрему відповідальність.

Канал взаємодії

Асистент може працювати на сайті, у мобільному застосунку, месенджері або контакт-центрі. На старті краще обрати один канал із найбільш зрозумілим сценарієм і стабільними даними, а не запускати все одночасно.

Рівень наміру

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

Каталог і пошук

Для пошуку асистенту потрібні структуровані назви, категорії, атрибути, описи, сумісність і зв’язки між товарами. Якщо дані каталогу неповні, AI не виправить проблему — він лише сформулює невпевнену відповідь більш природною мовою.

Операційні дані

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

Дії

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

Дані, без яких асистент не працюватиме надійно

Перед вибором моделі потрібно провести аудит даних.

Мінімально потрібні:

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

Важливо визначити джерело правди для кожного типу інформації. Каталог може бути головним для характеристик, ERP — для залишків, CRM — для статусів роботи з клієнтом, а служба доставки — для термінів. Якщо джерела суперечать одне одному, асистент повинен знати пріоритет або повідомляти, що дані потрібно уточнити.

Розумний пошук і підбір товарів

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

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

Корисний процес виглядає так:

1. Визначити основну потребу.
2. Уточнити критичні параметри.
3. Застосувати фільтри до реального каталогу.
4. Перевірити наявність і ціну.
5. Пояснити різницю між декількома варіантами.
6. Запропонувати наступну дію — відкрити картку або додати товар до кошика.

Якість такого пошуку напряму залежить від семантики й таксономії. Саме тому робота над семантикою інтернет-магазину стає основою не лише SEO, а й AI-пошуку.

Робота з кошиком і checkout

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

Для операцій із кошиком потрібні:

• явна ідентифікація користувача або сесії;
• перевірка ціни та наявності перед дією;
• підтвердження складу кошика;
• журнал виконаних операцій;
• обробка помилок і повторних запитів;
• захист від дублювання дії;
• перехід до стандартного захищеного checkout.

Асистент може допомагати, але фінансові операції повинні залишатися в платіжній інфраструктурі магазину. Мовна модель не повинна бачити або обробляти реквізити картки.

Інтеграція з CRM і підтримкою

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

Разом із передачею в CRM корисно надсилати:

• коротке резюме звернення;
• визначений намір;
• товари, які переглядав користувач;
• виконані кроки;
• причину передачі;
• рівень упевненості;
• контактні дані лише після згоди користувача.

Менеджер повинен бачити, що саме сказав AI, і мати можливість виправити відповідь. Такі виправлення стають матеріалом для покращення бази знань і сценаріїв.

Права доступу та приватність

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

Потрібно визначити:

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

Національний інститут стандартів і технологій США (NIST) пропонує розглядати ризики ШІ через постійний цикл: керувати, описувати контекст, вимірювати й реагувати. Для e-commerce це означає, що перевірка не закінчується після запуску — відповіді, помилки, доступи та вплив на користувачів потрібно контролювати постійно.

Що робити з невпевненими відповідями

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

Практичні правила:

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

Як запустити MVP поетапно

Найбезпечніше починати з вузького сценарію.

Етап 1. Довідкова підтримка

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

Етап 2. Пошук і порівняння

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

Етап 3. Кошик

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

Етап 4. Післяпродажний сервіс

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

Такий підхід дозволяє перевірити користь на реальних даних і не відкривати системі зайві дозволи на першому етапі.

Як вимірювати ефективність

Кількість діалогів сама по собі нічого не говорить про результат. Потрібно пов’язати поведінку асистента з бізнес-воронкою та якістю сервісу.

Корисні KPI:

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

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

Типові помилки впровадження

Найчастіші проблеми виникають, коли бізнес:

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

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

Як GL.ua підходить до AI в e-commerce

Для GL.ua AI-інтеграція — це не окремий віджет, а частина цифрової архітектури. Спочатку потрібно визначити бізнес-сценарій, джерела даних, дозволи й показники. Потім — підключити каталог, пошук, CRM та інші системи так, щоб кожна відповідь спиралася на актуальну інформацію.

Додатковий контекст про роль AI та мобільних каналів можна знайти у статті про еволюцію e-commerce. Якщо компанії потрібен власний асистент, варто почати з аудиту даних і одного вимірюваного сценарію. Так бізнес швидко побачить реальну користь і не створить систему, яку складно контролювати.