Раньше в правилах автоматизации учитывались не конкретные статусы сотрудников, а только доступ к обработке обращений и чатов в настройках статусов.

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

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

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

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

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

2. Отправляем браузерное и звуковое уведомления при добавлении заметки с упоминанием сотрудников, находящихся в статусах, которые предполагают, что сотрудник находится на рабочем месте или скоро вернётся после короткого отсутствия:

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

4. Распределяем простые обращения между сотрудниками в статусе «Обучение»:

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

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

Разберемся на конкретных примерах.

а) Например, такое правило распределяет чаты между сотрудниками с доступом к группе «Вопросы по оплате», у которых выставлен статус «Обучение»:

б) А такое правило распределяет обращения между конкретными сотрудниками при условии, что у них выставлен статус «Обучение». Если какой-то из указанных сотрудников выставит другой статус, правило не распределит на него обращения: