У одного нашего клиента интернет-магазин начал терять деньги не из-за падения трафика или роста конкуренции. Просто на сайте показывалось, что товар есть, а на складе уже нет. Потому что остатки обновлялись вручную. Менеджер по утрам сверял Excel-файлы из 1С, сайта и Wildberries. Иногда забывал. Иногда ошибался. А клиенты всё равно оформляли заказы.
Когда таких ситуаций стало слишком много, они пришли к нам, чтобы перестать терять клиентов из-за технического хаоса.
Что на самом деле происходит, когда магазин растёт
Сначала всё просто: сайт, пара товаров, заказы приходят редко, можно вбивать всё вручную. Но как только появляется второй канал продаж (Ozon, Яндекс Маркет), третий (CRM для email-рассылок), четвёртый (служба доставки) начинается рассогласование.
- В 1С цена изменилась, а на сайте нет.
- На Wildberries остаток обнулился, но в 1С этого ещё не видно.
- Клиент купил через сайт, а менеджер в CRM даже не знает, что он существует.
- Заказ ушёл в СДЭК, но адрес написан кириллицей, а система требует латиницу и посылка зависает.
Это естественный результат того, что системы не связаны между собой.
Почему готовые модули часто не спасают
Многие думают: «Поставлю модуль для 1С и всё заработает». Иногда так и бывает. Но только если у вас простой каталог, фиксированные цены и нет комплектов.
А если у вас:
- наборы, где состав меняется в зависимости от акции,
- цены, которые зависят от региона или истории покупок,
- предзаказы, частичные отгрузки, возвраты,
тогда стандартный обмен CommerceML ломается. Потому что он не умеет интерпретировать бизнес-логику. Он просто передаёт данные как есть.
В одном проекте артикул в 1С содержал слэш: «КР-7/2». На Wildberries такой символ запрещён. Загрузка падала. Каждый раз кто-то вручную правил названия. Это продолжалось полгода, пока не сделали промежуточный сервис, который сам подставляет допустимый формат под каждую площадку.
Как мы сейчас строим связи между системами
Сначала садимся с логистом, менеджером, бухгалтером и смотрим, как всё работает на самом деле. Потому что документация и реальность часто расходятся.
Например, в теории возврат должен проходить через 1С → сайт → CRM. А на практике клиент звонит менеджеру, тот вбивает всё вручную в Excel, а потом «как-нибудь» внесёт в систему. Если не забудет.
Только после этого проектируем обмен. И почти всегда добавляем буферную зону промежуточный сервис, который:
- проверяет форматы,
- временно резервирует остатки при оформлении заказа,
- повторяет отправку, если API маркетплейса не ответил,
- логирует всё, что пошло не так.
Это способ не сойти с ума, когда систем пять, а человека два.
Что реально меняется после нормальной интеграции
В последнем проекте:
- заказы стали обрабатываться за 7 минут вместо 45,
- количество отмен из-за «нет в наличии» упало на 89%,
- менеджеры перестали работать по вечерам, потому что перестали исправлять чужие ошибки.
А владелец впервые за два года уехал в отпуск без телефона. Потому что знал: если что-то пойдёт не так, система сама пришлёт уведомление, а не клиент с жалобой.
Когда пора задуматься об этом
Если вы:
- тратите больше часа в день на сверку остатков или заказов,
- боитесь запускать распродажи, потому что «всё сломается»,
- получаете жалобы вроде «купил, а потом сказали нет в наличии»,
значит, вы уже переросли ручное управление.
Интеграция нужна, чтобы перестать быть клеем между своими же системами. Чтобы данные текли сами, а вы могли заниматься бизнесом, а не бороться с Excel.
P.S. Один клиент недавно сказал: «Вы не программисты. Вы люди, которые вернули мне сон». Думаю, это лучшая характеристика хорошей интеграции.
Если вы планируете запускать или перестраивать интернет-магазин — лучше сразу заложить правильную архитектуру. Мы делаем такие проекты под ключ: от проектирования до интеграции с 1С, CRM, маркетплейсами и службами доставки. Подробнее на странице разработка интернет-магазина.