Сегментация клиентов: критерии, правила в CRM и обновление сегментов

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

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

Для какого решения нужна сегментация клиентов

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

Перед созданием группы ответьте на четыре вопроса:

1. Какое решение принимаем по этой группе?
2. Какие поля подтверждают включение клиента?
3. Кто выполняет следующее действие?
4. Когда и из-за какого события группа обновляется?

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

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

Какие признаки выбрать для B2B и B2C

Признаки удобно разделить на четыре группы.

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

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

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

Когда применять RFM

RFM описывает три измерения покупательской истории:

• давность (R) — сколько календарных дней прошло после последней завершённой покупки;
• частота (F) — сколько уникальных завершённых покупок совершено за выбранный период;
• сумма (M) — стоимость этих покупок в одной валюте за тот же период.

Метод применим, только если CRM содержит сопоставимые даты, идентификаторы покупок и суммы. Период, статусы сделок, валюта и дата среза должны быть одинаковыми для всех записей. Если дата отсутствует, давность остаётся неизвестной: клиенту нельзя автоматически присвоить самый низкий RFM-балл.

RFM — лишь один способ классификации. Он показывает историю покупок, но не объясняет причину поведения и не доказывает будущую потребность.

Как подготовить базу и обработать пропуски

Сначала сделайте копию набора для расчёта и зафиксируйте дату среза. Затем проверьте четыре области.

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

Периоды. Не сравнивайте годовую сумму одного клиента с квартальной суммой другого. Запишите начало и конец периода, часовой пояс и правило включения граничных дат.

Единицы. Суммы приводят к одной валюте по принятому компанией правилу. Количество сотрудников, заказов и дней хранят в отдельных полях. Не смешивайте сумму сделки с числом покупок.

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

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

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

Как задать правила сегментов в CRM

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

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

Правила лучше записывать сверху вниз:

1. Сначала отделить записи без обязательных данных.
2. Затем применить взаимоисключающие бизнес-правила в установленном порядке.
3. После этого вычислить дополнительные метки, пересечения которых разрешены.
4. Для каждого результата назначить действие и ответственного.

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

Официальная справка Битрикс24, обновлённая 22 июля 2026 года, описывает поле «Тип» в карточках контактов, компаний и сделок. Документация также показывает фильтрацию компаний по типу, групповые действия и применение условия по типу сделки в автоматизации. Это подтверждает документированную последовательность для Битрикс24, но не доказывает её доступность в конкретном портале: состав полей, тариф, права и текущий интерфейс нужно проверить перед настройкой. Статья не утверждает, что Switch On AI запускала этот сценарий в системе клиента.

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

Учебная сегментация небольшой клиентской базы

Ниже — синтетический пример, а не клиентский файл, тест CRM или результат внедрения Switch On AI. Все компании, контакты и сделки вымышлены.

Дата первого среза — 30 сентября 2026 года. Период для F и M — с 1 октября 2025 года по 30 сентября 2026 года включительно. Суммы указаны в рублях. Учитываются только уникальные завершённые покупки.

Исходные условные записи

Карточки C-101 и C-102 признаны дублями по условию примера: у них один подтверждённый внешний идентификатор компании. После объединения сделки D-1 и D-2 учитываются по одному разу. Частота равна 2, сумма — 200 000 рублей, последняя дата — максимум из известных дат, то есть 25 сентября. Контакты K-11 и K-12 остаются двумя связанными людьми.

Для расчёта используем формулы:

• R = дата среза минус дата последней покупки, в календарных днях;
• F = число уникальных завершённых покупок за период;
• M = сумма этих покупок за период;
• если дата неизвестна, R = «Неизвестно».

После объединения получаем:

В учебном примере действуют взаимоисключающие правила с таким приоритетом:

1. «Данные неизвестны» — нет даты последней покупки.
2. «Активные, высокая сумма» — R не более 90 дней и M не менее 200 000 рублей.
3. «Активные, стандартные» — R не более 90 дней и M менее 200 000 рублей.
4. «Требуют внимания» — R от 91 до 180 дней.
5. «Неактивные» — R больше 180 дней.

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

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

Что меняется после новой сделки

Предположим, 2 октября 2026 года у компании «Луч» появилась завершённая сделка D-6 на 60 000 рублей. Для нового среза 3 октября и скользящего периода в 12 месяцев:

• R становится равным 1 дню;
• F становится равной 2;
• M становится равной 100 000 рублей;
• компания переходит из «Неактивных» в «Активные, стандартные».

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

Как проверить пользу и автоматизировать обновление

Сначала проверьте воспроизводимость. Возьмите одну зафиксированную версию данных, дату среза и правила. Два сотрудника или два запуска расчёта должны получить одинаковое число клиентов в каждой группе и одинаковый список исключений.

Контрольный лист включает пять проверок:

1. Сумма количества клиентов во взаимоисключающих группах равна числу уникальных компаний после удаления дублей.
2. Одна уникальная сделка не увеличивает F и M дважды.
3. Пропущенная дата остаётся неизвестной и не попадает в реактивацию.
4. Для каждого сегмента назначены действие, ответственный и срок пересмотра.
5. После контрольного события меняются только те группы, на которые это событие влияет.

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

Switch On AI может разработать ИИ-помощника, бота или обычную интеграцию для конкретной операции. Здесь, вероятнее всего, нужна интеграция: получить разрешённые данные, применить явные правила, записать сегмент и передать исключения человеку. ИИ-помощник нужен лишь там, где требуется разобрать неструктурированное обращение или подготовить контекст; он не должен самостоятельно придумывать критерии клиента.

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

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