Заказы из WeChat не попадают в CRM: как закрыть дыру в продажах

Китайский канал продаж ожил: Mini Program в WeChat принимает заказы, клиенты платят, маркетинг радуется графику. А в российской CRM тишина. Менеджеры узнают о заявках из скриншотов в чате или из Excel, который «выгружает партнёр раз в день». Склад резервирует мимо. Клиент в WeChat спрашивает статус, а в Bitrix24 сделки ещё нет.

Так выглядит разрыв между витриной и операционкой. Mini Program живёт своей жизнью, 1С и CRM — своей. Пока заказов мало, ручной мост терпят. Когда канал становится заметным, fulfillment ломается: кто-то не видит оплату, кто-то отгружает не тот адрес, кто-то обещает срок, которого нет в учётной системе.

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

Отдельно страдает аналитика. Маркетинг считает ROI канала по Mini Program, финансы — по выгрузке из 1С, продажи — по CRM. Три цифры, три правды, один и тот же вопрос на планёрке: «так сколько мы вообще продали?»

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

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

Где рвётся цепочка от Mini Program до отгрузки

Сценарий первый — заказ «застрял» в WeChat. Оплата прошла, в Mini Program статус «принят», а в CRM пусто, потому что уведомление не настроено или падает без алерта. Клиент ждёт подтверждения. Менеджер ничего не знает.

Сценарий второй — частичный ручной ввод. Заявки заносят выборочно: крупные — да, мелкие — «потом». Остатки и приоритеты отгрузки искажаются. Аналитика канала врёт, потому что в CRM видна только часть правды.

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

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

Ошибки при запуске WeChat-коммерции

Считать Mini Program «отдельным сайтом для Китая» без владельца интеграции с ядром. Запускать оплату и каталог раньше, чем согласованы статусы и master-система по заказу. Хранить критичные данные только на стороне подрядчика Mini Program без доступа компании к логам и выгрузкам.

Ещё одна ловушка — пытаться «упростить» через ежедневный Excel. Это не упрощение, а отложенный операционный долг с гарантированным ростом ошибок по мере объёма.

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

Как должен выглядеть рабочий контур

Заказ в WeChat — это событие. Оно должно создавать сущность в CRM или в промежуточном слое, резервировать или ставить задачу складу, отражать оплату и возвращать статусы обратно в Mini Program. Для этого нужен явный контракт: идентификаторы заказа, состав корзины, адрес, контакты, сумма, валюта, статус оплаты, статус fulfillment.

Важно заранее решить, кто master. Часто удобная схема: коммерческий статус и коммуникация с клиентом ведутся в CRM или service-слое, складской учёт — в 1С, WeChat остаётся каналом витрины и уведомлений. Без этого решения каждая сторона будет «чуть чуть править у себя» и снова разъедет данные.

Технически обычно ставят промежуточный слой: приём событий WeChat, нормализация, очередь, доставка в Bitrix и 1С, журнал и повторы. Прямая хрупкая склейка «Mini Program дергает CRM напрямую» живуча только на демо.

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

Практика внедрения без остановки продаж

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

Параллельно включите контроль: алерт, если заказ не создался в CRM за оговорённое число минут; сверка дневных итогов WeChat против CRM и 1С; ручной аварийный ввод только как исключение с пометкой источника.

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

• сделайте заказ событием с гарантированной доставкой в CRM и учёт;
• верните статусы отгрузки обратно в WeChat;
• назначьте master-системы для денег, склада и коммуникации;
• логируйте и алертите разрывы, не узнавайте о них от клиента;
• уберите Excel-мост как основной процесс.

Что даёт связка канала и операционки

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

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

Появляется и сервисный эффект: поддержка отвечает быстрее, потому что история заказа уже в CRM, а не в переписке с подрядчиком Mini Program.

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

Если Mini Program уже продаёт, а CRM и 1С об этом узнают с опозданием, закройте разрыв через разработку приложений для WeChat: события заказа, обмен статусами и операционный контур без Excel-моста.

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