CRM интернет-магазина: заказы, обращения, повторные продажи

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

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

Что решает CRM, а что остаётся складской системе?

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

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

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

Как собрать единый профиль клиента?

Единый профиль — одна запись о покупателе, к которой привязаны все его заказы, обращения и согласия, независимо от канала. Без него CRM превращается в список дублей: один человек заказал с сайта, написал в мессенджер, повторно отправил форму — и стал тремя контактами с тремя сделками.

Правила, которые делают профиль единым:

1. Ключ идентификации. Телефон и электронная почта после нормализации: единый формат номера, нижний регистр почты, удалённые пробелы. Для организаций — ИНН. Правило определения дубля — решение компании, а не настройка интеграции: совпадение телефона, почты, номера заказа или их сочетания.
2. Поиск перед созданием. Каждое событие с сайта сначала ищет контакт по ключу; найден — обращение привязывается к нему как новая сделка или касание; не найден — создаётся контакт. «Похожее имя» ключом не является.
3. Один контакт — много сделок. Повторный заказ не создаёт новый контакт, он создаёт новую сделку у существующего. Повторная отправка той же формы не создаёт новую сделку вовсе — она связывается с существующей.
4. Заказы с площадок. Покупатель маркетплейса обычно не идентифицируется по контакту: площадка не передаёт телефон и почту. Такие заказы в CRM не попадают как сделки с клиентом — они живут в учёте, а в CRM при необходимости попадают обезличенно как события канала. Объединить профиль покупателя площадки с профилем покупателя сайта можно только если он сам оставил контакт на сайте.
5. Слияние дублей — процедура. Если дубли уже накопились, объединение делается по правилу: какая запись остаётся, куда переносятся сделки и согласия, что происходит с конфликтующими полями. Автоматическое слияние «по похожести» создаёт больше проблем, чем решает.

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

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

Как передавать события заказа?

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

Карта клиентских событий — что происходит на сайте, что создаётся в CRM и кто инициатор:

Три правила передачи:

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

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

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

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

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

Обращение без ответственного не обрабатывается — оно висит в общем списке, пока кто-то не возьмёт его сам. Правило назначения ответственного — решение компании, которое фиксируется до настройки и реализуется автоматически при создании сделки.

Варианты правил и где они уместны:

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

Зона ответственности здесь проходит так: интегратор настраивает назначение, задачу и уведомление по согласованной логике; компания принимает решение о правиле, держит актуальным состав сотрудников и их права в CRM и отвечает за дисциплину ведения этапов (страница «Интеграция магазина с CRM»). Если менеджеры не двигают сделки по этапам, никакая интеграция не покажет реальное состояние продаж.

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

Какие события нужны для повторных продаж?

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

События и данные, без которых повторные продажи не работают:

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

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

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

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

Как работать с брошенной корзиной?

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

Что считать брошенной корзиной. Корзина с товарами, не превратившаяся в заказ за согласованное время — обычно от часа до суток, — у покупателя, который идентифицирован: авторизован или оставил контакт на шаге оформления. Корзина анонимного посетителя — не повод для обращения, потому что обращаться некуда и не на что опираться.

Правила:

1. Обращение по брошенной корзине — рекламное сообщение, а не транзакционное. Оно допустимо только при наличии согласия на получение рекламы по этому каналу. Факт добавления в корзину согласием не является.
2. Одно напоминание, не серия. Если покупатель не вернулся после одного сообщения, второе и третье — путь к отписке и жалобе.
3. Без искусственного давления. Сообщение «товар заканчивается», если это не так, и скидка «только сегодня», которая повторяется еженедельно, разрушают доверие и подрывают цену.
4. Проверка наличия перед отправкой. Напоминать о товаре, которого уже нет, бессмысленно.
5. Не пересекаться с другими сценариями. Если покупателю в этот день уходит напоминание о повторной потребности, брошенная корзина ждёт или отменяется.
6. Корзина в CRM — событие, а не сделка. В профиль пишется факт и состав; сделка создаётся только при оформлении заказа. Иначе воронка заполняется «сделками», которые никогда не были обращениями, и отчётность искажается.

Место брошенной корзины в карте событий — отдельная строка «корзина без заказа» с триггером «идентифицированный покупатель, есть согласие, прошло N часов, товар в наличии, нет другого обращения сегодня» и действием «одно сообщение со ссылкой на корзину». Результат измеряется долей корзин, превратившихся в заказы после напоминания, по сравнению с корзинами, по которым напоминание не отправлялось, — с одинаковым периодом и сегментом, иначе сравнение ничего не показывает.

Как учитывать согласия и отписки?

Любое обращение к покупателю вне обслуживания его заказа — реклама, и для неё нужно предварительное согласие. Это не формальность CRM-настройки, а требование закона, и ответственность лежит на том, кто рассылает.

Закон о рекламе прямо устанавливает: распространение рекламы по сетям электросвязи — телефон, электронная почта, мессенджеры — допускается только при предварительном согласии абонента или адресата; реклама признаётся распространённой без согласия, если рекламораспространитель не докажет, что согласие было получено; по требованию адресата рассылка прекращается немедленно; автоматический обзвон и автоматическая рассылка без участия человека не допускаются (Федеральный закон № 38-ФЗ «О рекламе», статья 18, актуальная редакция). Отдельно действует закон о персональных данных с условиями обработки и обязанностями оператора (Федеральный закон № 152-ФЗ, актуальная редакция). Что именно и в какой формулировке требуется в вашем случае — определяет юрист; задача архитектуры CRM — чтобы было что показать.

Правила, которые закладываются в систему:

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

Это проверяется при сдаче: сценарий не срабатывает без согласия, отказ фиксируется и останавливает сценарии, у каждого контакта есть отметка с датой (страница «CRM и повторные продажи»). Магазин как владелец базы отвечает за политику обработки данных и содержание сообщений; интегратор отвечает за то, что система эти правила соблюдает технически.

Как измерять результат без двойной атрибуции?

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

Правила измерения:

1. Признак повтора — в заказе. При передаче заказа в CRM он получает признак «первичный» или «повторный» по наличию закрытой сделки у контакта; повторные заказы отличимы от первичных в отчётности — это пункт приёмки.
2. Источник повторного заказа — отдельно от источника первого контакта. У контакта хранится источник первого контакта; у каждого заказа — свой источник: сценарий повтора, прямой заход, реклама. Так заказ не приписывается одновременно рекламе, которая привела клиента год назад, и напоминанию, которое его вернуло.
3. Одно правило атрибуции на компанию. Первый контакт, последний контакт или сценарий — выбирается одно и применяется ко всем отчётам; смена правила — пересчёт за весь период.
4. Контрольная группа там, где это возможно. Часть покупателей сегмента не получает напоминание; разница в доле повторов между группами — эффект сценария. Без контрольной группы доля повторов после запуска сравнивается с долей до запуска за сопоставимый период, с пониманием, что сезонность и ассортимент тоже влияют.
5. Персональные данные в аналитику не передаются. Отчёты строятся по обезличенным событиям и идентификаторам, а не по именам и телефонам.

Шаблон отчёта по повторным покупкам за период:

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

Как проверить интеграцию?

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

Чек-лист приёмки:

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

Пункты 1–9 — из перечня проверок при сдаче интеграции с CRM, 10–12 — из перечня для повторных продаж на страницах Like Sites (интеграция с CRM, повторные продажи). Протокол проверки с датой хранится у ответственного за систему: при первом инциденте он показывает, был ли сценарий в проверке.

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

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

Когда CRM-интеграция преждевременна?

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

• Нет отдела продаж и обращений, требующих участия человека. Если все заказы — розница с онлайн-оплатой и автоматической отгрузкой, а вопросов покупателей единицы, процесс продажи как таковой отсутствует; CRM здесь — хранилище истории для повторных продаж, и начинать нужно с передачи заказов с составом, а не с воронки.
• Воронка в CRM не настроена или описывает не процесс, а состояния заказа. Автоматическое создание сделок в такую воронку будет мешать менеджерам; сначала процесс продаж, потом интеграция — и это работа компании.
• Нет решения о правиле распределения и правиле дублей. Это решения компании, без них интеграция не настраивается.
• Остатки ведутся вручную. Менеджер в CRM будет обещать товар, которого нет; учётная интеграция идёт первой.
• Товар покупают один раз на годы. Сценарии повторной потребности для такого ассортимента бессмысленны; CRM нужна только для процесса продаж, если он есть.
• Согласия собирались неформально или не собирались. Сначала порядок в согласиях и политике данных, только затем сценарии; импортированная база без согласий — не адресаты.
• Некому готовить тексты и принимать решения по условиям. Формулировки, скидки и частота — решения компании; интегратор настраивает то, что определено, а не придумывает за компанию.
• Объём мал. Десятки заказов в месяц менеджер помнит; CRM добавит дисциплины, но интеграция с очередями и журналом не окупится.

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

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

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