AI-агент підтримки для e-commerce платформи

Підтримка в мікромобільності влаштована інакше, ніж у класичному e-commerce. Товар фізичний, розкиданий по місту й ламається — тому звернення прив'язані не до замовлення, а до конкретного пристрою та його стану просто зараз. Пік навантаження припадає на вечір і вихідні, коли зміна операторів найменша. Додайте сезонність: у теплі місяці кількість поїздок зростає в рази, а разом з ними — черга. Найняти під пік стільки ж людей неможливо, бо взимку вони будуть без роботи. Саме тому в цій ніші автоматизація підтримки дає більший ефект, ніж у магазині з коробками на складі: розрив між середнім і піковим навантаженням тут набагато глибший.

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

1. 01

   Аудит звернень

   Розібрали історію тікетів і виділили топ-інтентів, що покривають більшість черги.

2. 02

   База знань + класифікація

   Зібрали відповіді у структуровану базу знань і навчили агента визначати намір звернення.

3. 03

   Маршрутизація й ескалація

   Прописали правила: стандартне — закриває бот, складне — з контекстом іде оператору.

4. 04

   Запуск і донавчання

   Запустили на частині трафіку, зібрали помилки й ітеративно підняли точність.

AI-агент на GPT-4o всередині n8n-пайплайну підключений до Zendesk. Кожен новий тікет класифікується за наміром, агент шукає відповідь у базі знань на PostgreSQL і генерує відповідь; складні або емоційні кейси автоматично ескалюються оператору з підсумком і посиланнями.

Zendesk лишився системою обліку — агент не замінює хелпдеск, а працює всередині нього, тож оператор бачить звичну стрічку й повну історію. n8n узяв на себе оркестрацію, бо кожен тікет проходить кілька кроків із розгалуженням: класифікація, пошук у базі, перевірка, відповідь або ескалація. Тримати таку логіку в коді означало б переписувати й передеплоювати сервіс щоразу, коли змінюється правило; у візуальному пайплайні це правка однієї ноди. PostgreSQL під базу знань, а не векторну БД як окремий сервіс: обсяг відповідей вимірюється тисячами, а не мільйонами, і pgvector усередині наявної бази прибирає ще одну систему з переліку того, що треба підтримувати. GPT-4o обрали за поєднання якості української мови й швидкості — у підтримці затримка відповіді відчувається сильніше, ніж останні відсотки точності.

• Бот, який не вміє здаватися

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

• База знань, що застаріває мовчки

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

• Метрика, яка вимірює не те

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

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

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