CRM видит заявку, склад — нет: как срослась 1С-мобилка торгового представителя

Мобильное приложение и CRM интегрируют через обмен данными в реальном времени: заявка, созданная торговым представителем на планшете, сразу попадает в CRM и одновременно резервируется на складе в 1С. Без прямой связки с учётной системой приложение показывает остатки на вчера, а менеджер узнаёт о браке заказа только от клиента.

случай: заявка есть, товара нет

Торговый представитель компании, которая возит бытовую химию по розничным точкам Москвы и области, оформил заказ в мобильном приложении в 11:14. CRM зафиксировала сделку сразу. Но склад узнал о заказе только в 11:52, когда менеджер вручную перенёс позиции в 1С — так было заведено с момента, когда приложение подключали «на скорую руку» и синхронизацию с учётной системой отложили на потом.

За эти 38 минут кладовщик успел отгрузить последние три паллеты того же товара под другой заказ. Торгпред уже подтвердил клиенту дату поставки, клиент отменил заказ у конкурента в пользу этой компании — и получил отказ. Заказ на 340 тысяч рублей ушёл, а торговый представитель узнал об этом на следующий день, когда клиент позвонил ругаться.

Причина не в криворуких сотрудниках, а в архитектуре: CRM и 1С жили отдельно, приложение писало только в CRM, а остатки товара считались вручную раз в час. Пока данные шли через человека, любая задержка превращалась в потерянный заказ.

что теряет бизнес, пока CRM и склад говорят на разных языках

Компания посчитала цену простоя за квартал: три похожих случая с потерей заказа, отмена одной оптовой поставки клиентом и порядка 15 часов рабочего времени менеджеров на ручную сверку заявок между CRM и 1С каждую неделю. При ставке менеджера это уже не мелочь, а статья расходов, которую никто не закладывал в бюджет на CRM.

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

как устроена рабочая интеграция: три уровня связи

уровень 1: одностороннее API

Приложение читает остатки из 1С через API раз в 15–30 минут и показывает их менеджеру. Заказ создаётся в CRM, в 1С попадает вручную или по расписанию. Подходит для компаний с редкими заказами и небольшим ассортиментом, где расхождение остатков за полчаса не критично.

уровень 2: двусторонний обмен по событию

Создание заказа в приложении сразу триггерит запись в 1С и резерв товара; изменение остатков в 1С (приход, списание, инвентаризация) обновляет данные в приложении и CRM без задержки на расписание. Именно этот уровень закрыл случай с торговым представителем выше.

уровень 3: единая шина данных с очередью

Обмен идёт через промежуточный сервис-очередь, который гарантирует доставку сообщения даже при коротком отключении 1С или CRM — заказ не теряется, а ждёт в очереди и применяется, как только система снова доступна. Нужен компаниям с несколькими точками продаж и высокой частотой заказов, где потеря одного сообщения об обмене стоит дорого.

сравнение трёх уровней интеграции

почему интеграция ломается на живом сервере, а не в тестах

На тестовом стенде с двумя пользователями обмен между приложением и 1С работает без сбоев. Но на боевой базе с 30–40 одновременными подключениями, когда менеджеры формируют отчёты по продажам, а торговые представители одновременно шлют заказы с полей, база 1С начинает тормозить именно в момент обмена — и приложение получает ответ с задержкой в несколько секунд вместо мгновенного.

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

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

как выбрать вариант интеграции под свой бизнес

Компаниям с одним складом и небольшим потоком заказов хватает разработки мобильного приложения с базовой интеграцией с 1С по расписанию — это дешевле и быстрее внедрить, риск потери заказа при задержке в 15–20 минут невысок.

Торговым сетям и оптовикам с несколькими точками и полевыми торговыми представителями, как в разобранном случае, нужен двусторонний обмен по событию или полноценное B2B-приложение с интеграцией 1С, где заказ, остаток и статус клиента синхронизированы в реальном времени между CRM, приложением и складом.

Разработка такого приложения с интеграцией начинается от 500 000 рублей — сумма зависит от количества сущностей для обмена (заказы, остатки, цены, статусы клиентов) и от того, встроена ли CRM в 1С или работает отдельным сервисом, с которым нужно строить дополнительный мост.

что проверить перед тем, как заказывать интеграцию

• ✓сколько времени в среднем проходит между созданием заказа в приложении и его появлением на складе — если больше 10 минут, это уже риск
• ✓проходит ли текущий сервер 1С тест Гилёва с запасом под пиковую нагрузку, а не только под средний день
• ✓что происходит с заказом, если на 30 секунд пропадает связь между приложением и 1С — теряется он или ждёт в очереди
• ✓видит ли торговый представитель актуальный остаток товара в момент оформления заказа, а не остаток на начало дня

Ответы на эти четыре вопроса обычно показывают, где именно теряются заказы — в коде интеграции, в мощности сервера или в отсутствии очереди на случай сбоя связи.

❓ Частые вопросы

Сколько стоит интеграция мобильного приложения с CRM и 1С?

Разработка приложения с интеграцией начинается от 500 000 рублей. Итоговая цена зависит от количества сущностей для обмена — заказы, остатки, цены, статусы клиентов — и от того, встроена ли CRM в 1С или это отдельный сервис.

Почему заказ из приложения появляется в 1С с задержкой?

Чаще всего дело не в коде интеграции, а в расписании обмена (раз в 15-30 минут вместо мгновенной передачи по событию) либо в слабом сервере 1С, который не успевает обработать запрос при высокой нагрузке от нескольких каналов одновременно.

Что будет с заказом, если во время оформления пропадёт интернет?

Зависит от уровня интеграции. При простом одностороннем API заказ может потеряться и его придётся вносить вручную. При интеграции через шину данных с очередью сообщение сохраняется и применяется, как только связь восстановится.

Как понять, что сервер 1С не тянет нагрузку от мобильного приложения?

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

Нужна ли отдельная CRM, если уже используется 1С?

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