Покупатель спрашивает, есть ли товар в наличии. Менеджер видит в карточке 20 единиц и обещает отправку. Но пять единиц уже зарезервированы под заказы с сайта, ещё три — под маркетплейс. Фактически продать можно только 12.
Проблема здесь не в плохой CRM. Просто CRM управляет клиентом и сделкой, а WMS — товаром и операциями на складе. Если компания продаёт физические товары через сайт, мессенджеры и маркетплейсы, эти системы должны не подменять, а дополнять друг друга.
Разберём, где проходит граница между CRM и WMS, когда можно обойтись одной системой и как связать клиентов, заказы, резервы и остатки без ручного копирования.
Коротко: чем отличаются CRM и WMS
CRM нужна для лидов, сделок и коммуникаций. В ней менеджер видит, откуда пришёл клиент, о чём спрашивал, что ему предложили, оплатил ли он заказ и когда нужно связаться снова.
WMS нужна для физического движения товара. Она хранит данные о приёмке, ячейках, резервах, подборе, сборке, упаковке, маркировке, отгрузке и действиях сотрудников.
Для продавца на маркетплейсах таким WMS-контуром может стать SelSup: система управляет остатками, резервами, сборкой, маркировкой и отгрузкой заказов.
Услугам и цифровым продуктам часто достаточно CRM. Селлеру, который получает готовые заказы из кабинетов маркетплейсов, основой может стать WMS. Интернет-магазину с собственными клиентами, оптовыми сделками и несколькими каналами продаж обычно нужна связка систем.
CRM и WMS отвечают на разные вопросы
Главная сущность CRM — клиент и сделка. Главная сущность WMS — товар и складская операция.
| Вопрос бизнеса | CRM | WMS |
| Кто обратился и из какого канала | Да | Нет |
| На каком этапе находится сделка | Да | Нет |
| Что клиент покупал раньше | Да | Получает из заказа, но не заменяет клиентскую историю |
| Сколько товара физически лежит на складе | Обычно нет точного складского среза | Да |
| Сколько товара уже зарезервировано | Только если данные пришли из складского контура | Да |
| В какой ячейке лежит товар | Нет | Да |
| Кто и когда собрал заказ | Видит после передачи статуса | Да |
| Проверена ли маркировка при сборке | Нет | Да, если процесс настроен в WMS |
| Когда менеджеру снова связаться с покупателем | Да | Нет |
Разница особенно заметна в момент обещания клиенту. CRM знает, кто покупатель, что он выбрал и на каком этапе находится заказ. Но ответ «товар есть» должен опираться не на карточку сделки, а на данные склада.
Физический остаток, доступный остаток и резерв — не одно и то же. Товар может лежать на полке, но уже быть закреплён за другим заказом. Именно WMS должна решить, какую единицу можно продать, где её найти и кому выдать задание на сборку.
Почему справочник товаров в CRM не заменяет складской учёт
Во многих CRM можно создать справочник товаров, добавить цену, прикрепить позицию к сделке и сформировать документ. Для менеджера этого достаточно, чтобы подготовить предложение или выставить счёт. Но справочник не отвечает на все вопросы склада.
На складе важно понимать:
- где лежит конкретная единица;
- доступна ли она для продажи или уже зарезервирована;
- из какой партии её нужно отобрать;
- требуется ли код маркировки;
- кто получил задание на сборку;
- прошёл ли заказ проверку перед упаковкой;
- какой статус уже передан маркетплейсу.
CRM фиксирует обещание клиенту, WMS проверяет, можно ли его выполнить. Если системы не связаны, менеджер может продать товар, который склад уже отложил для другого канала.
Когда достаточно только CRM
CRM может быть единственной рабочей системой, если компания продаёт услуги, консультации, обучение или цифровые продукты. Здесь нет физического остатка, ячеек и сборки. Основная задача — обработать обращение и провести человека по воронке до оплаты.
Для небольшого интернет-магазина CRM тоже может временно закрыть основные процессы, если:
- товаров мало;
- склад один;
- заказы собирает один человек;
- нет одновременных продаж на нескольких площадках;
- остатки легко проверить вручную;
- нет сложной маркировки, комплектов и правил резервирования.
Плюс такого подхода — быстрый запуск. Минус проявится при росте заказов: сотрудники начнут обновлять таблицы, сверять кабинеты и уточнять наличие в чатах. Если одна цифра поддерживается вручную в нескольких местах, ей быстро перестают доверять.
Когда продавцу нужна WMS
WMS становится необходимой не при определённом обороте, а при усложнении операций. Один сотрудник может спокойно обработать большой поток однотипных заказов, а крупная команда — запутаться в нескольких сложных отгрузках. Поэтому ориентироваться нужно на процесс.
Признаки, что ручного учёта уже недостаточно:
- один физический остаток продаётся через несколько каналов;
- заказы нужно распределять между складами или зонами сборки;
- сотрудники тратят время на поиск товара;
- появляются пересортица и недовложения;
- нужно фиксировать действия сборщиков;
- товар подлежит обязательной маркировке;
- комплекты собираются из общего физического остатка;
- остатки приходится вручную менять в нескольких кабинетах;
- о проблеме узнают только после отмены или просрочки.
WMS превращает заказ в последовательность проверяемых операций: резерв, задание, поиск ячейки, сканирование, сборка, упаковка и отгрузка.
Для сотрудника это понятный маршрут без поиска по таблицам и чатам. Для руководителя — история действий: кто собирал заказ, на каком шаге возникла задержка и почему изменился остаток.
Когда CRM и WMS нужны вместе
Связывать системы нужно не каждому продавцу. Если компания работает только с маркетплейсами, отдельная CRM может вообще не участвовать в обработке заказа: он поступает с площадки в WMS, где продавец управляет остатками, резервом, сборкой, маркировкой и отгрузкой.
Связка становится полезной, когда компания одновременно работает с покупателями и физическим товаром. Например:
- принимают заказы на собственном сайте и продают на маркетплейсах;
- ведут оптовые сделки с согласованием цены и параллельно отгружают розничные заказы;
- продают товары с длительным циклом выбора;
- возвращают покупателей за повторными заказами;
- управляют несколькими складами, магазинами или юридическими лицами;
- хотят показывать менеджеру реальный доступный остаток до обещания срока клиенту.
CRM хранит историю отношений и управляет сделкой. WMS подтверждает наличие, резервирует товар и управляет исполнением заказа.
| Что получает бизнес | Польза | Цена решения |
| Общая история клиента и сделки | Менеджер продолжает общение с нужного места | Нужно определить, какая система хранит главные данные о клиенте |
| Актуальный доступный остаток | Меньше отмен из-за продажи отсутствующего товара | Нужна стабильная передача заказов и резервов |
| Автоматическая передача статусов | Клиент быстрее получает информацию о заказе | Статусы двух систем необходимо сопоставить |
| Разделение ролей | Продажи и склад работают в подходящих интерфейсах | Нужны единые правила и ответственный за интеграцию |
Связка полезна только тогда, когда сотрудникам не приходится переносить данные между системами вручную. Иначе компания получает два интерфейса, но сохраняет прежние ошибки.
Менеджеру не нужно знать, в какой ячейке лежит товар, а сборщику — видеть историю переписки с покупателем. Каждый работает в своей системе, но получает результат работы соседнего контура.
Если готового коннектора между выбранными системами нет, до запуска отдельно оценивают техническую возможность, состав передаваемых данных и обработку ошибок.
Как SelSup закрывает задачи WMS
SelSup — самостоятельная WMS для FBS-продаж на маркетплейсах со встроенным товарным и складским учётом. FBS — схема, при которой продавец хранит, собирает и упаковывает заказ на своём складе, а затем передаёт его маркетплейсу для доставки покупателю. В SelSup продавец работает с товарами, физическим и доступным остатком, резервами, заказами, складами, ячейками и заданиями на сборку.
Для FBS-заказа SelSup связывает весь маршрут: остаток, резерв, задание, подбор, сборку, маркировку, печать, упаковку, отгрузку и историю действий. Сотрудник получает задание и подтверждает товар сканированием, а продавцу не приходится перед сборкой вручную сверять заказ с отдельной таблицей. Если один физический остаток используется в нескольких комплектах, после заказа система пересчитывает доступность связанных наборов.
SelSup можно использовать как основной складской контур или встроить в действующую учётную архитектуру с 1С, «МойСкладом» либо внешней WMS. Внедрение не должно ломать уже работающий учёт: архитектура зависит от того, где находятся главные данные и какие процессы нельзя прерывать.
Как связать CRM и WMS без двойного учёта
Главная ошибка интеграции — пытаться хранить и исправлять все данные сразу в обеих системах. Тогда остаток меняют в CRM, WMS и таблице, но ни одна цифра не выглядит надёжной.
Сначала определите единственный источник истины для каждого типа данных:
- CRM отвечает за клиента, контактные данные, обращения, задачи и этап сделки;
- WMS отвечает за товар, физический и доступный остаток, резерв, ячейку и статус складской операции;
- бухгалтерская или управленческая система отвечает за регламентированный учёт, если он ведётся отдельно;
- маркетплейс остаётся источником собственного заказа и площадочного статуса.
После этого опишите не только поля, но и событие, которое запускает передачу.
| Что передаём | Направление | Когда передаём | Что проверяем |
| Подтверждённый заказ, SKU и количество | CRM → WMS | После подтверждения заказа | Все позиции сопоставились, дубль не создался |
| Результат резервирования | WMS → CRM | Сразу после попытки резерва | Менеджер видит успех или конкретный дефицит |
| Статус сборки и отгрузки | WMS → CRM | При каждом значимом изменении | Статусы систем однозначно сопоставлены |
| Отмена или возврат | CRM ↔ WMS | После подтверждения события | Резерв снят, доступный остаток пересчитан |
| Ошибка обмена | В обе стороны | При сбое операции | Есть понятная ошибка и повторная обработка |
Какой способ интеграции выбрать
Готовый коннектор подходит, если он поддерживает нужные сущности, статусы и сценарии ошибок. API используют, когда процесс индивидуальный или данные должны передаваться сразу после события. Вебхуки помогают системе сообщить о новом событии, а принимающей стороне — не проверять изменения каждую минуту. Файловый обмен по расписанию допустим для первоначальной загрузки и некритичных справочников, но для заказов, резервов и статусов он создаёт задержку.
Способ интеграции выбирают по допустимой задержке и поведению при сбое. Если одна система временно недоступна, заказ должен попасть в очередь повторной отправки, а ответственный сотрудник — увидеть ошибку.
Пять этапов рабочего маршрута
Ниже — маршрут заказа, который поступил в CRM с собственного сайта, из мессенджера или через отдел продаж. Заказ с маркетплейса может поступать в WMS напрямую, минуя CRM.
- Передача заказа. После подтверждения сделки CRM передаёт номер заказа, состав, количество, способ доставки и необходимые данные получателя. Товары сопоставляются по стабильному идентификатору — артикулу или SKU, а не по названию.
- Создание резерва. WMS проверяет доступный остаток и резервирует нужное количество. Если позиции нет, система возвращает понятный результат, а не оставляет заказ без движения.
- Сборка и контроль. Сотрудник получает задание, идёт по маршруту и подтверждает товар сканированием. Штрихкод товара, этикетка заказа и Data Matrix — разные объекты, их нельзя смешивать в одном поле.
- Возврат статуса. После сборки или отгрузки WMS передаёт статус обратно. Менеджер видит его в CRM и может сообщить клиенту, что заказ готов или передан в доставку.
- Обновление доступности. После резерва, отмены или возврата WMS пересчитывает доступный остаток. Если один товар входит в несколько комплектов, доступность связанных наборов тоже меняется.
Вернёмся к примеру из начала статьи. На складе физически лежат 20 единиц, но восемь уже зарезервированы. WMS возвращает в CRM доступный остаток — 12 единиц, поэтому менеджер обещает клиенту только то количество, которое действительно можно зарезервировать и собрать.
Как проверить связку до полноценного запуска
Не начинайте с переноса всей базы и десятков статусов. Возьмите один реальный товар и проведите один тестовый заказ по полному маршруту.
Проверка должна ответить на семь вопросов:
- Создался ли заказ без ручного копирования?
- Совпал ли товар по артикулу или SKU?
- Уменьшился ли доступный остаток после резерва?
- Получил ли склад понятное задание?
- Можно ли подтвердить правильность товара при сборке?
- Вернулся ли статус в CRM?
- Восстановился ли остаток после тестовой отмены?
Один полностью проверенный маршрут полезнее десятка настроенных, но не испытанных обменов. После него можно добавлять новые склады, типы заказов, возвраты и комплекты.
Частые ошибки при внедрении
❌ Пытаться превратить CRM в WMS. Карточка товара и поле «остаток» не заменяют резервы, ячейки и контроль сборки. Менеджер видит количество, которому нельзя доверять. Решение — оставить складские данные в WMS.
❌ Оставить параллельную таблицу. Если сотрудник может исправить остаток в трёх местах, скоро появятся три разные цифры. Решение — определить единственный источник истины и закрыть ручное дублирование.
❌ Передавать товар по названию. Названия меняются, повторяются и содержат опечатки. Решение — сопоставлять позиции по стабильному идентификатору.
❌ Смешивать состояния товара. Физический остаток, доступный остаток, резерв и товар в пути нельзя складывать в одну колонку «есть». Решение — хранить состояния раздельно и заранее определить правила переходов.
❌ Автоматизировать только счастливый путь. Отмена, частичная сборка, возврат, нехватка товара и недоступность системы случаются в реальной работе. Решение — протестировать каждый сценарий до запуска.
❌ Не назначить владельца процесса. Без ответственного ошибки обмена остаются незамеченными. Решение — определить, кто следит за журналом, повторной отправкой и изменениями статусов.
Что выбрать: CRM, WMS или связку
Только CRM подходит компании, у которой главный объект работы — клиент и сделка, а физического склада нет или его процессы пока просты.
WMS как основная операционная система подходит селлеру, который получает готовые заказы из маркетплейсов и прежде всего должен точно управлять товаром, резервами и отгрузками.
CRM и WMS вместе нужны бизнесу, который одновременно управляет отношениями с покупателями и сложным движением товаров.
Не выбирайте систему только по списку функций. Возьмите один заказ и пройдите путь от первого обращения до изменения остатка после отгрузки. Если на каком-то шаге сотруднику приходится переносить данные вручную, искать товар по складу или уточнять статус в чате, именно там проходит следующая граница автоматизации.
