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