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

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

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

1. 01

   Мапа процесу

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

2. 02

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

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

3. 03

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

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

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

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

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

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

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

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

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

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

Автоматизація основного потоку замовлень — за 2–3 тижні.

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