Обработка заказов интернет-магазина: где теряются заказы

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

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

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

Как выглядит поток заказа от корзины до доставки

Коротко: заказ проходит шесть шагов - приём, проверка наличия, резерв, оплата, сборка, передача в доставку. Рвётся поток на стыках между шагами. Внутри шага всё идёт ровно.

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

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

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

Где чаще всего теряются заказы интернет-магазина?

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

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

1. Сайт. Заказ падает в админку магазина. Теряется, если уведомление менеджеру приходит письмом, а папка разбирается раз в день.
2. Мессенджеры. Заказ в переписке. Теряется, если менеджер забыл перенести его в учёт: в чате он есть, в работе - нет.
3. Телефон. Заказ принят на слух. Теряется, если позиции и адрес записаны не туда, откуда их возьмёт сборщик.
4. Почта. Заявка письмом. Теряется, если приходит на общий ящик, который читают все и никто.
5. Маркетплейс. Заказ в кабинете площадки. Теряется, если кабинет не связан со складом и сборщик узнаёт о нём позже, чем надо.

Отдельное место - отмена. Покупатель оформил заказ и передумал. Система при этом продолжает держать товар в резерве. Свободный остаток тает, другие покупатели видят «нет в наличии» там, где товар есть.

По данным Data Insight, в 2025 году в России оформили 8,3 млрд онлайн-заказов, и 81% из них пришёлся на маркетплейсы. Чем больше каналов, тем выше цена одного потерянного заказа.

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

Почему заказ принят, а товара нет?

Коротко: заказ фиксирует намерение. Товар под ним ещё не закреплён, и до резерва его может забрать другой покупатель.

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

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

Пока заказ не перешёл в нужный статус, товар под него не закреплён. Между оформлением и резервом всегда есть окно, и в этом окне остаток можно продать повторно.

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

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

Коротко: столько, сколько раз меняется ответственный или действие. Если два статуса означают одно и то же действие, один из них лишний.

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

Рабочий минимум выглядит так.

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

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

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

Что связывать: магазин, склад, доставку и учёт?

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

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

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

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

Коробка, доработка или своя разработка - что выбрать?

Коротко: начинайте с готового. Своя разработка нужна там, где готовое ломается о ваши каналы или правила. Желание «сделать своё» - не причина.

Решение зависит от ваших условий. Ориентир - в таблице.

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

Почему просрочка отгрузки на маркетплейсе стала дорогой?

Коротко: на маркетплейсах скорость передачи заказа влияет на комиссию и логистику. Рейтинг тут ни при чём: опоздание стоит денег.

Если вы работаете по FBS (отгрузка со своего склада), заказ лежит у вас, и площадка ждёт его в срок. В 2026 году правила ужесточились: скорость передачи заказа привязали к деньгам. Wildberries считает комиссию по тому, как быстро вы передали товар. У Ozon просрочка уходит в индекс ошибок и поднимает стоимость логистики следующих недель.

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

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

Как понять, где теряются заказы, по своим данным?

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

Возьмите месяц и выгрузите заказы. Дальше считайте.

1. Время от оформления до начала сборки. Если у части заказов оно измеряется днями, заказ где-то залёг.
2. Доля отмен по причине «нет товара». Высокая доля значит, что резерв и остаток не сходятся.
3. Число заказов, которые висят в одном статусе дольше положенного. Это и есть потерянные заказы, только заметные.
4. Время ответа на заказ из чата или почты. Если оно считается часами, часть покупателей уйдёт раньше, чем вы ответите.

Когда числа собраны, узкое место видно без догадок. Дальше остаётся решить, закрывается оно настройкой или требует разработки.

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

Когда автоматизировать заказы не нужно?

Коротко: если заказов немного и канал один, регламента хватит. Автоматизация окупается на объёме и на нескольких каналах.

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

• Заказов в день немного, и все приходят в одно место. Хватит уведомления и одного ответственного.
• Менеджеров двое-трое, и они рядом. Договориться быстрее, чем строить систему.
• Проблема в одном канале. Починка этого канала закроет большую часть потерь.
• Нет регламента. Пока нет правила, кто и когда берёт заказ, любая система покажет тот же беспорядок, только быстрее.

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

Что записать в задание подрядчику?

Коротко: опишите каналы, статусы, связки и крайние случаи. Чем точнее крайние случаи, тем меньше сюрпризов на приёмке.

Задание на обработку заказов - это список того, что система должна делать. Технологии тут вторичны. Что в него входит.

1. Каналы приёма. Откуда приходит заказ и как он попадает в общий список.
2. Статусы и переходы. Что значит каждый статус и кто его меняет.
3. Резерв. Когда товар закрепляется за заказом и когда освобождается.
4. Связки. Со складом, доставкой, учётной системой, кабинетом маркетплейса.
5. Крайние случаи. Нет товара, частичная отгрузка, отмена после оплаты, возврат, отмена на стороне площадки.
6. Кто главный по остатку. Один источник, остальные читают.
7. Оповещения. Где застрял заказ и кому об этом сообщать.

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

Хотите понять, как такой же поток устроен в CRM под ваш магазин? Разбор есть в статье про разработку CRM на заказ.

Как проверить обработку заказов при приёмке?

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

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

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

Если на каком-то шаге заказ «пропал» или остаток разошёлся, это и есть то самое узкое место. Принимать работу стоит только тогда, когда поток проходит целиком.

Сколько это стоит и окупается ли?

Коротко: цена зависит от числа каналов, связок и крайних случаев. Размер магазина на неё не влияет. Сравнивайте цену разработки с ценой потерь, которые она убирает.

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

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

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

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

Источники

1. Data Insight, «Интернет-торговля в России 2026» (данные за 2025) - рынок 13,4 трлн руб., 8,3 млрд заказов, доля маркетплейсов 81% заказов. https://datainsight.ru/DI_eCommerce_2026
2. Коммерсантъ, «Рост числа онлайн-заказов в России стал минимальным за восемь лет». https://www.kommersant.ru/doc/8551370
3. RetailCRM, документация: автоматическое бронирование товаров в заказе. https://help.retailcrm.pro/Users/Autoreservation
4. RetailCRM, документация: настройки складов и отгрузки. https://docs.retailcrm.ru/Users/Administration/ProductWarehouseSettings/WarehouseSettings
5. uniseller.io, «FBS на Wildberries и Ozon: пошаговая инструкция по отгрузке». https://uniseller.io/blog/fbs-otgruzka-wildberries-ozon/
6. mpfact.ru, «Опоздал на 1 час - плати штраф: новые правила FBS на Wildberries и Ozon в 2026 году» (оценки сервиса, не официальные правила площадок). https://mpfact.ru/tpost/shtrafy-za-opozdanie-fbs-wildberries-ozon

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