Сбор ответов · 29 сентября 2026 г.

Триггерные опросы: как настроить автоматическую отправку по событию

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

Что такое триггерный опрос и чем он отличается от рассылки

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

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

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

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

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

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

Как устроена схема технически: где здесь опросный сервис

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

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

Задержка и момент отправки: сразу или с паузой

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

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

Как не разослать один и тот же опрос дважды

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

Ограничения: где триггер не подходит

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

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

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

Роль сервиса форм в этой схеме: что есть, а чего нет

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

Типичные ошибки

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

С чего начать

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

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

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