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