Платформа онлайн-торговли: что включить в первую версию

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

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

Состав первой версии: что входит и что откладываем

Ниже состав по частям платформы. В столбце «Откладываем» то, что хочется добавить сразу, но что увеличивает работу и проверку без влияния на первые заказы. Список подписывается до разработки, новая функция оценивается отдельно, а не добавляется молча.

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

Каталог и остатки: кто главный и что видит покупатель

В платформе онлайн-торговли главные данные ведёт учёт: наименования, цены, остатки, комплекты. Сайт получает копию и показывает её. Пока это записано в виде таблицы «поле — источник — кто вправе менять», споров систем не возникает. Маркетинговые описания и фото чаще ведутся на стороне сайта, цена и остаток всегда в учёте. Подробнее об этом на странице «Интеграция сайта с 1С».

Остаток для покупателя не равен остатку в учёте. Нужно решить заранее:

• Что вычитается. Резервы под открытые заказы, товар в пути, брак, склады, с которых вы не отгружаете в интернет.
• Что показывать. Точное число, «в наличии» и «мало» или срок под заказ. Точное число удобно покупателю, но при каждой ошибке учёта превращается в обещание.
• Как работают комплекты. Остаток набора определяется самой дефицитной позицией, и его считает учёт или сервис обмена, а не страница.
• Что делать с договорными ценами. Для покупателей-организаций цена зависит от договора, и показывать её можно только после входа.

Остаток, который «поехал» между сайтом и учётом, самая частая жалоба на магазин. Типовые причины разобраны в статье «Остатки 1С и маркетплейса не совпадают», и для сайта они те же.

Заказ и оплата: статусы и повторная доставка уведомлений

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

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

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

Доставка и самовывоз: начинаем с простого

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

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

Обмен с 1С: что ходит в первой версии

Принцип один: сайт не ждёт 1С. Покупатель видит копию данных на стороне сайта, а заказ при недоступном учёте встаёт в очередь и доезжает сам. В первой версии ходят пять потоков:

• каталог и характеристики из учёта на сайт;
• цены и остатки на сайт, по изменению, а не раз в сутки;
• заказы с сайта в учёт, с составом и ценой, которые видел покупатель;
• статусы и документы из учёта на сайт;
• факт оплаты с сайта в учёт.

К ним добавляют журнал обмена и ежедневную сверку: число заказов, суммы и выборка остатков. Расхождение попадает в журнал, и регламент говорит, кто его разбирает. Если сверки нет, о расхождении узнают от покупателя. Стандартный формат обмена CommerceML закрывает основную схему, но упирается в комплекты, договорные цены и частичные отгрузки; где именно, написано в статье «CommerceML: как устроен обмен 1С с сайтом». Типовой обмен стоит 150 000–350 000 ₽ по странице интеграции, и при новой платформе он входит в смету первой версии.

Поиск и техническая основа для поисковой выдачи

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

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

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

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

Админка, роли и безопасность

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

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

Что не входит и чего мы не делаем

Три группы запросов не входят в первую версию, а две из них мы не делаем вовсе:

• Рекомендации, лояльность, отзывы, несколько витрин, многоязычность. Откладываем, возвращаемся по условию из таблицы выше.
• Маркетплейс чужих продавцов. Кабинеты продавцов, комиссии, выплаты и модерация — отдельный продукт, который мы не делаем. Обмен вашего учёта с торговыми площадками описан на странице «Интеграция 1С с маркетплейсами».
• Нативные мобильные приложения. Делаем адаптивный веб-интерфейс, при необходимости с установкой на экран. Приложения для iOS и Android не берём.
• Эквайринг и онлайн-кассы. Подключаем интерфейс вашего провайдера, но сами платежи не принимаем и данных карт не храним.
• Продвижение, реклама, содержание каталога. Это работа вашей команды или других подрядчиков.

Если вам достаточно существующего магазина на готовой платформе с обменом через модуль, заказная разработка не нужна. Сравнение готового и заказного подхода есть в статье «Коробочное ПО или заказная разработка».

Что делаем мы и с чего начать

Начинаем с обследования: платформа онлайн-торговли связана минимум с учётом, оплатой и доставкой, поэтому чаще всего это 350 000 ₽ и 3–4 недели; если магазин простой и связан только с 1С, хватает 200 000 ₽ и 2–3 недель. На выходе документ с составом первой версии, таблицей источников данных, схемой статусов заказа и вилкой бюджета. Стоимость вычитается из первого этапа, если продолжаете с нами.

Первая версия идёт по ступени пилота и укладывается в 400 000–1 200 000 ₽ за 2–3 месяца, если состав близок к описанному в таблице; точная вилка называется после обследования. Вывод в эксплуатацию — от 1 500 000 ₽ этапами по 300 000–700 000 ₽, сопровождение — 20 000, 60 000 или 120 000 ₽ в месяц, часы сверх пакета по 5 000 ₽. Мы делаем платформу и обмен, а не продвигаем магазин и не дежурим круглосуточно. Исходники лежат в вашем репозитории с первого коммита, остановиться можно после любой ступени. Все цены и сроки — на странице «Тарифы», описание услуги — на странице «Платформа онлайн-торговли».