Срок выполнения заявки – один из важнейших критериев оценки качества предоставления сервиса. В HelpDeskEddy вы можете создавать SLA планы (Service level agreement, сокр. SLA – политики соглашений об уровне обслуживания), которые позволят измерять и улучшать скорость реагирования сотрудников поддержки на обращения клиентов и повышать их удовлетворенность.

Использование соглашений об уровне обслуживания в HelpDeskEddy позволяет:

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

1. SLA планы (целевые метрики)
   1. Рабочая неделя, выходные и праздничные дни
   2. Привязка SLA плана к департаменту
2. Отображение SLA в заявке и общем списке
3. SLA в отчётах
4. Дополнительная информация

Настройка целевых метрик и рабочего времени для каждого департамента осуществляется в меню "SLA планы":

SLA план с id 1 является планом по умолчанию – его невозможно удалить и он всегда выбирается в каждом новом департаменте по стандарту. Если вы удалите ранее созданный план, который был выбран в одном или нескольких департаментах, то в них будет автоматически установлен SLA план с id 1.

Внутри каждого плана доступны различные настройки.

SLA план (целевые метрики):

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

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

• SLA на выполнение – время с момента создания заявки до момента её закрытия (перевода в соответствующий статус) – за сколько сотрудник должен обработать и закрыть заявку. 

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

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

Если же в заявке уже нарушился SLA на выполнение, то об этом тоже можно оповестить как в момент самого нарушения, так и через N времени после. За это отвечает настройка "напоминание о нарушенном SLA на выполнение спустя".

Чтобы активировать напоминание о подходящем/нарушенном SLA, а также оповещения при уже случившемся нарушении, необходимо перейти в меню "Диспетчер" и создать соответствующее правило, выбрав одно или несколько условий. Например:

В каждом SLA плане можно отдельно задать рабочую неделю и выходные/праздничные дни. Дело в том, что внутри одной компании различные отделы (департаменты) могут работать по-разному времени. Например, первая линия может обрабатывать заявки 24/7, а вторая с 09:00 до 18:00 в будние дни. 

Рабочее время – важнейший инструмент для правильного использования целевых метрик. Разберем на примере условного департамента "2 линия поддержки", который работает по SLA плану с рабочим временем с понедельника по пятницу с 09:00 до 18:00, и в этом плане стоит метрика "на первый ответ сотрудника" - 15 минут.

Теперь предположим, что на вторую линию поступило новое обращение в 08:00. Если бы мы не настроили рабочее время в SLA плане, то тогда SLA на первый ответ в этой заявке нарушился бы уже в 08:15 – в то время, когда сотрудников ещё даже нет на рабочем месте – согласитесь, это не очень справедливо.

Но так как у нас рабочее время для этого плана указано с 09:00, то система сперва дождется начала рабочего дня, и только потом запустит счётчик, поэтому у сотрудников будет именно 15 минут рабочего времени (когда все на местах и начался рабочий день), чтобы написать ответ и не нарушить метрику.

По такой же логике в отчётах работает принцип подсчёта в параметры "время первого ответ по SLA" и "время выполнения по SLA". Например, если заявка пришла в 8:00 утра, рабочий день в системе выставлен с 9:00, а сотрудник ответит в 9:15, то время ответа по SLA будет 15 минут (9:00+15 минут), т.к. учитывается именно рабочее время, а обычное время первого ответа будет 1 час 15 минут (8:00 + 1:15).

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

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

Теперь, когда мы создали и настроили SLA план, его осталось привязать к департаментам. Сделать это можно в настройках любого департамента:

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

Посмотрим как теперь можно отслеживать метрики внутри заявки и в общем списке заявок.

Как только клиент создаёт заявку в департаменте, к которому привязан SLA план, в ней начинают отсчёт установленные метрики. Возле названия заявки отображен таймер – он показывает ближайшую метрику, которая нарушится раньше всех (это работает и в обратную сторону: если одна метрика была нарушена 10 часов назад, а другая всего 1 час назад, то будет отображено "-10 ч.", т.к. именно эта метрика ждёт своего "выполнения" дольше всего):

Как только сотрудник напишет первый ответ в заявке, метрика "SLA на первый ответ сотрудника" исчезнет, но по-прежнему останется "SLA на выполнение":

Если клиент напишет новый ответ, то запустится метрика "SLA на ответ сотрудника после ответа клиента":

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

В общем списке заявок контролировать сроки выполнения можно при помощи фильтров и сортировки. В фильтрах для контроля SLA есть такие условия:

• Оставшееся время SLA на выполнение. Показывает все заявки, в которых оставшееся время SLA на выполнение больше/меньше X времени.
• Превышен срок SLA на выполнение. Показывает все заявки, в которых нарушен SLA срок на выполнение.
• SLA установлен. Показывает все заявки, в которых установлены целевые метрики (SLA план).

Чтобы отсортировать тикеты и отобразить вначале заявки, в которых SLA будет нарушен раньше всех, добавьте колонку "Ближайший SLA" в настройках списка заявок, нажав на шестеренку:

 Применить сортировку можно нажав на стрелочки возле параметра:

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

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

При помощи отчёта "экспорт заявок" можно выгрузить список заявок в .xml или .csv файл, а в шаблоне экспорта представлено множество тегов, связанных со SLA. Они помогут отобразить была ли в заявке нарушена SLA метрика, какое количество раз, сколько времени осталось на выполнение и т.д.:

Что важно помнить при работе со SLA:

• Если вы удалите SLA план, то в департаментах, в которых он был указан, будет автоматически установлен SLA план по умолчанию (c id 1).
• Сотрудники вручную не могут редактировать SLA метрики, кроме "выполнения заявки по SLA" – это поле отображается справа в заявке, но вы можете запретить его редактирование для любой группы сотрудников в меню "Группы, права доступа".
• При работе с заявкой её SLA план можно изменить при помощи Диспетчера.
• При нарушении SLA на первый/последующий ответ, заявка в списке красится в красный цвет. Если сотрудник ответил, то заявка перестает быть красной, а сам факт нарушения можно будет отследить в отчётах. Если нарушен SLA на выполнение, то заявка остаётся красной в списке заявок, пока не будет обнулён срок SLA на выполнение, либо изменён SLA план, либо пока заявка не будет закрыта.
• Если заявка переведена в статус "выполнено", заморожена, удалена в корзину или заблокирована, то SLA метрики ставятся на паузу.

Подробнее: при установке SLA на паузу, система считает количество времени, оставшееся до нарушения SLA на выполнения с учётом рабочего времени и праздников. А вот SLA на первый ответ/последующий ответ не пересчитывается после снятия паузы, а считается то время, которые задано в SLA плане, при условии, что они не были нарушены.

Например, установлены такие метрики: SLA на первый ответ 10 минут, на последующий 10 минут, на выполнение 60 минут и через 5 минут заявку заморозили. После снятия паузы, SLA на первый и последующий будет 10 минут (согласно SLA плану), а SLA на выполнения будет уже 55 минут, т.к. 5 минут уже были потрачены до заморозки заявки.

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

Например, рабочее время выставлено с пн-пт с 09:00 до 17:00. Сотрудник уже в нерабочее время, в 18:00 вручную выставил SLA срок на 20:00 этого же дня, и сразу заморозил заявку (SLA встало на паузу). Далее он разморозил заявку в 18:05 – после этого SLA на выполнение все равно будет посчитано как 120 минут с учётом рабочей недели (!). Таким образом SLA на выполнение после разморозки будет нарушено не в 20:05, а уже в 11:00 следующего рабочего дня, т.к. система считает именно рабочие часы.