Триггерные рассылки с сайта строят вокруг событий, повторной отправки и защиты от дублей

Триггерная рассылка отправляет письмо после события или выполнения условия. Покупатель оплатил, заказ сменил статус, подписчик подтвердил адрес. Для каждого случая заранее задают получателя и содержание.

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

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

Маркетинг и разработка согласуют карту событий до шаблонов писем. Событие приходит из системы, где хранится результат действия. Если это своя CRM, сначала определяют, кто владеет статусом заказа.

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

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

Для такого разрыва используют outbox: изменение и задание на письмо записывают одной операцией. Отдельный обработчик забирает сохранённые задания. Этот приём описан в руководстве AWS, проверенном 7 октября 2026.

Результат покупки и результат письма учитывают отдельно. Уже выданный доступ не отвечает на вопрос, получил ли человек ссылку входа. Это разные записи о разных действиях.

Повтор проверяет историю конкретного письма. Если отправитель его не принял, задание остаётся для новой попытки. Если принял, обычный повтор события подавляют.

Ремонт сломанной интеграции включает сверку пропущенных событий после восстановления передачи.

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

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

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

Статус «отправлено» нужно расшифровать до приёмки. Resend различает успешный запрос к API и доставку на почтовый сервер адресата. Ни тот, ни другой статус не подтверждает чтение человеком.

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

Только адреса недостаточно: он склеит разные покупки одного человека. Случайный новый ключ на каждую попытку даст обратную ошибку. Система примет повтор за новое письмо.

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

Защиту проводят до границы почтового сервиса. Например, Resend повторяет ответ на тот же запрос с тем же ключом без нового письма. На 7 октября 2026 ключ хранится 24 часа.

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

Просьба покупателя «пришлите ссылку заново» создаёт отдельное управляемое действие. Его отличают от повтора оплаты, ограничивают частоту и записывают причину. Старые ссылки обрабатывают по правилам доступа продукта.

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

ИИ-агенту отдают этот протокол вместе с задачей. Формулировка «сделать триггерные письма» оставляет ему решения о повторах и дублях. Постановку задач агенту разбираем в соседней статье.

Критерий готовности задаёт инженер, который принимает правку. Повторное письмо после сбоя и лишнее письмо после успеха проверяют разными испытаниями. Одного флага «обработано» для этих результатов мало.

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

Агент пишет код и воспроизводимые проверки, инженер принимает результат. Правила для ИИ-агентов задают границы работы, а тестовые отправки изолируют от данных покупателей. Сам запуск на покупателей согласуют отдельно.

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

Оператор видит остановившуюся очередь и причину отказа. Он может повторить разрешённое письмо или отменить потерявшее смысл. Каждое действие остаётся в истории.

Для маркетинга перед отправкой заново проверяют условия. Покупка могла завершиться, адресат мог отписаться, статус мог измениться. Ожидание в очереди не замораживает действия человека.

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

На странице /open видно, как инженер ведёт машину агентов на vibecoding.ru. Этот опыт помогает ставить проверки. Он не заменяет замер доставляемости и продаж в вашей компании.

При постоянных задачах по сайту второй шаг можно обсудить на /services. Тариф «Один проект» стоит 250 000 ₽ в месяц на 7 октября 2026: это подписка на поток разработки, а не цена настройки одной рассылки.

1. Зафиксируйте событие и условия отправки до работы над письмом.
2. Сохраните задание вместе с событием, чтобы остановка приложения не потеряла письмо.
3. Разделите повтор после сбоя и подавление дубля после успеха. Потерю ответа проверьте отдельно.
4. Принимайте сценарий по протоколу сбоев, с журналом и тестовым ящиком.
5. Сверяйте события с отправками. Каждый пропуск или дубль превращайте в задачу с проверкой.