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