Уведомления контрагенту в B2B-портале: события заказа, статусы и каналы оповещения

Уведомления контрагенту в B2B-портале — это сообщения, которые система отправляет клиенту при наступлении событий в его заказах и документах. Для предсказуемой работы зафиксируйте матрицу «событие × получатель (роль) × канал × шаблон», назначьте ответственного и проверьте, что каждое уведомление уходит один раз нужному адресату. Ниже — предметная последовательность, критерии выбора каналов, учебный пример и чек-лист приёмки.

Что входит в задачу уведомлений контрагенту и где её границы

Задача касается только оповещений клиента-контрагента о его заказах и связанных документах. Внутренние уведомления сотрудников продавца (менеджеров, кладовщиков, бухгалтерии) в эту работу не входят. Не смешивайте корпоративный портал сотрудников и клиентский B2B-портал: это разные аудитории и разные правила доступа.

Границы задачи удобно зафиксировать письменно до настройки. В них входят:

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

За границами остаются финансовые условия сделки: цены, отсрочка, лимиты и порядок расчётов определяются продавцом. Сервис уведомлений не является кредитором и не принимает решений о коммерческих условиях. Если в процессе участвуют персональные данные представителей контрагента, порядок их обработки согласуйте с профильным специалистом.

Исходные данные и ответственные за уведомления

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

Что нужно подготовить:

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

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

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

Варианты организации оповещений и критерии выбора

Есть несколько практических вариантов, и выбор зависит от того, как устроен ваш процесс продаж и как контрагент привык работать.

Первый вариант — уведомления только в личном кабинете. Контрагент видит события в интерфейсе, когда заходит сам. Плюс: не зависит от внешних каналов, вся история в одном месте. Минус: если клиент редко заходит, событие остаётся незамеченным.

Второй вариант — только электронная почта. Привычно, но при большом потоке письма теряются, а статус заказа в письме быстро устаревает.

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

Четвёртый вариант — событийные подписки: контрагент сам выбирает, какие события и по каким каналам получать. Гибко, но требует понятного интерфейса настроек и ролей, иначе клиент отключит нужное или включит лишнее.

Критерии выбора:

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

Если вы только проектируете портал, разумно сразу закладывать событийную модель и роли — это снижает затраты на доработки после запуска. Подробнее о том, как устроен такой контур, — в материале про разработку b2b-порталов и оптовых интернет-магазинов на 1с-битрикс.

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

Работу удобно вести по шагам, от перечня событий к проверке.

Шаг 1. Составьте перечень событий заказа

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

Шаг 2. Определите получателей по ролям

Для каждого события укажите, какая роль контрагента должна получить сообщение. Если событие важно нескольким ролям, это отражается в матрице, но не превращается в несколько одинаковых писем одному человеку.

Шаг 3. Выберите канал для каждого события

Канал выбирается по критичности и привычкам клиента. Ключевые события имеет смысл дублировать, информационные — оставлять в личном кабинете. Об устройстве клиентского интерфейса с остатками и ценами — в материале про личный кабинет B2B: остатки, цены под клиента и повторные заказы.

Шаг 4. Подготовьте шаблоны

В шаблоне должны быть понятные данные: номер заказа, статус, дата, что изменилось, ссылка на объект в портале. Текст должен позволять понять событие без перехода по ссылке, но давать возможность открыть детали.

Шаг 5. Настройте правила и проверьте дубли

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

Шаг 6. Проведите тестовый прогон

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

Матрица «событие × получатель × канал × шаблон»

Матрица — основной рабочий артефакт. Она связывает событие, роль, канал и шаблон, и по ней же проводится приёмка. Ниже — пример структуры; конкретное наполнение зависит от вашего процесса.

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

Каналы оповещения: как выбрать и что учесть

Канал — это способ доставки сообщения. У каждого есть свои ограничения, и их полезно знать до настройки.

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

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

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

При выборе канала полезно ответить на три вопроса: увидит ли контрагент сообщение в срок, сможет ли он вернуться к нему позже, и есть ли у вас подтверждение доставки. Если хотя бы на один вопрос ответа нет, канал требует дополнительной проверки.

Учебный пример: настройка уведомлений для оптового контрагента

Учебный пример. Данные условные.

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

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

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

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

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

Типичные ошибки и как их избежать

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

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

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

Чек-лист приёмки уведомлений

Проверка проводится на тестовом контуре до переноса правил в рабочий. Отмечайте пункты по факту, а не по ожиданию.

• Перечень событий заказа и документов согласован и не содержит пропусков.
• Для каждого события определена роль получателя на стороне контрагента.
• Для каждого события выбран канал и обоснован критериями.
• Шаблоны содержат номер заказа, статус, дату и ссылку на объект.
• Одно событие порождает одно сообщение на канал, дублей нет.
• Повторная обработка события не создаёт второе сообщение.
• Получатели соответствуют ролям, ручное указание адресатов исключено.
• История событий доступна в личном кабинете контрагента.
• При сбое канала событие сохраняется, а ответственный получает сигнал.
• Назначены ответственные за правила и за техническую часть.
• Проведён тестовый прогон по всем событиям матрицы.
• Подготовлены копия, резервирование и план возврата перед изменениями в рабочем контуре.

Ограничения и следующий шаг

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

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