Пользователь
Логин:
Пароль:
Забыли свой пароль?

Поиск по сайту
 

 Расширенный поиск
Реклама

 

Опрос


Погода

Маршрутизации обращений
Форумы
Обновления
Поиск
Пользователи 
Правила
Помощь
Войти

Страницы: 1
Маршрутизации обращений
#1
26.03.2012 14:13:55
добрый день!
а никто не ставил цель - считать время маршрутизации обращений от 1-й линии на 2-ю? Мне, как менеджеру процессов,интересно чтобы 1-я линия передавала автоматически зарегистрированные заявки в течении 40 минут, а не 4-х часов. (индивидуальные показатели менее интересны, это уже забота тим-лидера). С наскоку не нашёл возможности в SD сделать счётчик. Если отбросить усложняющие нюансы, условия для правила следующие:
если заявка в статусе "зарегистрировано" и рабочая группа = "1-я линия" то отсчитывать время в формате ЧЧ.ММ.СС (и сохранить это значение в поле заявки для последующей статистики)
не подскажите как можно это реализовать?
Изменено: Виктор FVS - 26.03.2012 14:14:35
 
 
#2
26.03.2012 14:21:38
А к чему ни будь завязаться можно? Как происходит регистрация заявок в целом на первой линии?
1 Вариант. (Почта)
Пользователь написал сообщение. Сообщение попало в систему в статус (Новое). Первая линяя производит регистрацию путем изменения поля статус и меняя поле группа.
Тут можно произвести завязку на статус и на поле группа.
2. Вариант (Телефон)
Оператор регистрирует заявку сразу на вторую линию. Т.е объект создается не на первой линии.. Завязка на условие создания и не первая линяя.

Можно так решить…
 
 
#3
26.03.2012 14:41:54
Варианты с подсчетом времени обработки на 1-й линии следующие:
1. При назначении на группу заявка переводится в следующий статус (допустим, из "Зарегистрировано" в "Назначено"), при этом правилом в custom поле "Время назначения" устанавливается текущая дата. Далее с помощью какой-либо системы отчетности считаем разницу между датой регистрации и временем назначения (среднее значение для группового показателя).
2. Вариант без использования дополнительного поля (тяжелый и неоптимальный). С помощью sql-запроса из таблицы с историей по заявке ищем дату изменения статуса и также считаем разницу.
3. Вариант для расчета времени обработки на 1-й линии с учетом уровня сервиса. При переводе в следующий после автоматической регистрации статус перенести в поле "планируемое начало (может называться по-другому в вашей локализации)" дату регистрации, а поле "планируемое окончание" текущую дату. В поле "планируемый срок" посчитается необходимый вам параметр в часах\минутах. Посчитается он исходя из: уровня сервиса в установленном в заявке SLA\рабочих часов рабочей группы\24х7, в зависимости от настроек системы.
 
 
#4
26.03.2012 14:45:04
А конкретно для каких целей? 1 линия забывает переводить? Или она вообще не видит поступление новых запросов? Или вам просто для анализа, чтобы в конце месяца видеть по сколько минут тратили на перевод?
 
 
#5
27.03.2012 11:44:52
спасибо, за ответы. подробнее:
Григорий, именно 1-й вариант. нужно оценивать автоматически зарегистрированные заявки по почте. к чему привязаться ясно, не ясно как настроить действие (счётчик времени)
Артём, 1-й вариант понятен, но хотелось бы и ищем путь получать продолжительность средствами SD, а не "с помощью какой-либо системы отчетности".
2-й вариант тяжелый, не подходит
3-й вариант кажись механизм подходит, но полностью я его пока не понял, и можно ли это сделать не на существующих, а добавить свои поля, и без привязки к сервису, т.к. независимо от сервиса все заявки должны быстро покидать 1-ю линию.
Сергей, для каких целей - получаем около 400 звонков в день, + несколько сотен писем на email, на котором автоматическая регистрация. Соот-во заявки регятся, но расписываются по группам медленно, и нам нужно объективно понимать слово "медленно", получить цифры. Также желательно эту цифру видеть самой 1-й линии, чтобы фильтром вьюхи можно было настроить подсвечивание "долгих" заявок красным и т.п.
Изменено: Виктор FVS - 27.03.2012 11:45:38
 
 
#6
27.03.2012 13:12:28
Виктор, для расчета длительности с помощью добавленных полей можно использовать Данные-Рассчитываемые поля-ServiceCall. Должно считаться без учета уровня сервиса.
Расчеты же с учетом уровня сервиса делаются обычно для того, чтобы не получать отрицательных данных в часы\дни, когда заказчик по договору не поддерживается.
 
 
 
Страницы: 1

Сегодня были (гостей: 2, пользователей: 0, из них скрытых: 0)