Уведомления в 1С:Комплексная автоматизация: сценарии клиентских сообщений

В «1С:Комплексная автоматизация» уже находится значительная часть информации, которую компании регулярно сообщают клиентам: зарегистрирован заказ, определены условия и сроки оплаты, изменилось состояние выполнения заказа, поступила оплата, появилась просрочка, произошла отгрузка, сформированы документы продажи.

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

Поэтому задача «уведомления 1С Комплексная автоматизация» обычно состоит не только в отправке письма. Необходимо связать учетное событие с правилом коммуникации:

событие в 1С → данные документа → правило → персонализированное сообщение → автоматическая отправка или проверка сотрудником → журнал.

Рассмотрим, какие данные «1С:Комплексной автоматизации» можно использовать для таких сценариев и где заканчиваются штатные возможности учетной системы и начинается событийная автоматизация клиентских коммуникаций.

Какие данные для уведомлений уже есть в 1С:Комплексная автоматизация

Один из наиболее удобных источников событий — контур продаж.

В «1С:Комплексная автоматизация» используется документ «Заказ клиента». Система позволяет отслеживать состояние выполнения заказа, условия и этапы оплаты, состояние оплаты и наличие просрочки, а также информацию об отгрузке. Для продаж формируются соответствующие документы и печатные формы.

Это важно для автоматизации сообщений: системе не требуется создавать отдельный параллельный источник данных о заказе. В большинстве типовых сценариев необходимая бизнес-информация уже возникает в 1С в ходе обычной работы сотрудников.

Официальный раздел фирмы «1С» «Управление продажами | 1С:Комплексная автоматизация» подтверждает наличие документа «Заказ клиента», управления его выполнением через состояния, контроля этапов и состояния оплаты, просроченной оплаты и отгрузки, а также формирования документов продажи и связанных печатных форм.

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

Штатная 1С и автоматические клиентские сообщения — это разные задачи

Важно не смешивать учетную функциональность «1С:Комплексной автоматизации» и дополнительную автоматизацию коммуникаций.

Штатная конфигурация является источником бизнес-данных. В ней возникают документы, меняется состояние заказа, отражаются расчеты, контролируются сроки и регистрируется отгрузка.

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

Например, сам факт изменения состояния заказа нужен для учета и управления продажей. Правило «при наступлении этого состояния сформировать клиенту письмо, подставить номер заказа и плановую дату и отправить его» — уже логика автоматизации коммуникаций.

Именно эту часть может выполнять Алертариум — Центр клиентских коммуникаций.

Алертариум не заменяет учетные механизмы «1С:Комплексной автоматизации». Он использует возникающие в 1С события и данные как основание для подготовки клиентских сообщений.

Сценарий 1. Подтверждение регистрации или изменения заказа

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

Источник события в 1С

Источником является «Заказ клиента» и его текущие данные.

Компания самостоятельно определяет, какой момент должен запускать коммуникацию. Это может быть первоначальная регистрация заказа или изменение его состояния, означающее, что заказ перешел на следующий этап внутреннего процесса.

Что можно сообщить клиенту

В сообщение могут подставляться:

• номер и дата заказа;
• наименование клиента;
• сумма;
• согласованные условия;
• плановые сроки;
• контакт ответственного менеджера;
• другая информация, которая действительно хранится в используемом процессе 1С.

Пример сообщения:

Ваш заказ № 1845 принят в работу. Плановый срок исполнения — 18 сентября. Если условия заказа изменятся, мы сообщим об этом дополнительно.

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

Режим отправки

Если сообщение только подтверждает уже зафиксированные в 1С данные и не содержит дополнительных обещаний клиенту, его обычно можно рассматривать как хороший кандидат на автоматическую отправку.

Если сотруднику необходимо дополнительно согласовать срок или условия, безопаснее сначала сформировать сообщение как черновик для проверки.

Сценарий 2. Подтверждение оплаты

Состояние оплаты — еще один пример данных, которые клиенту часто приходится уточнять у менеджера.

Покупатель перечисляет деньги и затем спрашивает:

«Оплата поступила?»

Сотрудник проверяет данные в 1С и вручную отвечает. При большом количестве заказов это превращается в постоянный поток однотипных операций.

Логика сценария

Изменилось состояние оплаты в 1С → определить заказ и клиента → сформировать подтверждение → отправить сообщение.

В сообщение можно подставить:

• номер заказа;
• сумму заказа;
• полученную сумму;
• актуальное состояние расчетов;
• данные ответственного сотрудника.

Например:

Оплата по заказу № 1845 получена. Благодарим. Заказ продолжает обрабатываться в соответствии с согласованными условиями.

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

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

Сценарий 3. Информирование о ходе выполнения и отгрузке заказа

«1С:Комплексная автоматизация» позволяет пользователю контролировать состояние выполнения заказа и сведения об отгрузке. Эти данные могут использоваться не только внутри компании, но и как источник клиентской коммуникации.

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

Поэтому сначала определяется бизнес-событие, а затем правило сообщения.

Например:

в заказе возникло состояние, которое по правилам компании означает готовность к передаче клиенту → подготовить уведомление.

В него можно включить:

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

Пример:

Заказ № 1845 подготовлен к следующему этапу исполнения. Плановая дата отгрузки — 18 сентября. По организационным вопросам можно обратиться к вашему менеджеру.

Если факт однозначно следует из данных 1С, уведомление может отправляться автоматически.

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

Сценарий 4. Отправка документов после их формирования

Еще одна типовая ручная операция возникает после оформления документов продажи.

Документ уже создан в 1С, но дальше сотруднику нужно:

1. определить, что его пора передать клиенту;
2. сформировать необходимую печатную форму;
3. найти контакт;
4. подготовить письмо;
5. приложить документ;
6. отправить сообщение.

Здесь полезно разделить два действия.

«1С:Комплексная автоматизация» остается системой, в которой оформляются учетные документы и формируются их представления. Алертариум отвечает за правило коммуникации: когда сформированный документ нужно передать клиенту и каким должно быть сопровождающее сообщение.

Сценарий может выглядеть так:

необходимый документ оформлен в 1С → выполнены условия правила → сформировано письмо → подставлены реквизиты → приложен предусмотренный документ → письмо отправлено либо передано сотруднику для проверки.

В тексте сообщения могут использоваться:

• организация;
• клиент;
• номер заказа;
• номер документа;
• дата;
• сумма;
• имя менеджера;
• сопроводительный текст.

Для стандартных документов с однозначным получателем автоматическая отправка сокращает число однотипных действий менеджера.

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

Сценарий 5. Напоминание о сроке оплаты и работа с просрочкой

Информация о сроках и состоянии оплаты особенно полезна для событийной автоматизации.

Здесь возможны два разных по риску сценария.

Напоминание до срока оплаты

Правило проверяет данные 1С и при приближении установленной даты формирует нейтральное напоминание.

Например:

Напоминаем, что по заказу № 1845 приближается срок оплаты. Актуальные данные по заказу указаны в сообщении ниже.

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

Такой сценарий хорошо формализуется, если все необходимые значения надежно ведутся в 1С.

Сообщение при просрочке

Просроченная задолженность требует более осторожного подхода.

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

Поэтому правило может не отправлять письмо сразу, а создавать готовое сообщение:

По данным учета на текущую дату по заказу № 1845 остается сумма к оплате. Просим проверить состояние расчетов. Если оплата уже произведена, пожалуйста, не учитывайте это сообщение.

Менеджер проверяет текст и при необходимости корректирует его перед отправкой.

Таким образом, автоматизация не обязательно означает полное исключение человека. Она может убрать подготовительную работу, оставив сотруднику только контроль решения.

Какие данные необходимо подготовить для автоматических уведомлений

Качество сообщения напрямую зависит от качества данных в 1С.

До запуска сценариев стоит проверить, где и как хранятся:

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

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

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

Как работает правило коммуникации

Для каждого сценария фактически требуется ответить на несколько вопросов.

Что произошло?

Определяется событие или состояние данных в «1С:Комплексной автоматизации».

Например, изменилось состояние заказа или состояние оплаты.

Кому нужно сообщить?

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

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

Что написать?

Для события выбирается шаблон.

Постоянная часть текста задается заранее, а переменные значения подставляются из 1С.

Нужно ли участие менеджера?

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

• отправить автоматически;
• сформировать сообщение для проверки сотрудником.

Это позволяет не применять одинаковую степень автоматизации к принципиально разным ситуациям.

Когда сообщение безопасно отправлять автоматически

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

Типичные примеры:

• подтверждение стандартного события по заказу;
• подтверждение поступления оплаты;
• передача заранее определенного документа;
• стандартное напоминание по установленной дате.

В этих случаях сотрудник не добавляет новой информации — он фактически только переносит данные из 1С в письмо.

Проверка человеком полезнее, если сообщение связано:

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

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

Зачем нужен журнал сообщений

Если клиентские уведомления становятся частью бизнес-процесса, недостаточно только отправить письмо.

Компания должна понимать:

• какое событие стало причиной сообщения;
• какому клиенту оно предназначалось;
• когда было сформировано;
• отправлялось автоматически или после проверки;
• какой текст был отправлен;
• какие данные использовались.

Поэтому завершающий этап сценария — журнал коммуникаций.

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

Как Алертариум использует события 1С:Комплексной автоматизации

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

Логика выглядит следующим образом:

бизнес-событие → данные 1С → правило коммуникации → шаблон → персонализированное сообщение → автоматическая отправка или проверка → журнал.

При этом данные заказа, расчетов и документов продолжают храниться и обрабатываться в «1С:Комплексной автоматизации».

Алертариум не является заменой CRM и не превращает транзакционные сообщения в массовую маркетинговую рассылку.

CRM помогает организовать работу сотрудников с клиентом. Алертариум решает более узкую задачу: стандартная коммуникация может запускаться самим событием в учетной системе без обязательного создания ручной задачи менеджеру.

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

Где фактически отправляется email

Для компаний, использующих локальную информационную базу, существенен вопрос архитектуры.

Фактическая отправка email выполняется из локальной 1С клиента. Там же остаются учетные данные подключения к почтовому серверу.

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

Это позволяет разделить две функции:

• управление логикой клиентских коммуникаций;
• непосредственную отправку сообщения инфраструктурой клиента.

С каких сценариев начать

Для внедрения не требуется сразу автоматизировать все сообщения, которые сотрудники отправляют из «1С:Комплексной автоматизации».

Практичнее выбрать несколько часто повторяющихся операций и для каждой описать:

Событие → Получатель → Содержание → Данные из 1С → Автоматически или после проверки.

Например:

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

Такой подход позволяет использовать «1С:Комплексную автоматизацию» как достоверный источник бизнес-событий, а автоматизацию строить вокруг уже существующего учетного процесса, не создавая для менеджеров еще одну систему, в которой необходимо вручную дублировать данные.

Автоматизируйте сообщения по событиям 1С

Автоматизируйте клиентские коммуникации в 1С с Алертариумом. Система сама создаст и отправит нужное сообщение по событию, сократит ручную работу менеджеров и ускорит информирование клиентов. Начните с нескольких ключевых сценариев сейчас.