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