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

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

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

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

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

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

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

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

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

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

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

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

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

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