Кейси / E-commerce · Операційна платформа
Клієнт під NDA Синхронізація даних і ШІ

Ритейлер звів шість каналів продажів в одну систему і зрізав скасування з 15% до 5%.

15% → 5%
скасування замовлень
~70%
звернень закриває ШІ
~2 міс
до повного контуру

Клієнт під NDA: галузь і розмір указані діапазоном. Цифри — з боку клієнта, порівняння періодів до і після запуску; на схожих проєктах результат відрізнявся в обидва боки. Порахувати на своїх обсягах →

Контекст

Один товар заводили в пʼять систем — і все одно продавали те, чого немає.

Ритейлер продає товари з обмеженим строком придатності через два маркетплейси, свою вітрину та офлайн-точку, плюс товарні фіди в Google Ads і Facebook Ads. Кожну нову позицію заводили руками: один раз у складську систему, потім окремо в кожен канал. Залишки зводили вигрузкою раз на добу, тому канал спокійно продавав те, чого на складі вже не було — або те, що було, але зі строком придатності, з яким відправляти не можна, і менеджеру доводилося дзвонити й уточнювати. Скасування доходили до 15% замовлень: штрафи маркетплейсу і картка, що провалюється у видачі. Накладні доставки набивали вручну, а помилки в транспортних знаходилися вже у перевізника. Акт приймання комірник заповнював на папері, бухгалтерія перебивала його в облік. Закупівлю товарознавець збирав за минулорічними файлами.

Рішення

Своя платформа, а не збірка поверх готової автоматизації.

Стек підбирали під задачу: Python і Django в ядрі, PostgreSQL як єдине джерело істини щодо товару, залишку і строку придатності. Позиція заводиться один раз, далі платформа сама створює й оновлює її в усіх каналах, включно з товарними фідами. Модель, що розбирає дзвінки, схована за інтерфейсом і замінна навмисно: кожні кілька місяців виходить щось краще, і ми переводимо клієнта, не переписуючи решту.

Архітектура
Карточка товарузаводиться один разПрийманняперерахунок + фотоДзвінки і заявкиколцентрЯдро платформизалишок · ціна · строкМаркетплейси2 каналиВітринасвій сайтОфлайн-касаоплатиРекламні фідиGoogle · MetaОбліксклади · бухгалтерія
Що побудували

Пʼять контурів, по одному за раз.

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

01
Єдина точка введення і синхронізація
Позиція заводиться один раз. Ціна, залишок, наявність і строк придатності самі розходяться по маркетплейсах, вітрині, офлайн-касі та рекламних фідах.
02
Документи доставки
Накладні генеруються самі. Система перевіряє, чи отримано замовлення, і знаходить помилки в транспортних накладних до відправлення, а не у перевізника.
03
Приймання на складі
Акт приймання заводиться автоматично. Комірник фізично перераховує товар і фотографує акт — далі система сама проводить його по складах і бухгалтерії та оновлює залишки в усіх каналах.
04
Колцентр із ШІ
Близько 70% звернень закриває ШІ. Решта йдуть оператору безшовно: той, хто дзвонить, не помічає передачі, контекст діалогу йде разом із ним.
05
Прогноз і закупівля
Система прогнозує продажі з урахуванням сезонності і формує закупівлю. Товарознавець її схвалює і править за бажанням, а не збирає з нуля.
До і після

До і після.

До
Заведення товару5 систем вручну
Оновлення залишківвигрузка раз на добу
Скасування замовлень~15%
Акт прийманняпапір, потім перебивка
Звернень на операторах100%
Після
Заведення товаруодин раз, далі саме
Оновлення залишківбезперервно
Скасування замовлень~5%
Акт прийманняперерахунок і фото
Звернень на операторах~30%
Межі автоматизації
Що залишилося за людьми — навмисно.
Фізичний перерахунок товару на приймання і фото акта. Жодна машина не підтвердить, що коробки справді приїхали.
Фінальне схвалення закупівлі: прогноз пропонує, товарознавець вирішує.
Конфлікти цін і описів між каналами. Ціну автоматом переписувати не даємо.
Ті приблизно 30% звернень, які ШІ віддає оператору замість того, щоб вгадувати.
Стек
Python Django PostgreSQL API маркетплейсів LLM (замінна) Прогноз попиту Моніторинг і алерти
Відверто про терміни

Чому весь контур зайняв пару місяців, а не рік.

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

Повʼязане

З чого зібраний цей кейс.

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

Хочете те саме для свого процесу?

Безкоштовний міні-аудит покаже ROI для найважливішого процесу — далі розробка за фіксованою ціною.

Безкоштовний міні-аудит →