Разработка интернет-магазина: продумайте весь жизненный цикл заказа

Определение правил продаж до создания магазина

Если разработка интернет-магазина начинается лишь со списка категорий и нескольких изображений товаров, решения о правилах продаж могут неоднократно меняться уже в ходе работы. Сначала мы выясняем, что продаёт компания, в какие страны или регионы доставляет товары, как рассчитывает цены и какая команда будет готовить заказы. Цифровые, физические и персонализированные товары, а также оптовые продажи коробками не следует подгонять под один сценарий покупки. В составе работ должно быть описано, как эти различия отразятся на покупателе и внутренних процессах магазина.

• Подготовка продавца и подключение поставщиков услуг: Владелец магазина оформляет учётную запись у платёжного провайдера, заключает договор с перевозчиком и предоставляет необходимые документы компании. Требования к заявке зависят от поставщика услуг; техническая разработка не гарантирует одобрения учётной записи продавца.
• Источник данных каталога: Определяем, из какого файла или системы будут получены название товара, SKU, штрихкод, связи между вариантами, изображения и описание. Наличие файла не означает, что данные готовы к использованию; повторяющиеся коды и недостающие варианты проверяются до переноса.
• Цена и доставка: Фиксируем правила отображения налогов, пороговые условия стоимости доставки, регионы доставки, исключения из бесплатной доставки и совместимость акций. Покупатель не должен сталкиваться с неожиданными условиями на последнем этапе оформления заказа.
• Возвраты и общение с клиентами: Определяем ответственных за приём заявки, рассмотрение, одобрение возврата и возврат средств. Применимость одинаковых правил возврата ко всем товарам оценивается совместно с юридическим консультантом компании.
• Тексты и фиксация согласий: Уполномоченные лица предоставляют тексты предварительной информации для покупателя, условий продажи, политики конфиденциальности и необходимых согласий. Программа может фиксировать время получения согласия и соответствующую версию текста; команда разработки не отвечает за юридическую корректность этих текстов.

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

Выбор платформы определяется бизнес-правилами, а не списком функций

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

В проектах HazırSoft могут использоваться решения на PHP/Laravel и MySQL; выбор технологии сам по себе не является показателем качества. Важно чётко определить, где рассчитывается цена, какая система служит источником данных об остатках и какая операция изменяет статус заказа. Если существующих компонентов достаточно, мы адаптируем их вместо ненужного переписывания; нестандартные бизнес-процессы включаются в состав работ по индивидуальной разработке.

В проектах переноса возможности экспорта данных из прежней системы изучаются на раннем этапе. Сохранение идентификаторов товаров, сопоставление старых URL, перенос записей о согласиях клиентов и обеспечение доступности истории заказов — отдельные задачи. Если используемый алгоритм хранения паролей нельзя перенести в новую систему, может потребоваться безопасная процедура сброса и установки нового пароля. Важно не только совпадение количества записей, но и сохранение корректных связей между товарами и вариантами, заказами и их позициями; при переходе также определяется, в какой системе будут завершаться открытые заказы.

Подтверждение оплаты по проверенному уведомлению, а не по странице успешного платежа

Переход клиента на страницу успешной оплаты сам по себе не доказывает получение средств. Уведомление, поступившее от сервера провайдера, необходимо проверить с помощью подписи или другого предусмотренного способа проверки; сумма, валюта и идентификатор заказа должны совпадать с данными соответствующего заказа. Повторная отправка того же уведомления не должна создавать новый заказ или повторно уменьшать остатки. Даже если произошёл сетевой сбой и браузер клиента не вернулся на сайт магазина, необходим журнал операций, позволяющий выяснить фактический статус платежа.

Технические и коммерческие ограничения при выборе провайдера

iyzico, PayTR и банковский интернет-эквайринг оцениваются с учётом учётной записи компании, возможностей API провайдера и модели продаж. Поддержка рассрочки, иностранных карт и разных валют доступна не для всех учётных записей в одинаковом объёме. При использовании зарубежного провайдера отдельно проверяются страна деятельности компании и возможность подключения её учётной записи. Способ оплаты, доступность которого для компании не подтверждена, не включается в состав работ как безусловно доступная функция.

Неудачная оплата и возврат средств — тоже часть процесса обработки заказа

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

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

Источник данных об остатках и ответственность за отгрузку при многоканальных продажах

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

При интеграции с маркетплейсом недостаточно передавать только название товара. Сопоставляются характеристики категорий, идентификаторы товаров в канале, варианты и правила ценообразования. Цена на сайте не обязательно должна совпадать с ценой на маркетплейсе: комиссии и условия акций могут различаться. Входящие заказы сохраняются с идентификаторами канала; повторное получение той же записи не должно создавать второй заказ. Ошибки передачи данных должны попадать в список задач, доступный сотрудникам, отвечающим за обработку заказов.

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

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

Управление каталогом, акциями и правилами дилерских продаж

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

• Движение остатков: Физическое количество на складе, количество, зарезервированное под заказы, и количество, доступное для продажи, — разные понятия. Пригодность возвращённого товара для повторной продажи может определяться после проверки.
• Совмещение акций: Купон, скидка за количество и бесплатная доставка могут сочетаться в одной корзине. Приоритеты, предельные значения и исключённые товары определяются явно; расчёт цены в панели управления должен соответствовать расчёту на этапе оплаты.
• Права доступа и журнал действий: Сотрудник склада может иметь право готовить заказы, но не изменять прайс-лист. Для критически важных операций, таких как одобрение возврата или изменение цены, фиксируются ответственный пользователь и время выполнения.
• Удобство для покупателя: Покупка без регистрации, проверка адреса и отслеживание заказа проектируются с учётом бизнес-модели. Сообщение об ошибке должно объяснять, какое поле и как исправить; все ошибки не сводятся к общему уведомлению о сбое.

В закупках B2B права доступа так же важны, как цена

В дилерском портале у одной компании может быть несколько пользователей. Разделение ролей подготовки и согласования заказа, специальные цены для дилерской группы, минимальное количество коробок и условия отсрочки платежа отличаются от правил магазина B2C. Если отображается сальдо взаиморасчётов, должны быть понятны источник данных и их актуальность; экран без связи с ERP нельзя представлять как отражение финансового состояния в реальном времени. При переходе от коммерческого предложения к заказу также определяется срок действия цены и то, резервируются ли товары при подготовке предложения.

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

Доступность каталога для поисковых систем и скорость покупки

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

• Название товара, описание и альтернативный текст изображения должны быть доступны для редактирования; пустые или повторяющиеся поля должны выявляться при массовом импорте.
• Цена и наличие в структурированных данных товара должны соответствовать информации, которую покупатель видит на странице.
• Изображения товаров на мобильных устройствах должны загружаться в подходящих размерах; при загрузке страницы цена и кнопка покупки не должны неожиданно смещаться.
• Кеш не должен показывать персональную цену одного клиента другому; динамическая корзина и контент, доступный авторизованным дилерам, должны быть отделены от общедоступного каталога.

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