Какие функции вы хотели бы видеть в продукте службы поддержки? [закрыто]

Этот вопрос для профессиональных системных администраторов и тех, кто поддерживает десктопы. Извините, разработчики ... вы можете поговорить об отслеживании ошибок в Stack Overflow.

Какой тип функций или функций вы хотели бы или хотели бы иметь в своей справочной службе или в программном обеспечении для устранения неполадок?

В некоторых областях могут быть отчеты, интеграция с инвентаризацией оборудования / программного обеспечения, интеграция с Active Directory / LDAP, автоматическое закрытие заявок от определенных пользователей.

Интеграция с электронной почтой. Без этого я никак не могу иметь дело с продуктом службы поддержки. Важно, чтобы клиенты и сотрудники могли общаться по электронной почте.

• Интеграция Office Communicator / IM
• Свободная / занятая интеграция («Я свяжусь с Джейн по поводу ее проблемы - о, нет смысла, я вижу, что она на встрече / по вызову / в отпуске»)
• Порталы самообслуживания пользователей («Я хочу изменить свой номер ячейки в GAL, пожалуйста!»)
• Пользовательские практические порталы («как добавить принтер?» Или «как настроить моего помощника вне офиса?»)
• Запросы (не проблемы - другими словами «эй, я бы хотел новый ноутбук и т. Д.»)
• Разрешения супервизора (для запросов «Да, я одобряю Джейн ли новый ноутбук»)
• База знаний (для сотрудников уровня 1/2), генерируемая внутри и автоматически («Если вы видите Необычное-Проблема X, решение - Лукавое Обходное решение Y»)
• Некоторая интеграция вики / sharepoint

Интеграция задач проекта и обслуживания

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

Итак, «Справочная служба Джо» просматривает единый портал управления работой, который показывает 8 элементов поддержки пользователей, 2 элемента для проекта Windows 7 и 5 вещей, которые он делает каждый день для резервного копирования. И «Администратор сервера Jill» просматривает тот же портал, на котором показаны ее 12 элементов для проекта Windows 7, 4 ежедневных задачи обслуживания сервера и 2 элемента поддержки пользователей, выделенных Джо. «Джефф Менеджер» смотрит на портал и видит его задачи, а также может посмотреть, регулярно ли выполняются задачи обслуживания и как продвигаются проекты.

Любые рекомендации?

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

• ITIL Complaince (по крайней мере, управление инцидентами / проблемами / изменениями, конечно, на основе CMDB)
• Модуль SLM (много метрик)
• Сетевой модуль самообслуживания (открывать и отслеживать ваши билеты)
• API интеграции (который позволяет интегрироваться с инструментами мониторинга, электронной почтой, смс и т. Д.)
• Интеграция LDAP (активный каталог или истинные решения ldap)
• Билетный шаблон
• Гибкий модуль отчетности
• База знаний

• Интеграция CallerID
• Клиент чата
• Введите поиск впереди

Возможность генерировать отчеты на основе истории тикета

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

Большинство систем, которые я видел, структурируют свои отчеты так, что о всех билетах сообщается только в их последней очереди. Из приведенного выше примера это означает, что при запуске отчетов тикет показывает, что колл-центр обработал тикет, но не персонал системы. Если бы кто-то мог сообщить историю, по крайней мере, это показало бы, что группа систем работала над заявкой.

Я также видел некоторые действительно дурацкие обходные пути для этой проблемы, когда каждый раз, когда билет перемещает очереди, пользователь должен создать новый билет в этой новой очереди и ссылаться на оригинал. Эта ошибка не только подвержена ошибкам, потому что люди забывают, но и становится беспорядком, когда билет должен быть отправлен назад, потому что что-то не решено должным образом