CRM-маркетинг

CRM расшифровывается как Customer Relationship Management — управление отношениями с клиентами. Это понятие шире программы: в стратегической трактовке Пейна и Фроу оно связывает процессы, людей и технологии ^[6]. CRM-система помогает хранить и использовать данные. Рабочее определение CRM-маркетинга выше объединяет эту стратегическую основу с выбором аудитории, цели и последовательности действий в документации Microsoft и Salesforce ^{[1, 3]}.

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

Кратко

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

Происхождение и история термина

Пейн и Фроу связывают появление обозначения CRM среди поставщиков информационных технологий и практиков с серединой 1990-х годов. Первоначальная связь с технологическими решениями помогает понять, почему CRM нередко отождествляют с программой ^{[6, с. 167–168]}.

В статье A Strategic Framework for Customer Relationship Management 2005 года Пейн и Фроу сопоставили узкую технологическую и широкую стратегическую трактовки CRM. Их схема включала разработку стратегии, создание ценности, согласование каналов, управление информацией и оценку результатов ^[6]. Это историческая концептуальная работа, а не инструкция по современному интерфейсу.

Современные продукты показывают, как общая идея воплощается в последовательностях действий. Microsoft Customer Insights — Journeys различает запуск по событию и по сегменту ^[1]. HubSpot описывает включение записей в автоматизированный процесс по условиям фильтра ^[2]. Документы подтверждают устройство конкретных функций; сами по себе они не доказывают увеличение продаж.

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

Суть и механизм

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

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

Сегментация — разделение аудитории на группы по выбранным признакам. У Пейна и Фроу выбор подходящего деления существующих и потенциальных клиентов входит в разработку клиентской стратегии ^{[6, с. 170]}. Для учебного сервиса это могут быть впервые зарегистрированные участники, завершившие обучение и те, у кого ещё открыт вопрос в поддержку. Признак должен соответствовать задаче: возраст сам по себе не сообщает, прочитал ли человек инструкцию.

Событие запуска, или триггер, — зарегистрированный факт, после которого рассматривают начало сценария: например, подтверждение записи. Сегмент — состояние группы, событие — изменение или действие. Microsoft документирует именно различие между реакцией на действие клиента и выбором клиентов с общими характеристиками ^[1].

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

Содержание следует из состояния, а не наоборот. Когда клиент уже оплатил услугу, замена имени в обращении не делает предложение «оплатите первый заказ» подходящим. Персонализация полезна для объяснения контекста, но одна подстановка имени ещё не показывает, что история отношений учтена.

Виды и классификации

По основанию запуска Microsoft выделяет событийные и сегментные сценарии ^[1]. По задаче можно использовать следующую редакционную классификацию; она не приписывается всем CRM-платформам.

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

Удержание здесь означает сохранение отношений с выбранными клиентами в течение определённого срока. Продолжение отношений выделено и в учебной схеме Salesforce ^[3]. Но событие, подтверждающее это, нужно назвать: действующая подписка, повторная покупка или другое обоснованное условие. Полученное письмо и открытая ссылка не равны сохранённым отношениям.

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

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

Как применяется на практике

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

Система или учебный материал	Что подтверждено документацией	Что проверить перед применением
Microsoft Customer Insights — Journeys	сценарии по событию и сегменту ^[1]	какие события включают контакт и что происходит при завершении или остановке
HubSpot Workflows	включение записей по фильтрам; набор условий зависит от типа процесса ^[2]	доступны ли нужные фильтры для выбранного типа процесса и подписки
Salesforce Trailhead	урок связывает цель, данные, каналы, этапы отношений и испытание сценария ^[3]	как измерить цель и проверить прохождение сценария в своей задаче

Учебный пример. Компания проводит занятия по записи. После подтверждения клиенту нужна инструкция с адресом и подготовкой. Если занятие перенесено, информация должна соответствовать новому времени. Если запись отменена, напоминание о старом занятии не требуется.

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

Следующая задача — определить допустимость контакта и содержание сообщения. В российском проекте наличие технического канала не заменяет проверки правил обработки данных и рекламы ^{[4, 5]}. Юридическая квалификация зависит от реального сообщения и обстоятельств; учебный пример не разрешает его отправку.

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

Как измерить результат

Ниже предложена редакционная модель отчёта. Она разделяет техническое выполнение, действия клиента, продолжение отношений и экономический итог. Число отправок отвечает только на первый из этих вопросов.

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

Delivery = \frac{D}{N}\times100\%, \qquad Conversion_{audience} = \frac{K}{N}\times100\%.

Если отдельно изучаются действия среди получивших сообщение, числитель должен включать только эту группу:

Conversion_{delivered} = \frac{K_D}{D}\times100\%,

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

Учебный расчёт с двумя знаменателями

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

Получаются три разных вывода: доставка — 180 / 200 × 100% = 90%; действие от всей аудитории — 36 / 200 × 100% = 18%; действие среди получивших — 36 / 180 × 100% = 20%. Последний процент выше, потому что его знаменатель меньше.

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

Как отдельно посчитать удержание

Для учебной подписки зафиксируем исходную группу N_0 и посмотрим, сколько её участников R сохраняют действующую подписку на установленную дату:

Retention = \frac{R}{N_0}\times100\%.

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

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

Что требуется для вывода о дополнительном эффекте

В методике полностью рандомизированного эксперимента NIST условия случайно назначаются единицам наблюдения ^[7]. В маркетинговой постановке это означает, например, заранее распределить подходящих участников между двумя условиями, а не после кампании сравнивать открывших письмо с остальными.

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

Наблюдаемые доли равны восемнадцати и двенадцати процентам. Разность — шесть процентных пунктов, или 36 / 200 − 24 / 200 = 0,06. При относительном сравнении с контрольными двенадцатью процентами получается пятьдесят процентов прироста. Это другой способ выразить ту же разность, а не дополнительные пятьдесят процентных пунктов.

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

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

Как проверить и принять сценарий

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

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

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

Изменение правила тоже не должно скрывать судьбу текущих участников. Microsoft различает завершение приёма новых контактов и полную остановку сценария; даже остановка не всегда предотвращает доставку сообщения, уже переданного промежуточному провайдеру ^[1]. Поэтому название кнопки нельзя принимать за доказательство немедленного исчезновения всех последующих контактов.

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

Ошибки, ограничения и спорные вопросы

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

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

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

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

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

Правовой аспект в России

По статье 5, частям 2–6 Федерального закона от 27.07.2006 №152-ФЗ «О персональных данных» в редакции от 26.07.2026 цели обработки должны быть определены заранее; состав данных должен им соответствовать, а данные — быть точными и при необходимости актуальными. Часть 3 запрещает объединение баз с несовместимыми целями обработки ^[4].

Статья 15, часть 1 того же закона отдельно требует предварительного согласия для обработки данных при продвижении товаров, работ и услуг через прямые контакты с потенциальным потребителем средствами связи. Доказать получение согласия должен оператор; по части 2 он обязан по требованию человека немедленно прекратить такую обработку ^[4]. Общего наличия данных в CRM для этого недостаточно.

Часть 1 статьи 18 Федерального закона от 13.03.2006 №38-ФЗ «О рекламе» в редакции от 04.08.2026 требует предварительного согласия адресата на рекламу по сетям электросвязи; доказательство его получения возложено на рекламораспространителя. По требованию адресата распространение рекламы в его адрес должно немедленно прекратиться ^[5].

Часть 2 статьи 18 отдельно запрещает рекламу с использованием средств выбора или набора абонентского номера без участия человека ^[5]. Поэтому факт согласия не подтверждает допустимость любого способа автоматизации. Конкретное сообщение, канал, основание обработки и способ отправки требуют правовой оценки. Здесь приведены границы норм, а не юридическое заключение по реальному сценарию.

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