Более пятой части розничных продаж в России приходится на онлайн. По данным Ассоциации компаний интернет-торговли, в первом полугодии 2026 года его доля достигла 22,2%. Это общий показатель для интернет-магазинов и маркетплейсов.

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

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

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

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

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

«Хотим продавать через интернет» — понятное желание. Для проектирования сайта его нужно уточнить.

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

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

Географию приходится пересматривать даже крупным сервисам. Весной 2022 года «Самокат» приостановил работу в 15 городах России. Представитель компании объяснил, что сервис перестраивает сеть, если отдельные точки не показывают нужной эффективности. Открыть доставку в новом городе — ещё не значит заработать на ней. Поэтому географию запуска стоит выбирать с учётом ожидаемого спроса и расходов на обслуживание заказов.

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

У нашей сети десять магазинов и склад. Значит ли это, что для онлайн-покупателя доступны остатки сразу из одиннадцати мест?

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

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

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

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

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

• предложить две доставки и показать стоимость каждой;
• сначала переместить товары в одну точку, увеличив срок получения;
• предложить покупателю выбрать товары, доступные в одном месте отгрузки.

У каждого решения есть цена для бизнеса и последствия для покупателя. Две доставки могут оказаться слишком дорогими, а ожидание перемещения — слишком долгим.

Выбранную схему предстоит проверить вместе с разработчиком и специалистами по учётной системе (например 1С). Можно ли получить нужные данные? Какие операции придётся автоматизировать или менять? Только после этого станет понятно, как реализовать сценарий и во сколько он обойдётся.

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

Сколько чайников можно заказать на сайте прямо сейчас? Число «три» выглядит оптимистично.

Для онлайн-продаж нужно определить, какой остаток считается доступным покупателю. Учитываются ли резервы, витринные экземпляры, повреждённые товары? Как быстро информация о продаже на кассе попадает на сайт?

Отдельный вопрос — резервирование онлайн-заказа. В какой момент товар закрепляется за покупателем: после оформления, оплаты или подтверждения сотрудником? Как долго хранится резерв и когда освобождается при отмене?

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

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

До начала разработки стоит выяснить:

• где хранятся остатки и насколько они точны;
• как учитываются продажи и резервы разных каналов;
• как быстро передаются изменения;
• что делать, если обмен данными временно перестал работать.

Например, при устаревших данных можно временно показывать «наличие уточняется» вместо обещания немедленного самовывоза. Конкретное поведение интернет-магазина зависит от бизнеса, но его нужно предусмотреть заранее.

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

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

Покупатель увидел на сайте лампу за 4 900 рублей и пришёл купить её в магазин. На полке — 5 400. Оказалось, первая цена действует только при оформлении заказа онлайн. Если сайт заранее об этом не предупредил, объясняться придётся продавцу.

Для нашей сети предстоит определить:

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

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

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

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

Покупатель нажал «Оформить заказ». На экране появилось радостное сообщение. Что происходит дальше?

Если уведомление ушло на общую почту магазина, которую все проверяют по возможности, радоваться пока рано.

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

У нашей сети сборкой могут заниматься сотрудники магазинов. Тогда стоит заранее проверить, есть ли у них время, упаковка и место для хранения заказов. Если в субботу в торговом зале очередь, обещание «соберём за 15 минут» становится довольно смелым.

Полезно разобрать и несколько ситуаций, в которых всё идёт не по плану:

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

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

Статусы заказа тоже должны соответствовать реальным событиям. Сообщение «Можно забирать» стоит отправлять, когда товар найден, проверен и отложен.

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

Сразу подключить десять магазинов, три города, все способы доставки и сложную программу лояльности — возможный сценарий (долгий, дорогой, но возможный). Но чем больше вариантов, тем больше связей предстоит настроить и проверить.

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

До запуска интернет-магазина нужно проверить оформление, оплату, отмену и возврат на контрольных заказах. MVP покажет, как эти процессы работают при реальной нагрузке. Такой запуск позволит проверить на реальных заказах:

• совпадает ли доступность на сайте с фактическим наличием;
• успевают ли сотрудники собирать заказы;
• получают ли покупатели понятные уведомления;
• сколько стоит обработка и выдача заказа.

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

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

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

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

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

Возьмём пожелание «покупатель может забрать заказ в любом магазине». Что именно оно означает? Выбрать точку, где товар уже есть? Заказать перемещение с центрального склада? Собрать покупку из остатков нескольких магазинов и привезти в четвёртый?

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

Если товары нужно перемещать, придётся определить, кто и когда запускает перемещение, где фиксируется резерв, как рассчитывается дата готовности и что происходит при задержке. А если покупатель отменил заказ, когда товар уже в пути? А если решил поменять магазин получения? Эти сценарии тоже потребуется обработать.

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

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

Цели, сценарии и ограничения стоит зафиксировать в бизнес-требованиях к проекту. Они помогут разработчику оценить объём работ.

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

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

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