Задайте в CRM общее правило рекламных отправок для каждого клиента и подключите к нему все Viber-кампании. Тогда пересечение сегментов не станет поводом отправить человеку несколько предложений подряд. Для этого понадобятся общая история сообщений, приоритеты кампаний и проверка непосредственно перед отправкой. Ниже разберём, что включить в задание на настройку CRM, как обработать отложенные сообщения и какие ситуации проверить перед запуском. Подход подходит бизнесу, где рассылками занимается один сотрудник или несколько отделов.
Почему лимит нужно привязать к клиенту, а не к сегменту?
Начните с проверки ближайших кампаний: найдите клиентов, которые входят сразу в несколько аудиторий. Например, покупатель попадает в группы «интересовались товаром» и «давно не покупали». Каждая группа запускает свой сценарий, хотя адресат у них один. Если CRM проверяет частоту только внутри сценария, обе отправки пройдут.
Сегмент отвечает на вопрос, кому подходит предложение. Общий лимит определяет, когда этому человеку допустимо отправить следующую рекламу. Эти настройки решают разные задачи. Если аудитории ещё приходится собирать вручную, сначала разберите сегментацию клиентов в CRM для малого бизнеса: иначе ошибки отбора будут попадать и в автоматические рассылки.
Для согласованной цепочки сообщений нужны единая база клиентов, общая история отправок и понятная логика триггеров (источник: sender.by). В проекте CRM это означает конкретное требование: ручная рассылка менеджера и автоматическая кампания должны обращаться к одной проверке частоты.
Уточните также, как система распознаёт одного получателя в разных карточках. Если один номер встречается у нескольких контактов, проверка только по карточке пропустит повтор. В задании на интеграцию укажите: перед отправкой CRM должна сопоставлять получателя с общей историей сообщений по этому номеру.
Какие правила записать до настройки CRM?
Сначала опишите решение обычными словами, чтобы менеджер и разработчик одинаково понимали результат. Формулировки «ограничить рассылки» недостаточно: из неё непонятно, какое сообщение пропустить, что отложить и когда снова проверить очередь.
- Определите рекламную паузу. Укажите, от какого события CRM её отсчитывает: например, от принятия сообщения сервисом к отправке. Выбирайте событие, которое интеграция умеет подтверждать.
- Назначьте приоритеты. Предложение по актуальному интересу клиента можно поставить выше общей новости. Для равных приоритетов задайте порядок, например по времени постановки в очередь.
- Укажите срок актуальности кампании. После его окончания CRM должна отменить сообщение, даже если рекламная пауза уже закончилась.
- Отделите уведомления по заказу. Подтверждение записи или готовности заказа обрабатывайте по отдельному правилу, без рекламных вставок.
- Назначьте ответственного за исключения. Зафиксируйте, кто разбирает спорные отправки и меняет правила для будущих кампаний.
Универсальную паузу закладывать не нужно. Для начала сопоставьте текущую частоту с поводами для сообщений: повторная покупка, сезонное предложение, новость ассортимента. Затем выберите правило, которое сотрудники смогут соблюдать во всех рекламных сценариях.
Отдельный разбор пересечения аудиторий есть в статье на isms.by. В задании для CRM зафиксируйте собственное решение на простом примере: клиент подходит для нескольких кампаний, система выбирает предложение с наивысшим приоритетом, а остальные отменяет или переносит до следующего допустимого времени.
Как связать CRM и сервис рассылок без дублей?
Проверьте, где именно система принимает решение об отправке. Наличие API, то есть интерфейса для обмена данными, само по себе не подтверждает поддержку общего лимита. Запросите у поставщика перечень доступных проверок и определите, какую часть логики будет выполнять CRM или отдельная интеграция.
Для настройки понадобятся идентификатор кампании, получатель, тип сообщения, приоритет и срок актуальности. В истории фиксируйте время отправки и её статус. В очереди храните ближайшее допустимое время и причину ожидания, чтобы менеджеру не приходилось угадывать, почему клиент пока не получил сообщение.
- Перед отправкой проверьте историю клиента и его текущую очередь. При необходимости заново сравните приоритеты сообщений.
- Закрепите выбранную отправку за получателем. Параллельный сценарий должен увидеть, что решение уже принято, и повторно проверить лимит.
- Передайте запрос сервису рассылок с идентификатором, по которому можно связать ответ с конкретной попыткой.
- Запишите результат. Если статус неизвестен, сначала уточните его доступным способом и только потом решайте вопрос повтора.
- Перед запуском отложенного сообщения снова проверьте паузу и срок предложения. За время ожидания история клиента могла измениться.
Особенно внимательно проверьте обрыв связи после запроса. CRM не получила ответ, но сервис уже мог принять сообщение. Слепой повтор в такой ситуации создаёт риск дубля. Попросите разработчика описать порядок проверки статуса и защиту от повторной обработки одного запроса с учётом возможностей API.
При проектировании CRM полезно заранее разделить ответственность: CRM выбирает допустимое сообщение, сервис выполняет отправку, интеграция возвращает статус. Если поставщик уже поддерживает общую проверку частоты, это тоже нужно отразить в схеме. Иначе две независимые настройки начнут по-разному переносить одну кампанию.
Как проверить лимит и видеть причины отмены?
Подготовьте тестовые карточки и заранее запишите ожидаемый результат для каждой. Проверяйте всю цепочку до журнала событий. Успешный запуск кампании ещё не показывает, сколько сообщений система назначила одному адресату.
- Клиент входит в пересекающиеся сегменты: CRM выбирает сообщение по приоритету и объясняет судьбу остальных.
- Клиент недавно получил рекламу: новая кампания ждёт до допустимого времени либо отменяется по правилу.
- Предложение истекло в очереди: CRM исключает сообщение и фиксирует причину.
- Сценарии стартуют одновременно или связь с сервисом обрывается: система проверяет очередь и статус запроса перед следующей попыткой.
- По текущему заказу приходит новое событие: уведомление проходит по отдельному правилу и не превращается в рекламную отправку.
В журнале разделите решения CRM и статусы сервиса. «Отменено из-за срока акции», «отложено по лимиту» и «ошибка отправки» требуют разных действий. По каждой записи сотрудник должен видеть кампанию, время решения и причину, а для переноса ещё и дату следующей проверки.
Для очереди задайте ответственного и условие, при котором CRM создаёт задачу на разбор. Например, сообщение осталось без определённого статуса после проверки интеграции. Похожую организацию работы можно использовать при настройке контроля зависших сделок в CRM: сотруднику нужны причина задержки, срок и конкретное действие.
Настройка готова к запуску, когда тесты подтверждают выбор сообщения, обработку параллельных запросов и отмену просроченного предложения. Сохраните эти сценарии: после изменения интеграции их можно пройти повторно.
Типичные ошибки при настройке лимита Viber-сообщений
- Проверять только автоматические кампании. Подключите к общему правилу ручные отправки сотрудников, иначе история останется неполной.
- Считать отбор аудитории окончательным решением. Повторяйте проверку перед отправкой, когда известны актуальная история и очередь.
- Переносить каждое лишнее сообщение. Проверяйте срок предложения и отменяйте кампанию, если после паузы она потеряет смысл.
- Принимать отсутствие ответа API за отказ в отправке. Уточняйте результат запроса перед повторной попыткой.
- Смешивать рекламную паузу и уведомления по заказу. Разделите типы сообщений и явно задайте правила для каждого.
Начните с действия на две минуты: откройте ближайшую Viber-кампанию в CRM и запишите, с какими другими кампаниями у неё пересекаются получатели.
