Нужна ли CRM интернет-магазину: CRM против админки сайта

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

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

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

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

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

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

Развилка проходит не по обороту, а по числу стыков между системами и людьми. Ниже — признаки, по которым видно, что админка уже не тянет.

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

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

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

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

Первая линия магазина — это три вопроса, повторяющиеся бесконечно: «где мой заказ», «есть ли этот размер или цвет», «как оформить возврат». Они однотипные, приходят круглосуточно и во всех каналах сразу, и именно они съедают время менеджеров, которые могли бы заниматься сложными и дорогими заявками. Это ровно та зона, где AI-чат-бот с поддержкой 24/7 окупается быстрее всего.

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

Как это выглядит в проде, можно посмотреть на нашем кейсе AI-консьержа для отеля. Оговоримся честно: это HoReCa, а не e-commerce, — но механика ровно та же. Один AI с единой логикой работает в 7 боевых каналах связи и отвечает гостям 24/7, база знаний собрана из документов отеля, а реальные наличие и цены берутся из внешней системы бронирования TravelLine, а не из памяти модели. Замените TravelLine на вашу учётную систему, а «свободен ли номер» на «есть ли размер» — архитектура не изменится.

И то, что остаётся за человеком. Нестандартный вопрос, конфликтная ситуация, спорный возврат, крупная оптовая заявка уходят менеджеру вместе с полной историей диалога, чтобы клиенту не пришлось пересказывать всё заново. AI снимает поток однотипного, а не заменяет вашу поддержку.

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

Первое — фискализация по 54-ФЗ. Расчёт с покупателем сопровождается фискальным чеком, который пробивается через онлайн-кассу и уходит оператору фискальных данных. Практический вывод для проекта простой: CRM не является кассой и не пробивает чеки — она должна корректно передавать данные в контур, где чек формируется, и не создавать вторую версию правды о платеже.

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

Третье — персональные данные. На каждой форме сайта, где вы собираете имя, телефон или почту, нужно согласие на обработку персональных данных, а в самой базе — понятные роли и разграничение доступа. Мы подробно разбирали чек-лист по 152-ФЗ в отдельной статье про CRM и клиентскую базу: там про согласия, хранение данных на серверах в РФ и права доступа. Здесь важен один принцип — эти требования закладываются в архитектуру на старте, а не прикручиваются после запуска.

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

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

Технически это собирается по-разному в зависимости от вашей стартовой точки. Если фундамент — Битрикс24, мы настраиваем воронки, роли и бизнес-процессы под ваши сценарии и подключаем сайт, мессенджеры и учётную систему через интеграции. Если вы хотите держать данные на своём размещении, подойдёт вариант с self-hosted CRM: внедрение и миграция идут «один в один», со сверкой контактов, сделок и истории с исходной системой. Нетиповые связки — обмен с маркетплейсами, личный кабинет оптовика, собственный портал — закрываются заказной разработкой, и мы прямо говорим, когда дешевле взять готовое решение вместо кастома.

Когда данные сведены, поверх появляется аналитика по клиенту, а не по каналу. BI-аналитика на естественном языке позволяет спросить обычными словами, сколько повторных покупок дал канал за квартал или в каких категориях чаще всего оформляют возврат, — и получить график, не выгружая ничего в Excel и не дожидаясь аналитика.

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

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

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