Покупатель оплатил, а магазин ещё не знает об этом: что входит в разработку интернет-магазина под ключ
Покупатель оплатил, а магазин ещё не знает об этом. Банк подтвердил операцию, на сайте крутится загрузка, в учётной системе заказа ещё нет, последняя единица товара по-прежнему доступна другому человеку. Для покупателя это один сломанный заказ. Для команды — четыре системы, каждая из которых описывает покупку по-своему.
Такой сбой легко принять за проблему экрана оплаты. Исправление кнопки ничего не даст, пока магазин не научится связывать платёж, резерв, заказ и передачу на склад. Большая часть разработки e-commerce находится именно за витриной: в правилах, данных, интеграциях и инструментах для сотрудников.
Оценку интернет-магазина мы начинаем с пути одной сделки от карточки товара до выдачи или возврата. Этот маршрут быстро показывает реальный состав проекта и помогает отделить коммерческое ядро от функций, которые можно добавить после запуска.
Возьмём один заказ и посмотрим, какие решения нужны магазину, чтобы принять деньги и выполнить обещания покупателю.
Один заказ проходит через витрину, банк, 1С и доставку
На демо всё обычно выглядит компактно: главная, каталог, карточка, корзина и форма оформления. В рабочем магазине за этими экранами живут как минимум четыре слоя. Покупатель взаимодействует с интерфейсом. Сотрудники обрабатывают товары, заказы и исключения. Учётные и внешние сервисы передают цены, остатки, платежи и статусы доставки. Аналитика и мониторинг показывают, где цепочка начала сбоить.
Состав проекта мы обсуждаем по решениям внутри заказа. Откуда карточка получила цену? В какой момент товар резервируется? Что произойдёт после повторного уведомления от платёжного сервиса? Кто увидит заказ, который приняли на сайте, но не передали в 1С? Ответы на эти вопросы превращаются в бизнес-правила, состояния заказа, интеграции и экраны админки.
Одна и та же корзина может выглядеть одинаково в двух магазинах, хотя объём разработки отличается в разы. Первый продаёт товары с одного склада по общей цене и доставляет одной службой. Второй работает с несколькими складами, региональными прайс-листами, частичными отгрузками, самовывозом и разными правилами возврата. Фронтенд у них похож, а система исполнения заказа устроена по-разному.
Даже показатель брошенных корзин сам по себе не объясняет причину. Baymard Institute оценивает среднемировую долю таких корзин в 70,19% и отдельно исследует ошибки интерфейса оформления. В конкретном магазине к интерфейсу добавляются собственные причины: товар закончился, срок доставки изменился, оплата прошла с задержкой, выбранный пункт выдачи недоступен. Диагностика начинается с маршрута заказа, а не с перестановки полей в форме.
Цена на карточке живёт до первого ответа 1С
Карточка товара собирает данные из нескольких мест. Описание и фотографии могут храниться в CMS, номенклатура и фасовки — в 1С, остаток — в складской системе, срок доставки — у логистического партнёра. Покупатель видит один экран, поэтому все источники должны договориться о том, какой товар сейчас продаётся и на каких условиях.
Как только данные приходят из нескольких систем, каталог приходится описывать как модель продукта. В ней появляются варианты, единицы измерения, упаковки, склады, ценовые правила, признаки доступности и связи между товарами. Нужны правила обновления: какие данные считаются основными, как быстро изменения доходят до сайта, что показывать при задержке обмена, можно ли продавать остаток, который давно не подтверждался.
В кейсе HOTZ мы начали с данных: в первой версии объединили четыре продуктовые линейки, а интерфейс связали с 1С по ценам, остаткам, фасовкам и номенклатуре. Сквозной каталог стал общим коммерческим ядром, поверх которого появились разные визуальные разделы брендов. Проект запустили за три месяца благодаря ранней работе с архитектурой и строгой приоритизации функций.
Такой порядок спасает от неприятной ситуации: дизайн уже согласован, а реальная товарная матрица в него не помещается. Например, одна краска продаётся банкой и комплектом, цена зависит от фасовки, а на складе учитывается базовая единица. Поэтому модель товара влияет на корзину, резерв, обмен с 1С, возврат и отчётность.
Поиск тоже зависит от качества каталога. Google рекомендует передавать цену, наличие, доставку и возвраты через структурированные данные и Merchant Center. Такая разметка не исправит расхождения между системами: она лишь публикует те значения, которые магазин ей передал. Сначала нужен надёжный источник данных, затем уже поисковое представление.
После оплаты заказ начинает жить сразу в нескольких системах
Успешный ответ платёжной формы ещё не означает, что сделка состоялась. Платёжный сервис должен сообщить о результате, магазин — связать уведомление с нужным заказом, склад — подтвердить резерв, служба доставки — принять отправление. Любой участник цепочки может ответить позже, прислать одно событие дважды или временно не ответить совсем.
Эти ситуации проектируют заранее, потому что в реальной эксплуатации они неизбежны. Повторное уведомление не должно создавать второй заказ. Потерянный ответ 1С не должен заставлять поддержку угадывать, приняла ли система данные. Ошибка расчёта доставки должна переводить заказ в понятное состояние, из которого оператор может продолжить обработку или связаться с покупателем.
Для этого заказ не хранят одной строкой «в обработке». У него есть отдельные состояния оплаты, резерва, сборки, отгрузки, доставки, отмены и возврата. Переходы связывают с конкретными событиями и действиями: оплата подтверждена, склад собрал часть позиций, перевозчик присвоил трек-номер, клиент отказался от получения. Покупателю показывают короткий понятный статус, а сотрудник видит подробную историю.
Здесь же появляется техническая работа, которую трудно заметить в макете. Интеграции должны безопасно повторять запросы, распознавать дубли и сохранять журнал обмена. Мониторинг отслеживает платежи без заказа, заказы без резерва и отправления, застрявшие между статусами. Эти механизмы редко попадают на обложку проекта, зато именно они не дают одной ошибке превратиться в десятки обращений в поддержку.
На странице направления e-commerce мы отдельно показываем интерфейс, операционное управление, интеграции и аналитику. Это не четыре этапа разработки, которые идут друг за другом. Они сходятся в одном заказе и проверяются вместе: одинаково ли понимают его покупатель, оператор, учётная система и служба доставки.
Админка нужна именно в тот день, когда заказ пошёл не по сценарию
Идеальный заказ проходит сам: товар найден, платёж принят, склад собрал, курьер доставил. Проектировать админку по идеальному пути опасно. Сотрудники открывают её ради исключений: покупатель изменил адрес, одна позиция закончилась, платёж завис, отправление разделили, возврат приехал без понятной причины.
Оператору нужен контекст для решения: состав и история изменений, состояние оплаты и резерва, обмен с внешними системами, сообщения об ошибках и доступные действия. Кнопка «повторить отправку» без информации о предыдущей попытке легко создаёт дубль. Возможность исправить цену без журнала превращает разбор спорной покупки в поиск по чатам.
Роли тоже следуют из операций. Контент-менеджер меняет описание товара, сотрудник склада подтверждает сборку, поддержка оформляет отмену, финансовый специалист проверяет возврат. Общая роль «администратор» выдаёт лишние права и не отвечает на главный вопрос: кто может изменить деньги, остаток и состояние заказа.
Хорошая админка сокращает путь исключения. Вместо пяти вкладок и переписки сотрудник получает одну историю заказа, понимает причину остановки и знает следующее допустимое действие. Поэтому операционный интерфейс входит в коммерческое ядро вместе с витриной. Магазин без него умеет принимать только те заказы, с которыми никогда ничего не случается.
Первый релиз должен довезти один заказ до клиента
Границу MVP удобно проводить по одному приоритетному типу сделки. Покупатель находит товар, видит подтверждённые условия, оформляет и оплачивает заказ. Система резервирует позиции, передаёт данные в основной учётный контур, получает статус исполнения и показывает его покупателю. Сотрудник видит ошибку на любом критическом шаге и может её обработать.
Пять вопросов фиксируют минимальный состав первой версии:
Рекомендации, сложную программу лояльности, расширенный личный кабинет, кабинет поставщика и аналитические панели переносят в следующие очереди, когда они не участвуют в первом типе сделки. Приоритет меняется вместе с моделью бизнеса. Для маркетплейса кабинет поставщика попадёт в ядро, для D2C-магазина на старте может хватить внутренней админки и обмена с учётной системой.
Теперь тот же платёж из начала статьи выглядит иначе. Система один раз создаёт заказ, подтверждает деньги, закрепляет товар, передаёт его в исполнение и показывает понятный статус. При сбое сотрудник видит место остановки и продолжает процесс без догадок. Так работает «интернет-магазин под ключ» после презентации и красивых макетов.
Правило первой версии: в неё входит всё, без чего магазин не может честно показать условия покупки, принять деньги, исполнить заказ и объяснить его статус.
Если хотите проверить состав будущего магазина до оценки, пришлите нам схему текущего заказа или короткий бриф. Мы разложим путь по данным, интеграциям и операциям и покажем, какие части нужны в первом релизе. Обсудить e-commerce-проект.
