Коллеги из ХК «Адмирал» поделились рабочим сюжетом: клуб нашёл болельщиков, которые раньше ходили на матчи, а потом перестали. Не всех сразу и не «примерно», а конкретный список людей, к которым есть с чем прийти — персональным предложением, а не общей рассылкой на всю базу.
Интересна не сама находка, а то, сколько шагов до неё. Задача формулируется в чате CRM обычными словами: «Выбери покупателей билетов на три последних домашних матча. Исключи абонементщиков». Или так: «Найди тех, кто открыл письмо о матче, но не купил билет».
Почему такой вопрос обычно стоит дорого
Данные для ответа у клуба есть всегда: билеты, проходы через турникеты, абонементы, открытия и клики в рассылках, заказы в магазине. Проблема в том, что вопрос маркетолога и структура базы говорят на разных языках.
«Кто перестал ходить» — это не поле в таблице. Это пересечение нескольких условий: были покупки в прошлом сезоне, нет покупок в текущем, нет действующего абонемента, есть согласие на коммуникацию. Чтобы получить такой список, обычно нужен либо аналитик с доступом к базе, либо терпение и полчаса в конструкторе фильтров — и то и другое превращает проверку гипотезы в задачу на несколько дней. В результате гипотезы просто не проверяются: клуб шлёт одно письмо на всю базу и надеется на отклик.
Как это выглядит сейчас
Ассистент живёт внутри CRM, рядом с базой болельщиков, и решает три разные задачи.
Собирает сегмент. «Пришли болельщиков с детьми», «собери сегмент женщин с билетами», «покупатели трёх последних домашних матчей без абонемента». В ответ приходит карточка сегмента: какие фильтры подобраны и сколько человек под них попало.
Считает по базе. «Сколько купили абонемент?», «сколько человек пришло на последний матч» — это уже не список, а число, и оно считается запросом к данным клуба, а не берётся из головы модели.
Отвечает по базе знаний. Вопросы про саму систему — как работает цепочка, чем отличается сегмент от пресета — закрываются документацией клуба, а не общими словами про CRM.
Что происходит под капотом
Здесь начинается инженерная часть, из-за которой такому ответу можно доверять.
Фильтры берутся из закрытого каталога. Модель не придумывает условия — она выбирает из списка того, что CRM действительно умеет: наличие мобильного приложения, согласие на рассылку, отписка, действующий абонемент текущего сезона, уровень программы лояльности, город, семейное положение, источник регистрации, категория покупателя, а также условия по заказам, баллам, проходам, билетам, открытиям и кликам в письмах — с операторами «больше», «меньше», «равно».
Неподдерживаемое честно называется неподдерживаемым. Если в запросе было условие, которого в CRM нет, ассистент не делает вид, что учёл его: он говорит, что именно отбросил, и предлагает переформулировать. Это важнее, чем кажется: молча проигнорированный фильтр даёт правдоподобный, но неверный сегмент, и ошибка всплывает уже после рассылки.
Сегмент не сохраняется сам. Карточка в чате — это черновик: его можно уточнить следующей репликой («убери тех, кто отписался»), и только по кнопке «Сохранить» он становится пресетом в CRM, который дальше используется в рассылке или цепочке.
Запрос к данным ограничен на уровне движка. Когда речь про «посчитать», модель формирует SQL, но до базы он доходит через валидатор: разрешён только одиночный SELECT, запрещены изменения данных и опасные функции, а само выполнение идёт в транзакции только на чтение. Если запрос не прошёл проверку или база вернула ошибку, ассистент получает её текстом и делает одну попытку исправиться — дальше честно сообщает о неудаче.
Что это меняет в работе
Главное изменение не в скорости одного запроса, а в стоимости гипотезы. Когда сегмент собирается за минуту прямо в чате, маркетолог проверяет пять идей вместо одной: отдельно тех, кто ходил с детьми, отдельно тех, кто был на плей-офф и пропал в регулярке, отдельно тех, кто открывает письма, но не доходит до покупки.
Дальше работает обычная механика платформы: сегмент уходит в рассылку или в триггерную цепочку, а результат — открытия, переходы, покупки — возвращается в ту же базу и становится материалом для следующего вопроса.
Границы, о которых стоит сказать прямо
Ассистент не принимает решений за клуб. Он не выбирает, какое предложение отправить вернувшемуся болельщику, не оценивает экономику акции и не запускает рассылку сам — сегмент остаётся черновиком, пока человек его не сохранил, а рассылка отправляется руками маркетолога.
Он не пишет в базу: любые изменения данных остаются за интерфейсом CRM и правами доступа. И он не заменяет разметку данных — если клуб не фиксирует проходы через турникеты или не ведёт согласия на коммуникацию, никакой формулировкой этого не компенсировать. Ассистент хорош ровно настолько, насколько полон контур, который клуб уже собрал.
Что дальше
Сегментация обычными словами — первый шаг к тому, чтобы CRM отвечала на вопросы, а не только хранила данные. Следующий — тот же разговорный интерфейс поверх остальных модулей экосистемы: достижений, абонементных кампаний, спортивной школы. Вопрос «кто перестал ходить» ничем не отличается от вопроса «кто из детей пропустил больше трети тренировок в этом месяце» — данные разные, механика одна.
