Сайт, склад, CRM и ИИ: единая система интернет-продаж

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

Статья для собственника компании, у которой уже есть несколько систем, несколько подрядчиков и ручные передачи данных между ними: выгрузки в таблицу, пересылка заказов в мессенджере, остатки «по звонку». Разбираем, какие системы нужны и за что каждая отвечает, где находятся главные данные, как проходит заказ, какие обмены обязаны работать без ИИ, где агент действительно полезен, как предотвращать дубли и циклические обновления, как организовать журнал и мониторинг, как распределить ответственность подрядчиков, как запускать систему этапами и как проверить всю цепочку. Устройство отдельных обменов — с 1С, с МоимСкладом, единых остатков, CRM — здесь не повторяется: это карта связей, владельцев и очередности работ.

Какие системы нужны и за что каждая отвечает?

В типичной торговой компании, которая продаёт на сайте и на маркетплейсах, набор систем складывается стихийно: сайт сделал один подрядчик, учёт настроил другой, CRM подключил менеджер, платёжный сервис выбрали по совету. Каждая система работает, а вместе они не складываются, потому что никто не назначил роли.

Ролей в системе интернет-продаж семь, и каждую должна исполнять ровно одна система:

На странице Like Sites про интернет-продажи тот же состав описан как единый путь заказа — трафик, каталог, карточка, корзина, оплата, склад, доставка, CRM, повторная продажа — с оговоркой, что каждый элемент можно запускать поэтапно, а интеграции подбираются как минимальный набор, который уменьшает ручную работу, а не «для галочки» (страница «Интернет-продажи», проверено 31 октября 2026).

Из таблицы следуют два практических вывода. Первый: «одна программа для всего» не существует и не нужна — попытка вести остатки в CRM или клиентов в учёте приводит к тому, что система делает чужую работу плохо. Второй: если две системы претендуют на одну роль — например, остатки правятся и в учёте, и на сайте, — конфликт неизбежен, и решать его нужно назначением, а не интеграцией.

Для масштаба: по исследованию Data Insight и Точка Банка 2025 года, 26,6% селлеров торгуют сразу на двух или трёх маркетплейсах, преимущественно это высокооборотные продавцы; для аналитики селлеры в среднем используют один инструмент — чаще всего Excel, 35%, — но почти половина продавцов с оборотом больше 1 млн ₽ в месяц работает по крайней мере с двумя сервисами (Data Insight, «Исследование селлеров универсальных маркетплейсов 2025»). Рост бизнеса означает рост числа систем, и вопрос «кто за что отвечает» встаёт раньше, чем кажется.

Где находятся главные данные?

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

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

Как читать таблицу: если какая-то строка не заполнена или в колонке «владелец» стоят две системы, именно там живёт следующий сбой. Если по строке «остатки» владелец — сайт, компания неизбежно придёт к перепродажам; если по строке «клиент» владелец — учёт, маркетинг и повторные продажи работать не будут.

Отдельный вопрос — компании с несколькими каналами на один запас. Остатки здесь владение учёта, но между учётом и каналами появляется интеграционный слой, который считает доступный остаток по каналам, применяет буферы и держит очередь обновлений с учётом лимитов площадок. Как устроен такой контур для магазина со своим складом, описано на странице интернет-магазин с собственным складом; в этой статье важно одно: интеграционный слой не владеет остатком, он его раздаёт.

Как проходит заказ от витрины до возврата?

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

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

1. Витрина. Покупатель видит каталог с доступным остатком и ценой из учёта. Инициатор данных — учёт, потребитель — сайт.
2. Оформление. Сайт создаёт заказ с собственным идентификатором, проверяет наличие повторно, ставит мягкий резерв на время оплаты. Инициатор — сайт.
3. Оплата. Платёжный сервис принимает платёж, пробивает чек, присылает событие сайту. Инициатор — платёжный сервис.
4. Передача в учёт. Сайт передаёт заказ в учёт; там создаётся документ заказа с внешним идентификатором, ставится резерв, доступный остаток уменьшается и расходится по каналам. Инициатор — сайт, владелец дальше — учёт.
5. Передача в CRM. Сделка создаётся с источником, составом корзины и контактом клиента; менеджер получает задачу, если заказ требует участия — B2B, нестандартная доставка, вопрос покупателя. Инициатор — сайт или учёт по согласованию, владелец клиента — CRM.
6. Сборка. Склад собирает по документу учёта; статус «собран» проставляется в учёте и уходит на сайт и в CRM.
7. Отправление. Создаётся в службе доставки по данным заказа; трек-номер возвращается в учёт, сайт и CRM; покупатель получает уведомление.
8. Отгрузка. В учёте — документ отгрузки; резерв закрыт, физический остаток уменьшен.
9. Доставка. Статусы приходят от службы доставки; при вручении заказ закрывается.
10. Повторная продажа. CRM фиксирует историю покупки, сегмент, согласие на коммуникацию; сценарии повторного контакта работают по данным CRM, а не по выгрузке из учёта.
11. Отмена и возврат. Отмена до отгрузки снимает резерв в учёте и возвращает деньги через платёжный сервис с чеком возврата. Возврат после доставки — заявка через сайт или CRM, товар едет обратно, в учёте — документ возврата по факту приёмки, деньги — через платёжный сервис. Каждая система получает своё событие.

На этом пути есть три места, где ручная передача встречается чаще всего и стоит дороже всего: между сайтом и учётом (шаг 4 — заказы пересылают руками, остатки правят вручную), между учётом и CRM (шаг 5 — менеджер «ведёт клиента» в мессенджере, а CRM не знает о заказе) и в возврате (шаг 11 — деньги вернули, товар не оприходовали, резерв висит). Именно эти три обмена проектируются первыми.

Для B2B-заказа путь отличается: вместо оплаты на шаге 3 — счёт и резерв с ограничением срока, вместо сборки по факту оплаты — подтверждение менеджером, а CRM становится обязательным звеном с первого шага. Для заказов с площадок путь начинается в кабинете площадки, а шаги 4 и 6–8 идут через учёт по правилам FBS. Каждый вариант рисуется отдельной строкой, и их число — тоже характеристика сложности системы.

Ситуация: заказы приходят с сайта и площадок, остатки ведутся в учёте, клиенты — у менеджеров в мессенджерах, а между системами данные переносятся руками. Что разберём: список систем, каналы продаж, подрядчиков по каждой системе, ручные передачи и главный сбой последнего квартала. Результат: карта систем с таблицей владельцев данных и путём заказа по вашим каналам — документ, с которым можно идти к любому подрядчику. Действие: получить карту систем и этапов автоматизации.

Какие обмены должны работать без ИИ?

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

Обмены, которые обязаны работать без ИИ:

У каждого из этих обменов свои технические особенности, и они разобраны на страницах соответствующих интеграций: обмен с 1С зависит от конфигурации, релиза и доработок и строится по открытому протоколу, через стандартный интерфейс или сервисы конфигурации (интеграция интернет-магазина с 1С); обмен с МоимСкладом — через JSON API с лимитами и вебхуками (интеграция с МоимСкладом); передача в CRM — создание сделки с источником, составом корзины и задачей менеджеру без утечки персональных данных в аналитику (интеграция интернет-магазина с CRM). В архитектуре важно другое: все эти обмены — один слой, и у них должны быть общие свойства.

Общие свойства детерминированных обменов, которые задаются на уровне системы, а не каждого модуля:

• Устойчивые идентификаторы. Товар, заказ, клиент, платёж узнаются по ключу, а не по названию или сумме. Ключ хранится с обеих сторон.
• Идемпотентность. Повторное событие даёт тот же результат: второй заказ не создаётся, второй платёж не проводится.
• Очередь и повторы. Недоступность принимающей стороны не теряет событие: оно ждёт и отправляется позже с нарастающим интервалом.
• «Последнее значение побеждает» для состояний. Остаток и цена передаются как актуальное значение, а не как история изменений.
• Журнал с составом данных. Каждая передача оставляет запись, по которой можно разобрать инцидент.
• Защитное поведение при устаревании. Если данные не обновлялись дольше порога, потребитель это знает и ведёт себя осторожно.

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

Где агент действительно полезен?

ИИ-агент — необязательный слой системы. Он появляется тогда, когда детерминированные обмены работают, данные лежат в системах с назначенными владельцами, и остаётся работа, которую нельзя выразить правилом: интерпретация неструктурированного входа, классификация, подготовка черновиков, сопоставление по смыслу, объяснение.

Признаки процесса, где агент уместен, — в контексте единой системы:

• Вход неструктурирован: письма, сканы, отзывы, строки отчётов с разными названиями одного товара, заявки в свободной форме.
• Данные для решения уже лежат в системах с владельцами: агент читает учёт, CRM, кабинеты площадок — ему есть что читать.
• Результат — черновик или предложение, которое подтверждает человек, либо действие с понятной ценой ошибки и откатом.
• Исключения можно описать и передать человеку с объяснением.

Типичные места агента в архитектуре торговой компании:

Ключевое условие — агент работает поверх системы, а не вместо неё. Агент сверки бесполезен, если заказы с площадок не попадают в учёт; агент заявок — если остатки на сайте обновляются вручную; агент первички — если справочники контрагентов полны дублей. Поэтому в очередности работ агент стоит после обменов, и честный исполнитель предложит сначала навести порядок в данных. Как устроен пилот агента поверх существующих систем — роли доступа «читает / пишет / предлагает / запрещено» по каждой системе, режим черновиков, условия остановки — разобрано в статье как внедрить ИИ-агента в бизнес: пилот, тесты, безопасность; какие процессы вообще подходят и во что обходится агент в первый год — на странице ИИ-агенты для бизнеса и в статье сколько стоит ИИ-агент для бизнеса и когда он окупается.

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

Как предотвращать дубли и циклические обновления?

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

Дубли. Один и тот же товар, клиент или заказ существует в системе дважды, потому что разные системы узнают его по разным признакам. Защита — на уровне архитектуры, а не каждого обмена:

1. Единый внутренний ключ для каждой сущности с таблицей соответствий: внутренний код товара ↔ код в учёте ↔ ID карточки сайта ↔ артикулы площадок; внутренний ID клиента ↔ контакт CRM ↔ контрагент учёта.
2. Сущности создаются только владельцем. Товар — в учёте, клиент — в CRM (контрагент в учёте создаётся для документов по правилу), заказ — сайтом один раз. Остальные системы получают сущность с ключом и не создают свою.
3. Проверка перед созданием — по ключу, а не по похожести. Заказ ищется по идентификатору сайта, клиент — по нормализованному телефону и почте или по ИНН для B2B, товар — по коду учёта.
4. Объединение дублей — процедура с правилом для всех систем: какая запись остаётся, куда переносятся связи, как уведомляются потребители.

Циклы. Система А передаёт значение в Б, Б считает его изменением и передаёт обратно в А, А снова передаёт в Б — и так до тех пор, пока кто-то не заметит нагрузку или расхождение. Классический случай — остаток, который правится и на сайте, и в учёте, при двусторонней синхронизации остатков. Или описание товара, которое обмен из учёта затирает, контент-менеджер восстанавливает, обмен снова затирает.

Защита от циклов:

• Одно направление на каждое поле. Таблица владельцев данных по определению запрещает двусторонние поля: у поля один владелец, и оно передаётся от него.
• Метка источника у события. Каждое изменение несёт признак, откуда оно пришло; обмен не отправляет обратно изменения, которые сам же принял.
• Сравнение перед записью. Если новое значение равно текущему, записи и события не происходит.
• Версии или метки времени. При конфликте побеждает не «последний пришедший», а запись владельца; конфликт пишется в журнал.

Отдельно о третьих участниках. Если к системе подключены два обмена на один объект — например, коннектор платформы сайта и отдельный интеграционный слой оба пишут остатки на площадку, — цикл и дубли гарантированы. Правило: один объект — один обмен в каждом направлении; старые механизмы отключаются до включения новых.

Как организовать журнал и мониторинг?

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

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

Мониторинг — наблюдение за свойствами, а не за «работает ли сервер»:

Уведомления идут конкретному ответственному — не «в чат всем», — с разделением по срочности: остановка приёма заказов или оплаты — немедленно; очередь растёт — в течение часа; расхождение сверки — в ежедневном отчёте. Like Sites формулирует принцип поддержки так: не обещаются невозможные 100% безотказности, а создаётся понятная система контроля и восстановления, где состав проверок, время реакции и границы ответственности фиксируются до начала обслуживания (страница «Интернет-продажи», раздел о поддержке). Это применимо к системе в целом: мониторинг без зафиксированных порогов и адресатов — просто лента логов.

Ещё одно правило: мониторинг проверяет не только технику, но и дисциплину. Если статусы в учёте не проставляются, резервы не снимаются, возвраты не оприходуются — это видно по бизнес-сигналам, и это проблема процесса, а не интеграции. Журнал помогает отделить одно от другого.

Как распределить ответственность подрядчиков?

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

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

Like Sites для своих проектов разделяет это явно: на стороне исполнителя — архитектура, реализация, настройка согласованных интеграций, тестирование технических сценариев и поддержка по договору; на стороне клиента — достоверные данные, юридические тексты, договоры с платёжными и логистическими сервисами, касса и документы, фактическая обработка и отправка заказов (страница «Интернет-продажи», раздел «Кто за что отвечает»). Принцип переносим на любой набор подрядчиков: граница проходит по данным и договорам, а не по тому, «чей модуль».

Три правила, которые снимают большинство споров:

1. Стык — чья-то зона. У каждого обмена есть владелец, и он отвечает за журнал этого обмена. «Мы отправили, а они не приняли» — не ответ; ответ — запись в журнале с составом данных и кодом ошибки.
2. Изменения согласуются до внедрения. Обновление 1С, смена платформы сайта, новая CRM — событие для всех подрядчиков, чьи обмены затронуты, с проверкой на тестовом контуре.
3. Доступы выдаёт компания. Пользователи обмена, ключи API, права — у компании, а не у подрядчика; смена подрядчика не должна означать смену ключей ко всем системам.

Ситуация: у вас три подрядчика, и при каждом сбое они указывают друг на друга, а вы разбираетесь сами. Что разберём: список систем и подрядчиков, какие обмены между ними есть, у кого доступы и кто ведёт журнал. Результат: матрица ответственности по звеньям и стыкам, которую подписывают все участники, и перечень доступов, которые должны быть у компании. Действие: получить карту систем и этапов автоматизации.

Как запускать систему этапами?

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

Порядок этапов и критерий готовности каждого:

На странице Like Sites тот же принцип выражен четырьмя уровнями работы с магазином: запуск, переход — связывание нового магазина с текущими процессами, склад, остатки, CRM, — рост и непрерывность, с замечанием, что маркетплейсы могут работать параллельно, пока бизнес проверяет прямой спрос (страница «Интернет-продажи», раздел «От запуска до постоянной работы»). Этапы 0–2 — это «запуск» и «переход»; 3–5 — «переход» и «непрерывность»; 6 — надстройка.

Две ловушки очерёдности. Первая — начать с агента: он самый заметный и его проще продать, но без этапов 0–2 ему нечего читать. Вторая — начать с CRM до остатков: менеджеры получают красивые сделки по заказам, которые нельзя собрать, потому что товара нет. Правильный порядок скучный: данные, заказы, остатки, клиенты, каналы, наблюдение, автоматизация.

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

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

Как проверить всю цепочку?

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

Чек-лист сквозной приёмки:

1. Товар, созданный в учёте, появляется на сайте с правильными характеристиками, ценой и доступным остатком; переименование не рвёт связь; витринное описание после цикла обмена не изменилось.
2. Заказ, оформленный на сайте и оплаченный, создал ровно один документ в учёте с внешним идентификатором, ровно одну сделку в CRM с источником и составом, одно событие оплаты с чеком; резерв уменьшил доступный остаток на сайте и на площадках в измеренный интервал.
3. Повторная отправка того же заказа не создала второго документа, второй сделки и второго резерва.
4. Статус «собран» в учёте отразился на сайте и в CRM; отправление создано в службе доставки, трек виден покупателю и менеджеру.
5. Отгрузка закрыла резерв и уменьшила физический остаток; физический и доступный остаток в учёте сходятся с данными каналов по контрольной выборке.
6. Отмена до отгрузки вернула остаток во все каналы, деньги — через платёжный сервис с чеком возврата, сделка в CRM получила статус отмены.
7. Возврат после доставки: заявка зафиксирована, товар не появился в продаже до приёмки, после документа возврата появился; деньги возвращены событием, а не ручной правкой.
8. Заказ с площадки по FBS попал в учёт, уменьшил доступный остаток на сайте, прошёл сборку и отгрузку по тем же правилам.
9. Одновременные заказы последней единицы на сайте и площадке не привели к перепродаже благодаря буферу или дали расхождение, зафиксированное в журнале.
10. Остановка учёта на час: сайт продолжил работу на последнем остатке, перешёл в защитный режим по порогу, очередь накопила события, после восстановления всё дошло; журнал содержит полную картину.
11. Остановка API площадки: обновления в очереди, повторы с интервалом, после восстановления отправлено актуальное значение.
12. Новый клиент с телефоном в другом формате не создал дубль в CRM; B2B-клиент с тем же ИНН не создал второго контрагента в учёте.
13. Искусственное расхождение — ручная правка остатка на сайте — обнаружено сверкой и записано в журнал с источником.
14. Уведомление о сбое пришло названному ответственному в согласованный срок.
15. Если есть агент: он прочитал данные из систем, подготовил черновик, не выполнил запрещённого действия, записал всё в журнал; его работа видна в сводном журнале рядом с обменами.

Проверка проводится на тестовом контуре с копиями систем и затем — контрольными заказами на живом контуре с наблюдением. Протокол с датой и результатами хранится у ответственного за систему: при инциденте он показывает, был ли сценарий в проверке. Like Sites в своём процессе ставит этап проверки реальных сценариев — заказ, оплата, отмена, возврат, изменение остатка, уведомления — перед запуском и относит к критериям готовности каждого проекта состав работ, зоны ответственности и критерии готовности (страница «Интернет-продажи», раздел «Как запускаем»). Для системы из нескольких подрядчиков это единственный документ, в котором участвуют все.

Когда единая система не нужна?

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

• Один канал и один склад при небольшом потоке. Сайт с коннектором к учёту и ручная CRM в виде списка клиентов закрывают задачу; система появится, когда появится второй канал или поток, который не помещается в голову.
• Учёт не ведётся по документам. Если остатки «примерно», а продажи вносятся итогом, интеграции будут честно разносить неверные данные. Сначала учёт.
• Нет ответственного за систему на стороне компании. Семь ролей и четыре подрядчика без одного владельца карты систем — это не система, а переписка. Пока такого человека нет, лучше меньше звеньев.
• Проблема в одном стыке. Если болит только обмен сайта с учётом, нужно починить этот обмен, а не перепроектировать всё; узкие руководства по каждому обмену для этого и существуют.
• Экономика канала не проверена. Если собственный магазин ещё не показал прямого спроса, строить вокруг него CRM, мультиканальный остаток и агента рано; какие признаки говорят, что собственный канал оправдан, разобрано в статье свой интернет-магазин или маркетплейс: как сравнить прибыль и выбрать.
• Нужен только агент под один процесс с готовыми данными. Если учёт, CRM и каналы уже связаны и работают, архитектурный проект не нужен — нужен пилот одного процесса.

И обратный признак: единая система нужна, когда компания регулярно теряет заказы или деньги в стыках — перепродажи, дубли клиентов, невозвращённые резервы, неоприходованные возвраты, споры подрядчиков без журнала. Каждый такой случай можно посчитать в рублях по собственным данным за квартал, и эта сумма — аргумент за проект или против него.

Ситуация: вы не уверены, нужна ли вам единая система или достаточно починить один обмен и навести порядок в данных. Что разберём: список систем, каналы, подрядчиков, ручные передачи и главный сбой. Результат: честный ответ — что делать первым, какие звенья нужны сейчас, какие нет, и карта этапов с критериями готовности. Действие: получить карту систем и этапов автоматизации.