Приглашаем к тестированию LadVen OSЗапросить демо
Перейти к основному содержимому

Правила обработки входящих писем

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

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

Правила настраиваются для подключённого ящика в его настройках. Как подключить ящик — в разделе Почта.

Как работает правило

Как работает правило — conceptual guidance, not UI evidence

Каждое правило состоит из двух частей:

  • Условия — при каких письмах правило срабатывает;
  • Действия — что портал делает с подходящим письмом.

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

Условия

Условия — conceptual guidance, not UI evidence

Условия описывают, какие письма попадают под правило. Доступные условия:

УсловиеКогда использовать
Отправительписьма от конкретного адреса — например, постоянного клиента или партнёра.
Домен отправителявсе письма из одной компании (по части адреса после @).
Получательписьма, пришедшие на конкретный адрес общего ящика (продажи, поддержка, счета).
Темаписьма с ключевым словом в теме — «заявка», «счёт», «жалоба».
Папкаписьма, попавшие в определённую папку ящика.
Наличие вложенийписьма с файлами — например, договоры или документы на проверку.

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

В редакторе выберите, как объединять добавленные условия:

  • Все условия — письмо должно соответствовать каждому указанному условию;
  • Любое условие — достаточно совпадения хотя бы с одним условием.

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

Действия

Действия — conceptual guidance, not UI evidence

Действия описывают, что происходит с подходящим письмом. Доступные действия:

  • Создать обращение в CRM — письмо становится обращением, с которым дальше работает отдел; источник и содержание сохраняются.
  • Назначить ответственного — обращение или поток сразу получает владельца, а не ждёт ручного распределения.
  • Задать статус потока — перевести переписку в нужное состояние (например, «в работе» или «требует ответа»).
  • Отметить, что требуется ответ — выделить письмо, на которое нужно ответить, или снять такую отметку.
  • Пометить письмо — визуально выделить важные письма.
  • Переместить в папку — разложить письма по папкам автоматически.
  • Отправить автоответ — поставить ответ по шаблону в очередь (см. ниже).
  • Оставить письмо локально — обработать письмо без продвижения в CRM, когда обращение заводить не нужно.

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

Автоответ

Автоответ — conceptual guidance, not UI evidence

Автоответ ставит заранее подготовленный ответ в очередь после совпадения письма с правилом. Он отправляется с этого ящика не сразу. Если исходящая автоматизация отключена в политике ящика, автоответ не отправится; ответы на сам ящик и письма от отправителей no-reply пропускаются.

Настраивая автоответ, учитывайте:

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

Не превращайте автоответ в имитацию живого ответа. Его задача — подтвердить приём и задать ожидание по срокам, а не заменить работу менеджера.

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

Приоритет правил

Приоритет правил — conceptual guidance, not UI evidence

Портал применяет первое подходящее правило, поэтому порядок решает исход:

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

Проверка на примере

Проверка на примере — conceptual guidance, not UI evidence

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

Хорошие практики

Хорошие практики — conceptual guidance, not UI evidence

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

Частые ошибки

Частые ошибки — conceptual guidance, not UI evidence

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

Связанные разделы

Связанные разделы — conceptual guidance, not UI evidence