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