Сколько стоит отсутствие актуальных остатков

Типичная ситуация выглядит так:

• на сайте указано 8 единиц товара;
• клиент заказывает 6;
• менеджер подтверждает заказ;
• склад обнаруживает только 3;
• часть товара уже была зарезервирована другим заказом;
• информация об этом ещё не дошла до сайта или CRM.

После этого начинается ручное исправление ситуации.

Нужно:

1. проверить остатки повторно;
2. связаться со складом;
3. найти товар на другом складе;
4. подобрать аналог;
5. согласовать замену с клиентом;
6. пересчитать заказ;
7. изменить документы;
8. изменить доставку;
9. при необходимости вернуть оплату.

Одна ошибка в остатках может затронуть сразу несколько сотрудников.

Как устроены резерв, несколько складов и защита от перепродажи — в FAQ про склад и остатки.

Возьмём условную компанию.

Это не реальные данные конкретного бизнеса, а пример расчёта.

Предположим:

• 40 заказов в день;
• в 5% заказов возникает проблема с остатками;
• на обработку одного такого случая уходит в среднем 18 минут;
• 22 рабочих дня в месяц.

Количество проблемных заказов:

40 × 5% = 2 заказа в день

Теперь считаем время:

2 заказа × 18 минут × 22 дня

Получаем:

792 минуты

или:

13,2 часа в месяц

На первый взгляд не так много.

Но это только время на обработку проблемных случаев.

В расчёт пока не входят:

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

Ошибку в остатках часто считают только как потерю времени менеджера.

Но цепочка может быть длиннее.

Например:

Менеджер проверяет заказ и звонит клиенту.

Склад повторно проверяет наличие.

Закупщик ищет товар у поставщика.

Бухгалтерия делает возврат или корректировку.

Логистика переносит доставку.

Если каждый сотрудник тратит по несколько минут, одна ошибка начинает стоить уже не 10–15 минут, а суммарно гораздо больше.

Базовая формула:

Количество проблемных заказов × среднее время обработки × стоимость рабочего часа

Но лучше считать по ролям.

Например:

Менеджер + склад + бухгалтерия + логистика

Если один проблемный заказ требует:

• 10 минут менеджера;
• 7 минут склада;
• 5 минут бухгалтерии;
• 6 минут логиста,

получаем:

10 + 7 + 5 + 6 = 28 минут

При 40 таких случаях в месяц:

40 × 28 минут

получаем:

1120 минут

или:

18,7 часа

И это всё ещё только рабочее время сотрудников.

Более серьёзный сценарий — когда клиент уже оформил или оплатил заказ.

Тогда возможны:

• полный отказ от заказа;
• частичный отказ;
• замена товара;
• перенос срока;
• возврат денег.

Стоимость такой ситуации нужно считать отдельно.

Например:

Количество отменённых заказов × средняя маржа заказа

Здесь важно использовать собственные данные компании.

Не средний чек вообще, а именно то, сколько бизнес реально теряет на отменённом заказе.

Иногда компания знает, что данным нельзя доверять.

Поэтому менеджеры перестраховываются.

Перед каждым подтверждением заказа они:

• звонят на склад;
• проверяют 1С;
• пишут кладовщику;
• открывают таблицу;
• уточняют наличие у поставщика.

В этом случае проблема проявляется уже даже тогда, когда ошибок нет.

Например:

• 40 заказов в день;
• 2 минуты на ручную проверку;
• 22 рабочих дня.

Расчёт:

40 × 2 × 22

получаем:

1760 минут

или:

29,3 часа в месяц

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

Остаток может быть технически правильным, но фактически недоступным.

Например:

на складе 10 единиц.

Из них:

• 4 уже зарезервированы;
• 2 находятся в сборке;
• 1 списана, но ещё не проведена;
• 3 действительно доступны.

Если сайт показывает просто:

Остаток: 10

то клиент получает неверную информацию.

Поэтому важно различать:

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

Представим ситуацию.

Два клиента одновременно оформляют один и тот же товар.

Система показывает:

5 единиц

Первый клиент заказывает 4.

Но резерв не создаётся сразу.

Второй клиент спустя несколько минут заказывает ещё 3.

Формально система приняла заказ на 7 единиц при наличии 5.

После этого один заказ приходится исправлять.

Если такие ситуации повторяются регулярно, это уже не исключение, а системная проблема.

Если компания работает с несколькими складами, одного числа «остаток» недостаточно.

Например:

• Минск — 2;
• Москва — 5;
• склад поставщика — 12.

На сайте отображается:

В наличии: 19

Но реальный вопрос клиента может звучать так:

Можно ли получить 8 единиц завтра?

Ответ уже зависит не от общего остатка, а от:

• географии;
• сроков перемещения;
• резервов;
• логистики;
• графика склада.

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

Остатки по складам в кабинете дилера — в дилерском портале сантехники; доступное количество из учёта — в B2B-портале с 1С.

Когда система не умеет автоматически учитывать склады, менеджер начинает делать это вручную.

Например:

1. проверить основной склад;
2. проверить второй;
3. написать коллеге;
4. уточнить возможность перемещения;
5. пересчитать срок доставки.

Если такая проверка занимает 6 минут и происходит 15 раз в день:

15 × 6 × 22

получаем:

1980 минут

или:

33 часа в месяц

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

Остатки могут обновляться не в реальном времени, а по расписанию.

Например:

• каждые 24 часа;
• раз в 6 часов;
• раз в час.

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

Особенно это заметно при:

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

Проблема усиливается, если товар продаётся одновременно через:

• сайт;
• маркетплейс;
• менеджеров;
• офлайн-магазин;
• дилерский портал;
• телефонные заказы.

Каждый канал может уменьшать остаток.

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

Иногда сотрудники сами обновляют остатки.

Например:

• выгружают Excel;
• меняют значения;
• импортируют файл;
• проверяют ошибки.

Если процесс занимает 30 минут два раза в день:

30 минут × 2 × 22 дня

получаем:

1320 минут

или:

22 часа в месяц

Почти три рабочих дня только на поддержание актуальности данных.

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

Например:

К сожалению, товара нет.

Клиент отвечает:

А когда появится?

Менеджер уточняет у закупщика.

Клиент спрашивает:

А есть аналог?

Менеджер ищет аналог.

Клиент спрашивает:

А цена та же?

Появляется новая цепочка работы.

То есть ошибка в одной цифре превращается в отдельный мини-процесс.

Если товара нет, менеджер часто ищет аналог.

Например:

• 25 проблемных заказов в месяц;
• 12 минут на подбор замены.

Расчёт:

25 × 12 минут

получаем:

300 минут

или:

5 часов

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

После замены часто пересобирают документы: повторное формирование счёта и новая версия КП.

После замены товара может потребоваться:

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

Если на это уходит ещё 15 минут:

25 × 15 минут

получаем:

375 минут

или:

6,25 часа

Теперь одна проблема с остатком создала уже:

5 + 6,25 = 11,25 часа

дополнительной работы.

Иногда заказ отправляют частями.

Например, клиент заказал 10 товаров.

Девять есть.

Одного нет.

Компания решает:

• отправить основную часть сейчас;
• недостающий товар позже.

В итоге возникает вторая:

• сборка;
• упаковка;
• накладная;
• отгрузка;
• доставка.

Такую стоимость нельзя считать универсальной.

У каждой компании свои расходы.

Но эту статью можно использовать как повод начать измерять:

Сколько дополнительных отправлений в месяц возникает из-за ошибок в остатках?

Самый неприятный сценарий — клиент отказывается ждать.

Тогда компания теряет не только время.

Она может потерять сам заказ.

Формула:

Отменённые заказы × средняя маржа

Например, если за месяц из-за отсутствия товара отменяется 8 заказов, компания может посмотреть фактическую маржу этих заказов.

Это будет реальная, а не модельная стоимость ошибки.

Важно не завышать эффект.

Если товар отсутствует, клиент может:

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

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

Лучше разделять:

• успешно заменён;
• перенесён;
• частично выполнен;
• полностью отменён.

До разработки новой системы можно провести простой замер.

В течение месяца фиксировать каждый случай:

В конце месяца можно получить:

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

После этого проблему уже можно оценивать в деньгах.

Полезно фиксировать:

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

Эти показатели покажут не просто наличие проблемы, а её источник.

В зависимости от бизнеса система может:

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

Вместо:

1С → Excel → менеджер → сайт

можно использовать:

1С / WMS → API → сайт / B2B-портал / CRM

Изменение остатка происходит в учётной системе.

После этого данные автоматически передаются в остальные каналы.

Заказ также может создавать резерв.

Обмен остатками, резервом и заказами с учётной системой — интеграция Laravel с 1С.

Не каждой компании нужна синхронизация каждую секунду.

Если продаются:

• дорогие товары;
• небольшое количество заказов;
• большие складские запасы;

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

Если же:

• остатков мало;
• заказов много;
• продажи идут по нескольким каналам;

то задержка становится критичной.

То есть частоту синхронизации нужно выбирать исходя из процесса, а не по принципу:

Чем чаще, тем лучше.

Автоматическая синхронизация сама по себе не гарантирует актуальность.

Интеграция может перестать работать.

Поэтому важно контролировать:

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

Хорошая система должна не просто синхронизировать данные, но и показывать, когда синхронизация нарушена.

Предположим, сейчас компания имеет:

• 40 заказов в день;
• 2 проблемных заказа;
• 18 минут на каждый.

Получаем:

2 × 18 × 22 = 792 минуты

или:

13,2 часа

Дополнительно менеджеры проверяют наличие вручную:

40 × 2 минуты × 22 = 1760 минут

или:

29,3 часа

Общие затраты времени:

13,2 + 29,3 = 42,5 часа в месяц

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

Например, остаётся:

8 часов в месяц

Тогда модельная экономия:

42,5 − 8 = 34,5 часа

Это не обещание результата.

Фактический эффект зависит от конкретной компании.

Формула:

Сэкономленные часы × фактическая стоимость часа

Отдельно можно добавить:

+ предотвращённые отмены

+ сокращение дополнительных доставок

+ сокращение возвратов

+ уменьшение количества ручных операций

Лучше считать каждый блок отдельно.

Так будет видно, откуда появляется экономический эффект.

Если компания:

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

то сложная интеграция может не окупиться.

Иногда достаточно:

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

Отсутствие актуальных остатков — это не только проблема каталога.

Оно создаёт цепочку дополнительных расходов:

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

Поэтому стоимость проблемы лучше считать формулой:

Ручная проверка + обработка ошибок + замены + дополнительные операции + реальные отмены

Первый шаг — не разработка новой системы.

Сначала нужно измерить:

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

После этого можно определить, что дешевле:

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

Главное — считать не одну ошибку.

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