AI-агент обробки замовлень для fashion e-commerce

Контекст галузі

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

Задача

Менеджери щодня вручну звіряли замовлення з наявністю, оновлювали статуси й писали клієнтам. Це з’їдало години, гальмувало відправки та плодило помилки у пікові дні.

Підхід

1. 01

   Мапа процесу

   Розписали шлях замовлення від оплати до відправки й точки ручної роботи.

2. 02

   Автопідтвердження

   Агент звіряє наявність і підтверджує або позначає проблемні позиції.

3. 03

   Статуси й сповіщення

   Автооновлення статусів і повідомлення клієнту на кожному кроці.

Як працює рішення

1. 01ShopifyНадходить замовлення
2. 02n8n + Shopify APIЗвіряє з наявністю й оновлює статус
3. 03GPT-4oОпрацьовує нестандартне й пише клієнту
4. 04SlackСповіщає команду про позиції для людини

n8n оркеструє процес: через Shopify API агент читає замовлення й наявність, GPT-4o опрацьовує нестандартні випадки та формулює повідомлення, а Slack сповіщає команду про позиції, що потребують уваги людини.

Чому саме такий стек

Shopify лишився системою обліку: агент читає замовлення й залишки через API, але не стає другим джерелом правди. Це принципово: щойно з’являється паралельна база товарів, розбіжності стають питанням часу. n8n оркеструє процес, бо шлях замовлення розгалужений: оплата, перевірка наявності, часткове комплектування, відправка, і на кожному кроці можливий виняток. GPT-4o застосовується вузько: не для рішень про замовлення, а для формулювання повідомлень клієнту й розбору нестандартних випадків, де правило описати важко. Slack обрано точкою людського контролю, бо команда й так у ньому працює: позиції, що потребують рішення, приходять туди, де їх помітять за хвилини, а не в чергову панель, яку відкривають раз на день.

Де такі проєкти зазвичай ламаються

• Гонка за останній розмір

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

• Автоматичні повернення коштів

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

• Мовчання замість поганої новини

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

Результати

Основний потік замовлень автоматизували за 2-3 тижні.

Кому підходить таке рішення

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

Часті запитання

Інші кейси