Письмо должно подтверждать реальное событие
Покупатель получил письмо «заказ оплачен», хотя лишь выбрал оплату переводом. Через несколько минут пришло ещё одно подтверждение, а ответ на письмо ушёл на ящик, который никто не проверяет. Такие проблемы возникают, когда уведомления настраивают как набор текстов без связи с процессом заказа.
Уведомления о заказах в Битрикс нужно проектировать по четырём вопросам: что произошло, кому об этом сообщить, какие сведения достоверны в этот момент и какое действие нужно дальше. Красивый шаблон не исправит неверный момент отправки или адрес другого клиента.
Почтовое событие обозначает основание для формирования сообщения, а шаблон определяет его адреса, тему и содержание. В документации Битрикс по почтовым шаблонам описаны привязка к типу события, поля отправителя и получателя, тема, тело и доступные переменные. Их состав нужно проверять для конкретного события и версии проекта.
Задача владельца магазина — утвердить смысл уведомлений и проверить путь письма на контролируемых примерах. Настройку очередей, обработчиков и почтового транспорта выполняет специалист. Ни сохранение шаблона, ни отсутствие ошибки в панели не доказывают, что нужное письмо получил покупатель.
Из чего складывается уведомление
Событие
Подтверждено изменение конкретного заказа.
Шаблон
Выбраны текст, данные и следующий шаг.
Адресат
Определён получатель и рабочий канал ответа.
Составьте карту уведомлений заказа
Начните с событий, которые действительно полезны клиенту: получение заказа, подтверждение условий, результат оплаты, передача в доставку, готовность к выдаче и отмена. Набор зависит от магазина. Не добавляйте письмо на каждый внутренний переход, если оно не меняет ожидания или доступное действие покупателя.
| Основание | Что сообщить | Чего не утверждать без подтверждения |
|---|---|---|
| Создан заказ | Номер, состав и следующий шаг | Что оплата уже получена |
| Условия подтверждены | Согласованные позиции и порядок исполнения | Что товар уже передан перевозчику |
| Подтверждена оплата | Учтённая сумма и состояние расчётов | Что частичная оплата закрыла весь заказ |
| Передано в доставку | Способ отслеживания | Что клиент уже получил товар |
| Отмена | Факт отмены и дальнейшая связь | Что возврат денег завершён |
Добавьте в карту адресата, источник события, ответственного за текст и условия повторной отправки. Если сообщение формирует внешняя платёжная или логистическая система, учтите его рядом с письмами магазина. Покупатель воспринимает всю переписку как один процесс и не обязан разбираться, какая система прислала каждую строку.
Разделите сообщения клиенту и сотрудникам. Менеджеру нужны служебные сведения для обработки, покупателю — понятный результат и следующий шаг. Пересылка одного внутреннего письма всем участникам может раскрыть лишние данные и оставить клиента без полезного объяснения.
Как написать понятное письмо о новом заказе
В теме укажите узнаваемое действие и номер заказа, если он уже присвоен. Не перегружайте её рекламными обещаниями. Получатель должен понять назначение письма по списку входящих и позднее найти его среди других сообщений магазина.
В начале сообщите подтверждённый факт: заказ получен. Далее покажите состав, количество, итоговую сумму с пояснением доставки, выбранный способ получения и следующий шаг. Если менеджер ещё уточняет наличие или стоимость доставки, это должно быть выражено прямо. Слова «всё подтверждено» уместны только после соответствующего решения.
Сохраняйте связь с конкретным заказом. Изменение карточки товара в каталоге не должно подменять описание уже оформленной покупки. Если письмо содержит ссылку на подробности, проверьте её доступность для нужного клиента и поведение после выхода из аккаунта. Ссылка не должна открывать сведения постороннему пользователю.
Условный пример: «Мы получили заказ № 124. Менеджер проверит состав и свяжется с вами указанным способом. Текущие сведения доступны в заказе». Это учебная формулировка; срок и способ ответа нужно подставлять только из реального процесса. Не обещайте звонок в течение часа, если такой порядок не обеспечен.
Завершите письмо способом связи по вопросу заказа. Покажите, можно ли отвечать на него напрямую и что указать в обращении. Если ящик не принимает ответы, предложите рабочий канал, а не просто предупреждение об ограничении.
Какие данные подставлять и как проверять пустые поля
Переменные шаблона подставляют меняющиеся сведения: номер, дату, имя, сумму и другие доступные значения. Их список зависит от события и реализации. Попросите исполнителя показать, откуда берётся каждое важное поле. Похожее название переменной не гарантирует, что она означает именно нужную сумму или адрес.
Для каждого необязательного значения задайте запасной вариант. Если имя не указано, письмо должно начинаться естественно, без пустого обращения и лишней запятой. Если номер отслеживания ещё неизвестен, не показывайте пустую кнопку или ссылку. Отсутствие данных лучше обработать в шаблоне заранее, чем исправлять после рассылки.
Проверьте длинные названия, несколько позиций и нестандартные символы. В письме должны сохраняться единицы, количество и различия вариантов товара. Сокращение названия не должно скрывать размер или модификацию, от которых зависит покупка. Суммы и подписи должны оставаться читаемыми на телефоне.
Отдельно согласуйте персональные данные. Включайте только то, что нужно для понимания и исполнения заказа. Полные внутренние комментарии, служебные отметки и лишние сведения о клиенте не должны попадать в шаблон по умолчанию. Состав и правовые основания обработки компания проверяет с ответственным специалистом.
Отправитель, получатель и ответ на письмо
Адрес получателя должен браться из согласованного источника конкретного заказа или аккаунта. Разберите, что происходит после изменения почты в профиле: куда уйдут сообщения по уже оформленной покупке? Это проектное правило, которое требуется проверить, а не оставлять случайному поведению разных модулей.
Покажите человеку узнаваемого отправителя. Если магазин использует несколько сайтов или направлений, проверьте соответствие названия, адреса и ссылок нужному сайту. В шаблонах Битрикс предусмотрены настройки адресов и дополнительных заголовков; фактическую конфигурацию подтверждает исполнитель.
Проверьте копии сообщений. Служебный получатель может быть нужен отделу продаж, но адреса других клиентов не должны появляться в открытой копии. Если используется общий ящик, определите, кто контролирует его и как передаёт обращения в работу. Полученное письмо без ответственного не решает задачу покупателя.
Отправьте ответ на тестовое письмо с контролируемого ящика. Убедитесь, что он пришёл туда, где его ожидает команда, сохранил связь с заказом и не вызвал автоматический цикл ответов. Такая проверка обнаруживает проблемы, которые не видны при просмотре самого шаблона.
Как проверить отправку по всей цепочке
Разделите этапы: событие возникло, сообщение сформировано, передано почтовому сервису, принято им и появилось в ящике получателя. Это разные подтверждения. По статусу в магазине нельзя автоматически заключить, что человек увидел письмо или прочитал его.
Для проверки используйте собственные тестовые адреса и заказ в согласованной среде. Не отправляйте пробные уведомления реальным клиентам и не меняйте адрес рабочего заказа ради удобства теста. Попросите специалиста показать безопасный способ воспроизведения события без реального платежа или отгрузки.
Если письмо отсутствует, соберите время события, номер тестового заказа, адрес получателя и ожидаемый шаблон. Исполнитель проверяет, было ли сформировано сообщение, как обработана очередь и что ответил почтовый сервис. Настройки домена и доставляемости также относятся к его проверке; владелец не должен случайно менять их без понимания связи с рабочей почтой.
Откройте доставленное сообщение на телефоне и компьютере в используемых почтовых клиентах. Проверьте читаемость без загрузки картинок, переносы длинных строк, кнопки и ссылки. Смысл заказа не должен храниться только в изображении, которое может не отобразиться.
Попадание одного письма во входящие не обещает одинаковую доставку всем адресатам. Для приёмки зафиксируйте проверенные ящики, время, результат и ограничения. После запуска нужен контроль сообщений о недоставке и жалоб на отсутствие писем, связанный с конкретными событиями и заказами.
Что подтверждают разные этапы
Сформировано
Магазин подготовил сообщение по событию.
Передано
Почтовый сервис принял сообщение для обработки.
Получено
В тестовом ящике проверено фактическое письмо и его содержание.
Как обрабатывать повторы и задержки
Заказ может обновляться несколько раз, а внешняя система — повторно сообщать уже известное состояние. В карте уведомлений определите, какое событие должно вызвать отправку нового письма, а какое является повтором. Покупателю не нужно несколько одинаковых подтверждений оплаты только из-за повторной технической передачи.
При этом не запрещайте все повторные письма без разбора. Клиент может запросить повтор подтверждения, менеджер — исправить ошибочные сведения, заказ — действительно вернуться на предыдущую стадию. Для каждого случая полезно различать автоматическую отправку, ручной повтор и новое содержательное событие.
Задержанное сообщение может потерять актуальность. Например, подтверждение получения заказа приходит после письма об отправке. Попросите исполнителя проверить порядок при восстановлении очереди и показать, как учитывается текущее состояние. Решение зависит от реализации, но результат для клиента должен оставаться объяснимым.
Повторная отправка всей очереди — не универсальная диагностика. Сначала нужно установить, какие письма уже приняты сервисом и какие действительно не ушли. Иначе клиент получит дубли, а команда утратит возможность понять исходную причину. Записывайте ручные действия и список затронутых сообщений.
Какие сценарии включить в приёмку
Выберите варианты заказа, которые меняют смысл письма: предоплата, оплата при получении, частичная оплата, самовывоз, доставка, отмена и частичная отправка. Проверяйте только применимые к магазину сценарии, но не ограничивайтесь одним полностью успешным примером.
- Письмо о создании не сообщает об оплате без подтверждения.
- В письме о частичной оплате понятны учтённая сумма и дальнейший шаг.
- Письмо о самовывозе содержит актуальный адрес и условие готовности.
- Недоступные переменные не отображаются как служебные обозначения.
- Получатель, копии и обратный адрес соответствуют карте уведомлений.
- Повторное событие не создаёт незапланированную рассылку.
- Все ссылки ведут на нужный сайт и соблюдают доступ к заказу.
Сверьте письмо с личным кабинетом и сообщением менеджера. Если в одном месте заказ готов, а в другом ещё ожидает подтверждения, нужно выяснить источник расхождения. Проектирование состояний разобрано в статье об обмене заказами сайта и 1С.
Результатом приёмки должен быть набор проверенных сообщений и таблица событий с ответственными. Укажите, какие версии шаблонов перенесены в рабочий проект и как вернуть предыдущие при ошибке. Проверяйте также реальные письма после первой штатной операции, не создавая искусственных заказов для посторонних клиентов.
Как поддерживать уведомления после запуска
При изменении доставки, оплаты, статусов или контактов пересматривайте связанные письма. Новый способ получения может потребовать другой адрес, инструкцию или следующий шаг. Назначьте владельца карты уведомлений, чтобы изменение процесса не оставляло старые обещания в автоматических сообщениях.
Поддержке нужен короткий порядок разбора жалобы «письмо не пришло»: какие сведения спросить, где проверить событие и кому передать техническую часть. Пароли, ключи и служебные данные почтового подключения не должны попадать в переписку с клиентом или публичный отчёт.
Для обсуждения настройки с ШТАБ ИТ подготовьте карту уведомлений, обезличенные примеры и описание расхождений. Если требуется пересмотреть отображение заказа после покупки, используйте также материал о личном кабинете покупателя. Начать стоит с точного события и адресата: это основа полезного письма.
Источники и полезные ссылки
Интерфейсы и возможности сервисов могут меняться. Перед настройкой сверяйтесь с актуальной документацией.


