На сайте продавалось 17 % ассортимента — и это был не баг витрины, а складов

Почему у бренда одежды с 4 000 клиентов на сайте продавалось только 89 SKU

У клиента был магазин в Москве, интернет-магазин на InSales и RetailCRM, за которую платили примерно 200 тыс. ₽ в год. При этом на сайте реально продавалось только 89 SKU из 521 своего товара в наличии — 17 %. Остальное витрина показывала как доступное, но в корзину оно не ложилось.

С кем мы работали и что у них болело

Публично это можно называть так: бренд одежды middle-up, 6 лет на рынке, средний чек 40–50 тыс. ₽, около 4 000 клиентов, магазин в Москве + интернет-магазин на InSales + RetailCRM.

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

Что было сломано до нас

Мы смотрели не по словам, а по API RetailCRM, МойСклад, InSales и ApiShip.

Самая неприятная часть была в складах. InSales смотрел на сумму остатков по всем складам, поэтому на витрине товар как будто был. А корзина резервировала только с приоритетного склада. Там часто стоял ноль. Отсюда и абсурд: товар виден, но купить нельзя.

Плюс шла двойная запись заказов: один и тот же заказ попадал в МойСклад двумя потоками — из InSales и из RetailCRM, с разницей в 15 секунд. В последних 1 000 заказах мы нашли 69 подтверждённых пар дублей.

Что мы сделали сначала, а что пришлось переделать

Сначала я сам ошибся в одной гипотезе: по аудиту казалось, что Ламоду и ВБ надо отключать от сайта. На звонке клиент объяснила, что это витрина допассортимента, и товар выкупается со склада маркетплейса за день. Этот пункт мы из плана убрали. Хороший пример, почему нельзя лечить склад по скриншоту.

Дальше пошли по порядку:

1. Разобрали схему складов и маппинг между МойСклад и InSales.
2. Зафиксировали, что сайт должен продавать со всех складов, а не только с приоритетного.
3. Перестроили логику так, чтобы RetailCRM была мастером заказов и клиентов, а МойСклад — мастером остатков.
4. Отключили лишнюю загрузку заказов в МойСклад, чтобы не плодить дубли.
5. Склеивание дублей оставили штатными методами CRM, но сразу сказали честно: это не лечит причину, если двойная запись останется.
6. Отдельно добивали доставку: включили вывод веса и габаритов, проставили значения по умолчанию, залили данные в 1 775 вариантов и настроили тарифы по умолчанию для интеграций.

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

Что изменилось после внедрения

По доставке у нас есть уже подтверждённые тесты:

• 03.08.2026 — автозаявка в СДЭК для курьера, трек 10302327199, сумма 642,50 ₽;
• 03.08.2026 — автозаявка в СДЭК до ПВЗ, трек 10302397901, сумма 667,50 ₽.

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

По складам и дублям итоговые цифры в документах у нас не зафиксированы в виде красивого «было/стало». Я это специально не буду додумывать. Но уже на этапе аудита было видно, что проблема не в «плохой CRM», а в том, что витрина, склад и заказы жили разными жизнями.

Где мы споткнулись

Первое. Код ПВЗ не удалось добить автоматом с первого захода. Пробовали пять подходов: триггеры RetailCRM, HTTP-запрос из CRM в саму CRM, статусные триггеры, «ПВЗ по умолчанию» в модулях СДЭК и ApiShip. В итоге рабочий внешний скрипт мы написали, но потом сняли по решению клиента — запускать его на ноутбуке было ненадёжно, а сервера под это не было. Я бы в следующий раз сразу закладывал нормальный серверный контур, а не надеялся на «ну у меня же ноут всегда включён».

Второе. СДЭК без региона иногда считал не тот адрес. Без региона он видел не Москву, а деревню Москва в Тверской области. В одном из расчётов это давало 2 467 ₽ вместо 642 ₽. Очень бытовая ошибка, но на ней легко сжечь и время, и нервы.

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

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

Что можно перенести к себе

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

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