Этот вопрос предназначен для профессиональных системных администраторов и специалистов службы поддержки рабочего стола. Извините, разработчики ... вы можете поговорить об отслеживании ошибок на Stack Overflow.
Какие функции или какие функции вы хотели бы иметь в своей справочной службе или в программном обеспечении для устранения неполадок?
Некоторые области могут включать отчеты, интеграцию с инвентаризацией оборудования / программного обеспечения, интеграцию Active Directory / LDAP, автоматическое закрытие заявок от те определенные пользователей.
Интеграция электронной почты. Без этого у меня нет никакого отношения к продукту службы поддержки. Важно, чтобы клиенты и сотрудники могли общаться с помощью электронной почты.
Интеграция проекта и задач обслуживания
Я хотел бы видеть систему, которая (по сути) показывает все работы, которую должен выполнить обслуживающий персонал. В большинстве малых и средних компаний есть существенное дублирование между людьми, выполняющими поддержку службы поддержки, людьми, выполняющими проекты, и людьми, выполняющими работы по обслуживанию. Я хотел бы иметь возможность управлять задачами для проектов и задачами для регулярного обслуживания вместе с задачами службы поддержки в единой системе управления работой.
Итак, «Joe Help Desk» смотрит на единый портал управления работой, который показывает 8 элементов поддержки пользователей, 2 элемента для проекта Windows 7 и 5 вещей, которые он делает каждый день для резервного копирования. «Администратор Jill Server» смотрит на тот же портал, на котором показаны ее 12 элементов для проекта Windows 7, 4 ежедневных задачи обслуживания сервера и 2 элемента поддержки пользователей, расширенные Джо. «Джефф Менеджер» смотрит на портал и видит свои задачи, а также может проверить, регулярно ли выполняются задачи обслуживания и как продвигаются проекты.
Есть рекомендации?
Хочу что-нибудь со встроенным переводчиком. Знаете, тот, который превращает пользовательский разговор в нечто, по крайней мере напоминающее разумное описание проблемы.
Возможность формировать отчеты на основе истории тикета
Например, это особенно удобно, когда у вас есть центр обработки вызовов, обрабатывающий взаимодействие с пользователем, а не персонал системы, который делает это напрямую. Таким образом, когда персонал системы решает проблему, заявка может быть помещена в очередь, чтобы операторский центр мог связаться с клиентом и проверить решение.
Большинство систем, которые я видел, структурируют свои отчеты так, что все заявки сообщаются только как находящиеся в их последней очереди. В приведенном выше примере это означает, что при создании отчетов билет показывает, что операторский центр обработал заявку, но не персонал системы. Если бы можно было сообщить историю, по крайней мере, это показало бы, что системная группа отработала заявку.
Я также видел несколько действительно дрянных способов решения этой проблемы, когда каждый раз, когда билет перемещает очереди, пользователь должен создавать новый билет в этой новой очереди и ссылаться на оригинал. Эта ошибка не только связана с тем, что люди забывают, но и становится беспорядком, когда тикет должен быть отправлен назад, потому что что-то не было разрешено должным образом