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

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

Разделите письмо и задачу на два объекта

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

Это принципиальное разделение. Письмо — исходная информация, поступившая от клиента. Задача — рабочий объект, который появляется после обработки этой информации. Если через некоторое время потребуется понять, почему была создана конкретная задача, исходное письмо останется в системе и позволит восстановить контекст.

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

Настройте получение сообщений из почты

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

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

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

Запускайте обработку при появлении нового письма

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

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

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

Определите контакт по электронной почте

Следующий шаг — найти отправителя среди существующих контактов.

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

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

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

Получите клиента и ответственного инженера

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

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

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

Создайте задачу с контекстом обращения

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

Исполнитель назначается автоматически на основании данных клиента.

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

В демонстрации срок задается формулой «дата создания плюс семь дней». Это именно параметр тестового сценария, а не универсальный срок обработки обращений.

Используйте данные клиента для дальнейшей маршрутизации

Главное преимущество такого подхода появляется после создания задачи. Она уже содержит не только текст письма, но и связи с остальной информацией о клиенте.

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

Получается последовательная модель:

электронная почта → письмо → контакт → клиент → ответственный → задача → дальнейшая обработка.

При этом каждый следующий шаг опирается на данные предыдущего, а не формируется отдельно.

Учтите работу с вложениями

В демонстрации отдельно рассматривается вопрос вложений. Короткие изображения и видео, которые клиент может присылать вместе с обращением, также могут участвовать в процессе. При этом для вложений размером более 5 МБ в исходном материале обозначено ограничение, которое необходимо учитывать при проектировании сценария.

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

Проверьте полный маршрут на тестовом письме

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

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

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

Исходная демонстрация настройки

Что дает такая архитектура

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

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

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

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

‍