Вопросы и ответы

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

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

Как работает автоматическое закрытие обращений?

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

1. Обращение находится в состоянии разрешения.
2. У обращения заполнено фактическое время разрешения.
3. Срок ожидания оценки работ по обращению истек.

Подробнее: Процесс обработки обращений

Оценка по обращению не приходит. Также при переходе по ссылке для написания комментария к оценке открывается некорректная страница при условии, что системная настройка «Адрес сайта» заполнена корректно. Свойства UseCSATRatingService и CSATRatingService включены. Что предпринять для исправления?

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

Email-сообщение не связывается с обращением. Если оно связывается, то с существующим обращением, вместо создания нового. В чем причина?

1. Проверьте соответствует ли полученное email-сообщение правилам связи email-сообщения с существующим обращением.
2. Убедитесь, что письмо имеет такой же ConversationID, как другие письма по обращению. ConversationID — это идентификатор, который указывает на то, что письма связаны, то есть имеют одну цепочку.

Если у нового письма ConversationID совпадает с идентификатором ветки существующего обращения, то email-сообщение привяжется к нему. Например, если новое обращение было отправлено как ответ на одно из писем ветки по существующему.

Email-сообщение не регистрируется, если почтовый ящик указан в копии или скрытой копии письма. Что делать?

Базовая функциональность BPMSoft не предусматривает возможность регистрации обращений, если почтовый ящик не указан в основных получателях письма. Активация такой функциональности возможна через SQL-скрипт с указанием ее названия – RegisterCaseFromAnyEmail. Подробнее о включении скрытых функциональностей читайте в разделе статьи Механизм управления функциональностью Feature Toggle.

После активации функциональности RegisterCaseFromAnyEmail базовая логика проверки наличия в получателях (TO, CC, BCC) письма адреса целевого ящика для регистрации обращений будет отключена и обращения будут регистрироваться по всем письмам, синхронизируемым для данного почтового ящика.

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

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

Обновятся ли сроки реакции и разрешения в обращении, если обновить их в сервисе?

Обновление сроков реакции и разрешения зависит от состояния обращения, например:

1. Обращение еще не просрочено. Сроки реакции и разрешения обновятся, если заново закрепить сервис в сервисном договоре. Иначе в ранее созданных обращениях сроки не изменятся.
2. Обращение уже просрочено. Изменение сроков в сервисе не повлияет на сроки реакции и разрешения. Если флаги «Просрочен по реакции» и «Просрочен по разрешению» установлены, то они не будут изменены.
3. Обращение переоткрыто. Если обращение из состояния «Решено» переводится в состояние «Переоткрыто», то происходит перерасчет только времени разрешения.

Для чего используется справочник «Правила поведения полей сроков в обращении при изменении состояния»?

В BPMSoft существует функциональность CaseStagesFromDCM, которая активирована по умолчанию для всех сотрудников (All employees). Подробнее о включении функциональности смотрите в статье Механизм управления функциональностью «Feature toggle».

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

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