AI-агент підтримки для e-commerce платформи
Платформа оренди мікромобільного транспорту тонула в тисячах однотипних звернень. Ми розгорнули AI-агента, який обробляє тікети, вирішує стандартні питання й ескалює складні кейси операторам.
- 11 644тікетів оброблено
- 26,5 хвсередній час відповіді
- 41,5%закрито ботом без оператора
- 4 689ескалацій до операторів на тиждень ↓
Контекст галузі
Підтримка в мікромобільності влаштована інакше, ніж у класичному e-commerce. Товар фізичний, розкиданий по місту й ламається, тому звернення прив'язані не до замовлення, а до конкретного пристрою та його стану просто зараз. Пік навантаження припадає на вечір і вихідні, коли зміна операторів найменша. Додайте сезонність: у теплі місяці кількість поїздок зростає в рази, а разом з ними й черга. Найняти під пік стільки ж людей неможливо, бо взимку вони будуть без роботи. Саме тому в цій ніші автоматизація підтримки дає більший ефект, ніж у магазині з коробками на складі: розрив між середнім і піковим навантаженням тут набагато глибший.
Задача
Команда підтримки отримувала тисячі звернень на місяць, переважно однотипних: статус замовлення, поломки, повернення, оплати. Оператори витрачали більшість часу на копіпаст відповідей, час реакції зростав у пікові години, а складні кейси губилися в загальній черзі.
Підхід
- 01
Аудит звернень
Розібрали історію тікетів і виділили топ-інтентів, що покривають більшість черги.
- 02
База знань + класифікація
Зібрали відповіді у структуровану базу знань і навчили агента визначати намір звернення.
- 03
Маршрутизація й ескалація
Прописали правила: стандартне закриває бот, а складне з контекстом іде оператору.
- 04
Запуск і донавчання
Запустили на частині трафіку, зібрали помилки й ітеративно підняли точність.
Як працює рішення
- 01ZendeskНадходить новий тікет
- 02n8n + GPT-4oВизначає намір звернення
- 03PostgreSQLШукає відповідь у базі знань
- 04GPT-4oГотує відповідь клієнту
- 05ОператорОтримує складні кейси з підсумком
AI-агент на GPT-4o всередині n8n-пайплайну підключений до Zendesk. Кожен новий тікет класифікується за наміром, агент шукає відповідь у базі знань на PostgreSQL і генерує відповідь; складні або емоційні кейси автоматично ескалюються оператору з підсумком і посиланнями.
Чому саме такий стек
Zendesk лишився системою обліку: агент не замінює хелпдеск, а працює всередині нього, тож оператор бачить звичну стрічку й повну історію. n8n узяв на себе оркестрацію, бо кожен тікет проходить кілька кроків із розгалуженням: класифікація, пошук у базі, перевірка, відповідь або ескалація. Тримати таку логіку в коді означало б переписувати й передеплоювати сервіс щоразу, коли змінюється правило; у візуальному пайплайні це правка однієї ноди. PostgreSQL під базу знань, а не векторну БД як окремий сервіс: обсяг відповідей вимірюється тисячами, а не мільйонами, і pgvector усередині наявної бази прибирає ще одну систему з переліку того, що треба підтримувати. GPT-4o обрали за поєднання якості української мови й швидкості: у підтримці затримка відповіді відчувається сильніше, ніж останні відсотки точності.
Де такі проєкти зазвичай ламаються
Бот, який не вміє здаватися
Найдорожча помилка полягає в тому, щоб змусити агента відповідати завжди. Клієнт із поламаним пристроєм посеред вулиці, якого бот тримає в циклі уточнень, обходиться дорожче за десяток нерозв'язаних тікетів. Поріг впевненості й миттєва ескалація важливіші за відсоток автоматизації.
База знань, що застаріває мовчки
Тарифи, зони паркування й умови повернення змінюються, а база лишається старою. Агент упевнено відповідає торішніми правилами, і це виявляється лише зі скарг. Потрібен власник бази й регламент оновлення, інакше точність спадає непомітно.
Метрика, яка вимірює не те
Частка закритих ботом виглядає переконливо, доки не з'ясується, що частина «закритих» тікетів просто відкривається знову під іншим номером. Рахувати треба повторні звернення того самого клієнта, а не самі закриття.
Результати
| Було | Стало |
|---|---|
| Оператори копіпастили однотипні відповіді | 41,5% звернень закриває агент без оператора |
| Складні кейси губилися в загальній черзі | Складне й емоційне йде оператору з підсумком і посиланнями |
| Час реакції зростав у пікові години | Середній час відповіді 26,5 хв на 11 644 тікетах |
Перший робочий результат отримали за 2 тижні, на повну потужність вийшли за місяць.
Кому підходить таке рішення
Такий агент окуповується там, де більшість звернень повторюються і мають чітку відповідь: статус замовлення, умови повернення, тарифи, типові поломки. Орієнтир: від кількох сотень тікетів на місяць і помітний розрив між денним і піковим навантаженням. Якщо звернень мало або кожне унікальне й вимагає переговорів, дешевше підсилити операторів шаблонами й пошуком, ніж будувати агента. Так само варто зважити, наскільки стабільні ваші правила: якщо тарифи й умови змінюються щотижня, спершу треба навести лад у джерелі правди, а вже потім автоматизувати відповіді на них.
Часті запитання
Чи замінює AI-агент операторів підтримки?
Ні. Він знімає повторювану частину черги, щоб оператори займалися складними випадками: поверненнями коштів, конфліктами, нестандартними ситуаціями. Складні й емоційні звернення агент передає людині разом із підсумком діалогу, щоб оператор не починав з нуля.
Що буде, якщо агент не знає відповіді?
Спрацьовує поріг впевненості: замість здогадки тікет іде оператору з поміткою про причину ескалації. Це свідомий вибір: краще передати людині зайвий раз, ніж дати клієнту впевнено сформульовану неправду.
Скільки часу займає запуск такого агента?
Перший робочий результат зазвичай за два тижні: аудит звернень, база знань за топовими інтентами, запуск на частині трафіку. Вихід на повну потужність займає близько місяця, бо потрібні реальні діалоги, щоб побачити помилки й підняти точність.
Чи можна підключити такого агента до іншого хелпдеску, не Zendesk?
Так. Логіка живе в n8n, а хелпдеск підключається конектором, тож Freshdesk, HelpScout, Intercom чи власна система на API вимагають переробки інтеграційного шару, а не самого агента. Те саме стосується каналів: Telegram, WhatsApp і пошта підключаються до того ж пайплайну.