Интернет-магазин бренда одежды: каталог, заказы, оплата и личный кабинет покупателя

У бренда была задача, которую плохо решают готовые платформы: собственная товарная логика. Одежда это не просто карточка товара с ценой, а размерная сетка, цвета, ростовки, коллекции и сезоны. На конструкторе это выражается через костыли: «размер» становится свойством товара, каждая комбинация отдельной позицией, и каталог из сотни моделей превращается в тысячи карточек, которые невозможно вести.

Вторая проблема это склад. Учёт компания вела в МойСклад и 1С, и это правильное место для учёта. Но магазин про него ничего не знал: наличие на сайте было отдельным списком, который кто-то поддерживал руками. Расхождение обнаруживалось самым дорогим способом: покупатель оформлял и оплачивал то, чего на складе уже не было.

Третья проблема: заказы жили в разрыве. Оплата приходила в одном месте, заказ передавался на сборку в другом, статус покупателю сообщали в третьем. Между этими местами стоял сотрудник, который переносил данные и, как любой человек, иногда этого не делал вовремя.

И четвёртая: поддержка превратилась в справочное бюро. Большая часть обращений была не про проблемы, а про «где мой заказ», «что я заказывал в прошлый раз», «какой был размер». На каждый такой вопрос уходило время сотрудника, хотя ответ у системы уже был, просто покупатель не мог его увидеть.

Расхождение склада и сайта обнаруживалось самым дорогим способом: покупатель оформлял и оплачивал то, чего на складе уже не было.

Магазин целиком, а не витрину поверх чужой платформы. Каталог построен вокруг товарной логики бренда: модель, её цвета и размерная сетка это одна сущность с вариантами, а не россыпь независимых карточек. Покупатель выбирает размер внутри карточки модели, а контент-менеджер ведёт одну позицию вместо двадцати.

Оформление заказа сделано коротким и устойчивым: корзина, доставка, оплата. Оплата принимается через ЮKassa, и заказ меняет статус по факту подтверждения платежа, а не по нажатию кнопки, то есть система знает, что деньги действительно получены, и не отдаёт на сборку неоплаченное.

Личный кабинет покупателя закрывает тот самый поток вопросов в поддержку. Человек видит свои заказы, их состав, статусы и историю, не спрашивая никого. Это не «приятное дополнение», а разгрузка сотрудников, измеряемая количеством ненаписанных сообщений.

И админка, рабочее место команды бренда. Товары и коллекции, заказы и их статусы, покупатели, контент витрины. Сделана под то, как бренд реально работает, а не под универсальную схему «товар, заказ, клиент», в которую потом приходится вписываться.

Модель с её цветами и размерной сеткой это одна сущность с вариантами, а не двадцать независимых карточек. Контент-менеджер ведёт позицию, а не комбинаторику.

Учётные системы остались на своих местах: МойСклад и 1С остались там, где ведётся склад и учёт, и магазин их не заменяет и не дублирует. Он берёт оттуда то, что обязано быть в одном экземпляре, и отдаёт обратно то, что порождает сам.

Из учётных систем приходят товары, остатки и цены. Это закрывает первую проблему из первого раздела: наличие на витрине перестало быть отдельным списком, который кто-то поддерживает. Позиция, которой нет на складе, не продаётся на сайте, и не потому, что кто-то вовремя это заметил, а потому, что источник данных о наличии один.

Обратно уходят заказы: оформленный и оплаченный заказ попадает в учётную систему как документ, готовый к сборке. Тот сотрудник, что раньше стоял посередине и переносил данные руками, из цепочки убран вместе с задержками и опечатками, которые эта работа неизбежно порождала.

Обмен идёт фоновыми задачами по расписанию, а не в момент нажатия кнопки. Это важно для устойчивости: учётная система может быть занята или недоступна, и заказ в этот момент не должен пропадать. Задача, не выполнившаяся с первого раза, возвращается в очередь и повторяется.

Позиция, которой нет на складе, не продаётся на сайте, и не потому, что кто-то вовремя это заметил, а потому, что источник данных о наличии один.

Платёж это место, где ошибка стоит дороже всего: здесь деньги покупателя встречаются с обязательствами бренда. Поэтому статус заказа меняется не по возвращению покупателя на страницу «спасибо», а по уведомлению от платёжной системы. Покупатель может закрыть вкладку сразу после оплаты, заказ всё равно будет отмечен оплаченным.

Обратная ситуация тоже учтена: заказ оформлен, но оплата не прошла или брошена на середине. Такой заказ не уходит на склад и не занимает товар навсегда, а остаётся в своём статусе, видимый и команде, и покупателю в кабинете.

Уведомления от платёжной системы обрабатываются так, чтобы повтор не создавал вторую оплату: платёжные провайдеры повторяют доставку уведомления, если не получили подтверждения, и система, которая этого не учитывает, рано или поздно отгружает заказ дважды.

У бренда появился собственный канал продаж, устроенный по его товарной логике, а не по чужой схеме. Это касается и каталога с размерными сетками, и админки, в которой команда работает ежедневно.

Склад и витрина перестали расходиться. Вопрос «есть ли это в наличии» имеет один ответ, потому что у него один источник: учётная система, а не таблица, которую кто-то забыл обновить.

Ручной перенос заказов исчез как операция. Оплаченный заказ попадает в учётную систему сам, и скорость этого больше не зависит от того, насколько занят сотрудник.

А поддержка перестала быть справочным бюро: вопросы про статус и состав заказа покупатель закрывает в кабинете сам. Сотрудники остались для тех обращений, где действительно нужен человек.