Комментарии 17
У нас, к примеру, воркфлоу обработки запроса строится на основе статусов запроса: новый, на обсуждении, закрыт. Если оператор не знает, что ответить клиенту, он отправляет запрос на обсуждение на уровень выше (техконсультанту, админу, разработчику), т.е. инициирует внутреннее обсуждение запроса. Когда ответ подготовлен, оператор пишет и отправляет ответ клиенту.
Наверное, это стандартная схема. Однако, интересно было бы узнать и о других вариантах организации обработки запросов, которые применяются в ваших компаниях и группах.
Наверное, это стандартная схема. Однако, интересно было бы узнать и о других вариантах организации обработки запросов, которые применяются в ваших компаниях и группах.
А что такое хелпдеск? С точки зрения организационной структуры предприятия. Кому он подчиняется? И в чьих интересах работает?
Хелпдеск — служба поддержки ru.wikipedia.org/wiki/Служба_технической_поддержки
Один из вопросов, который хотелось бы обсудить: критерии, по которым оценивается приоритет запросов. Начиная от вручную выставленных «срочно — не срочно», заканчивая изменением приоритета за деньги клиентом (а что, ведь и такое бывает). Нужно ли? Если да, то какие схемы применяются у вас в работе?
НЛО прилетело и опубликовало эту надпись здесь
Могу лишь сказать исходя из своего опыта работы в крупной компании.
Система приоритетов в идеале неплоха: каждому приоритету регламентированное время решения проблемы, как следствие возможность гарантировать клиенту сроки и описывать их в договоре гарантировать перерасчет услуг при превышении этого времени (клиенто-ориентированность на лицо). Как вытекающее из системы приоритетов более удобная отчетность, анализ причинах превышения времени решения проблемы.
На практике же: часто загруженность сотрудников хэлпдеска, приводит к игнорированию приоритетов, и решению проблем просто по порядку, по времени появления. Зависимость сотрудников хэлпдеска от сотрудников других отделов, тоже очень часто делают систему приоритетов незначительной, загруженность других отделов, человеческий фактор. При сильном акценте на приоритетах в работе, начнется «тикетопинание» между отделами. Опять же есть шанс, что при большом количестве высоко приоритетных тикетов, тикеты более низкого приоритета будут копиться, откладываться.
Палка о двух концах.
Система приоритетов должна быть гибкой и генерироваться самой системой.
Лично мое мнение, система должна в реальном времени анализировать работу сотрудников. Чем меньше сотрудник загружен на данный момент, тем больше вероятность, что система назначит на него проблему, естественно анализируя общее число обработанных проблем. Адекватней будет система будильников, которая будет выделять ответственному отделу определенное время на решение проблемы, в зависимости от приоритета (и пусть сотрудники не знают этот приоритет).
Например:
1 приоритет (скрыт от сотрудников): На прием, обработку, координацию обращения, сотруднику хэлпдеска выделено 1час -> при координации на отдел расчетов, сотруднику этого отдела выделено 2.5 часа и т.д.
3 приоритет (скрыт от сотрудника): На прием, обработку, координацию обращения, сотруднику хэлпдеска выделено 2часа -> при координации на отдел расчетов, сотруднику этого отдела выделено 4 часа и т.д.
и приоритезировать тикеты согласно оставшемуся времени (показывать в списке очередность с которой сотрудник должен смотреть проблемы)
Система приоритетов в идеале неплоха: каждому приоритету регламентированное время решения проблемы, как следствие возможность гарантировать клиенту сроки и описывать их в договоре гарантировать перерасчет услуг при превышении этого времени (клиенто-ориентированность на лицо). Как вытекающее из системы приоритетов более удобная отчетность, анализ причинах превышения времени решения проблемы.
На практике же: часто загруженность сотрудников хэлпдеска, приводит к игнорированию приоритетов, и решению проблем просто по порядку, по времени появления. Зависимость сотрудников хэлпдеска от сотрудников других отделов, тоже очень часто делают систему приоритетов незначительной, загруженность других отделов, человеческий фактор. При сильном акценте на приоритетах в работе, начнется «тикетопинание» между отделами. Опять же есть шанс, что при большом количестве высоко приоритетных тикетов, тикеты более низкого приоритета будут копиться, откладываться.
Палка о двух концах.
Система приоритетов должна быть гибкой и генерироваться самой системой.
Лично мое мнение, система должна в реальном времени анализировать работу сотрудников. Чем меньше сотрудник загружен на данный момент, тем больше вероятность, что система назначит на него проблему, естественно анализируя общее число обработанных проблем. Адекватней будет система будильников, которая будет выделять ответственному отделу определенное время на решение проблемы, в зависимости от приоритета (и пусть сотрудники не знают этот приоритет).
Например:
1 приоритет (скрыт от сотрудников): На прием, обработку, координацию обращения, сотруднику хэлпдеска выделено 1час -> при координации на отдел расчетов, сотруднику этого отдела выделено 2.5 часа и т.д.
3 приоритет (скрыт от сотрудника): На прием, обработку, координацию обращения, сотруднику хэлпдеска выделено 2часа -> при координации на отдел расчетов, сотруднику этого отдела выделено 4 часа и т.д.
и приоритезировать тикеты согласно оставшемуся времени (показывать в списке очередность с которой сотрудник должен смотреть проблемы)
Спасибо за картинку — теперь я буду знать как рисовать ТЗ! (не шучу).
каким вы видите ваш идеальный хелпдеск
Однозначно не таким как как хелпдеск от IBM.
Извините, наболело…
напишите скрипт интеграции сторонего модуля в БД WA, типа инсталятора, с ясным API. будет только польза.
М-р-р-р, какой макет! :)
Самый лучший service desk, пока не идеальный, как мне видится,
1. Должен соответствовать ITIL, начиная от поддержки процессов управления инцидентами и проблемами, заканчивая подсчетом метрик,
2. Должен обладать хорошим интерфейсом. Потому что это слабое звено большинства решений. При заведении инцидента например, нужно вводить множество полей, так что должны быть шаблончики. Ну и еще по мелочи должны быть подобные решения для ускорения работы операторов. Интерфейс должен быть и для заявителей.
1. Должен соответствовать ITIL, начиная от поддержки процессов управления инцидентами и проблемами, заканчивая подсчетом метрик,
2. Должен обладать хорошим интерфейсом. Потому что это слабое звено большинства решений. При заведении инцидента например, нужно вводить множество полей, так что должны быть шаблончики. Ну и еще по мелочи должны быть подобные решения для ускорения работы операторов. Интерфейс должен быть и для заявителей.
Предлагаю не изобретать велосипед и посмотреть в Service Operations ITIL. там прекрастно описан хелпдеск таким каким он должен быть.
А идеальный хелпдеск для кого? Ведь действительно сильно зависит от размера компании (и чуть меньше — от специфики деятельности).
Угодить всем не получится.
Угодить всем не получится.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Идеальный хелпдеск