Сайты

Интернет-магазин: что решить до начала разработки

Каталог, свойства товаров, доставка, оплата, остатки и интеграции — решения, которые принимают до вёрстки. Менять их потом заметно дороже.

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

Каталог: структура и свойства товаров

Каталог — это фундамент. Всё остальное — фильтры, поиск, выгрузки, рекомендации — построено на нём.

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

  • Может ли товар находиться в нескольких категориях сразу? Если да, это надо заложить заранее — переделка на живом каталоге неприятна.
  • Что считать товаром, а что вариантом товара? Футболка трёх цветов и четырёх размеров — это двенадцать товаров или один товар с двенадцатью вариантами? От ответа зависят карточка, остатки, корзина и вся аналитика продаж.

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

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

Каталог нельзя «дозаполнить потом». Товары, заведённые по разным правилам, придётся переносить вручную, и чем их больше, тем дороже это обходится.

Доставка и оплата

Варианты доставки определяют логику корзины и оформления заказа. Вопросы, на которые нужны ответы до разработки:

  1. Какие способы доставки будут? Самовывоз, курьер, транспортные компании, пункты выдачи — у каждого своя логика адреса и сроков.
  2. Как считается стоимость? Фиксированная, по зонам, по весу и габаритам, по тарифу перевозчика через его сервис. Расчёт через сторонний сервис — это интеграция со своими сроками и ограничениями.
  3. Есть ли бесплатная доставка и от какой суммы? Это влияет на корзину: покупателю нужно показывать, сколько осталось добрать.
  4. Что с крупногабаритным товаром? Если часть ассортимента нельзя отправить обычным способом, правило должно быть в системе, а не в голове менеджера.

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

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

Остатки: где живёт правда

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

Решить нужно три вещи.

Где мастер-система. Остатки ведутся в 1С, в складской программе, в CRM или на самом сайте? Источник правды должен быть один. Если товар можно списать и на складе, и на сайте, рассинхронизация гарантирована.

Как часто синхронизируются данные. Раз в сутки, каждые несколько минут или в реальном времени по событию. Чем быстрее оборачивается товар, тем критичнее задержка. Для штучного и редкого товара разница особенно заметна.

Что делать при нуле. Прятать товар, показывать с пометкой «нет в наличии», принимать предзаказ. У каждого варианта свои последствия: скрытый товар теряет накопленные поисковые позиции, а страница с пометкой их сохраняет.

Отдельный вопрос — резервирование. Товар блокируется в момент добавления в корзину, в момент оформления или после оплаты? И на какое время? Без явного правила два покупателя купят последнюю единицу.

Интеграции с 1С и CRM

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

Типичный набор направлений:

  • Из учётной системы на сайт: номенклатура, цены, остатки, иногда описания и изображения.
  • С сайта в учётную систему: заказы, данные покупателя, выбранные доставка и оплата.
  • С сайта в CRM: обращения, брошенные корзины, история покупок.
  • Обратно на сайт: статусы заказов, трек-номера.

Вопросы, которые надо закрыть заранее: по какому полю сопоставляются товары в двух системах (артикул, штрихкод, внутренний код), что происходит при конфликте данных, что делать, если учётная система недоступна в момент заказа. Последнее особенно важно: заказ не должен теряться из-за того, что 1С на обслуживании — он принимается и ставится в очередь на передачу.

Ещё одна вещь, которую стоит проговорить: не всё нужно тянуть из учётной системы. Названия и описания там часто написаны для склада, а не для покупателя. Иногда правильнее вести маркетинговый контент на стороне сайта, а из 1С брать только цены и остатки.

Кто и как наполняет карточки

Самая недооценённая часть проекта. Магазин может быть готов, а продаж не будет, потому что карточки пустые.

Нужно ответить:

  • Откуда берутся тексты и фотографии? Свои, от поставщика, закупаются отдельно. Описания от поставщика часто дублируются у десятков магазинов, и поиск это видит.
  • Кто физически заводит товары? Свой сотрудник, подрядчик, автоматический импорт из прайса.
  • Сколько времени занимает одна карточка? Умножьте на количество товаров — получится реальный срок запуска, который обычно длиннее, чем срок разработки.
  • Как поддерживается качество? Нужен регламент: какие поля обязательны, какие требования к фотографиям, как формулируются названия.
  • Как добавляются новые товары? Ручной ввод не масштабируется. Если ассортимент обновляется часто, импорт из файла или из системы поставщика нужен с первого дня.

Практический совет: заведите несколько настоящих карточек до начала вёрстки. На них сразу видно, каких полей не хватает, где описания слишком длинные, а где фотографии не подходят по формату.

Почему это дороже менять потом

Причина в том, что перечисленные решения лежат в основании, а не сверху.

Смена модели «товар — вариант» переписывает карточку, корзину, заказ, выгрузки и аналитику. Добавление второго склада меняет логику остатков и расчёт доставки. Появление юридических лиц после запуска — это новые поля, новые документы и новая ветка в оформлении заказа. Замена источника правды по остаткам — переделка всей интеграции.

Отдельная статья расходов — данные, которые уже накопились. Пока товаров десяток, перестроить структуру можно. Когда их тысячи и по ним идут заказы, каждая переделка превращается в миграцию с проверкой результата.

Что сделать до старта

Короткий список, который стоит закрыть письменно, прежде чем начинать разработку:

  1. Структура категорий и решение по товарам с вариантами.
  2. Набор свойств по каждой категории, с пометкой, что участвует в фильтрах.
  3. Способы доставки и правила расчёта стоимости.
  4. Способы оплаты, сценарий для юридических лиц, порядок возврата.
  5. Мастер-система для остатков, частота синхронизации, поведение при нуле, правила резерва.
  6. Перечень интеграций с направлением обмена и ключом сопоставления товаров.
  7. Ответственный за наполнение, источник контента и оценка сроков по всему ассортименту.
  8. Десяток реальных карточек как образец.

Когда эти пункты закрыты, разработка интернет-магазина идёт предсказуемо. Когда нет — сроки сдвигаются не из-за кода, а из-за решений, которые всё равно придётся принять, только позже и дороже. Если по какому-то пункту нет ответа, это нормальный повод обсудить его до начала работ.