Уведомления о заказе: письма покупателю и менеджеру

Покупатель, не получивший письмо с подтверждением заказа, начинает сомневаться, прошёл ли заказ вообще, — а менеджер, не узнавший о новом заказе вовремя, задерживает обработку. Разберём настройку уведомлений о заказе в 1С-Битрикс: и для покупателя, и для команды магазина.

Штатные почтовые события для заказа

Модуль продаж регистрирует собственный набор почтовых событий — подтверждение нового заказа, уведомление об изменении статуса, уведомление менеджеру о новом заказе. Список конкретных событий и их привязка к действиям видна в разделе Сервисы → Почтовые события → Настройки, где для каждого действия можно посмотреть, какое именно событие за него отвечает.

Отдельные шаблоны под каждый статус

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

Уведомление менеджера о новом заказе

Настройка получателя уведомления о новом заказе (конкретный email, список email или интеграция с мессенджером) определяет, насколько быстро команда узнает о новом обращении, — для магазинов с высокой скоростью реакции как конкурентным преимуществом стоит рассмотреть дублирование уведомления не только по email, но и через telegram-бота или другой мессенджер, где сотрудники реагируют быстрее, чем на почту.

Программная отправка кастомного уведомления

<?php

use Bitrix\Main\Mail\Event;

EventManager::getInstance()->addEventHandler(
    'sale',
    'OnSaleStatusOrderChange',
    function ($event) {
        $orderId = $event->getParameter('ORDER_ID');
        $order = \Bitrix\Sale\Order::load($orderId);

        if ($order->getField('STATUS_ID') === 'DELIVERED') {
            Event::send([
                'EVENT_NAME' => 'ORDER_REVIEW_REQUEST',
                'LID' => $order->getSiteId(),
                'C_FIELDS' => ['ORDER_ID' => $orderId],
            ]);
        }
    }
);

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

Уведомления через SMS и push вместо только email

Email — не единственный и не всегда самый быстрый канал для уведомления покупателя: для срочных статусов (например, "курьер выехал") SMS или push-уведомление часто эффективнее, поскольку открывается быстрее письма, особенно если покупатель редко проверяет почту в течение дня. Подключение таких каналов требует отдельной интеграции со специализированным сервисом, поскольку штатный механизм почтовых событий Битрикса рассчитан именно на email.

Дублирование уведомлений и усталость от них

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

Тестирование всей цепочки уведомлений

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

Частые ошибки

• Один универсальный шаблон письма для всех статусов. Формальный сухой текст вместо релевантного конкретному этапу сообщения.
• Уведомление менеджеру идёт только на email. Задержка реакции команды по сравнению с более быстрыми каналами.
• Избыточные уведомления по каждому мелкому статусу. Покупатель перестаёт обращать внимание на действительно важные сообщения.
• Проверен только один статус, а не полная цепочка. Ошибка в промежуточном звене остаётся незамеченной до реальной жалобы покупателя.

Итог

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