Service Desk — быстрый старт. 3 часть. Создание единой точки входа

Я так же заметил общую тенденцию к телеграмму. Как минимум у одного сотового оператора и одного банка видел, что в техподдержку можно через телеграмм написать.

Тоже так думал. Но попробовал в этом качестве телеграм. И выяснилось следующее:
— есть протокол переписки у обеих сторон (а в силу некомпетентности поддержка часто врет)
— можно отправить фотку или скриншот
— если сильно в лом — можно отправить войс
— нет тупого ожидания в виде «нажмите то, это, слушайте Шуберта 15 минут» — отправил запрос, и по мере готовности общаешься.

В общем — понравилось.

Первая часть
Вторая часть

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

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

А еще должна быть неизменяемость истории выполнения заявки, т.е. в идеале сервисдеск должен быть сторонним относительно ИТ отдела продуктом, в котором собственные ИТ специалисты не должны мочь внести изменения на уровне базы данных.

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

— контакты должны подхватываться из AD/учетной системы/откуда то еще, — например смена пароля производится по заявке, а новый пароль отправляется сотруднику по СМС. и только пароль прописанный в учетной системе или АД является доверенным.

Не обязательно. Это зависит уже от конкретной компании и от того как в ней организованы процессы и на сколько высок уровень автоматизации. Статья предназначена для тех кто собирается внедрять сервисдеск. А если он в компании только внедряется, то вполне может быть, что нет даже домена.

— критичность пользователь зачастую определить самостоятельно не в силах, для него все срочно и важно. пункт вообще не обязателен.

Так и не пользователь ее определяет. А специалист техподдержки при первичном анализе. Это важно, чтобы правильно сортировать заявки. У нас критичность определялась по двум параметрам — блокирует ли проблема его работу и к какому отделу он относится (ряд отделов имеет более высокий приоритет обслуживания, т.к. они напрямую влияют на прибыль компании).

— Сервис? Это описание проблемы? А если у пользователя ексель падает при запуске, это какой сервис?

Об этом я достаточно подробно писал здесь. Описанный вами случай попадает под категорию «Поддержка прикладного ПО» нашего текущего каталога услуг.

Что ж у вас за сервисдеск, если пользователю автоматически не приходит письмо о регистрации заявки с назначенным номером? =)

Вы не поверите, но приходит. И от тех ребят тоже пришло. Но они просто забили на это обращение. А пользователь не разобрался, что это чужой отбойник.

ну либо пользователь легендарно туп.

Пользователь это клиент. Если клиент что-то не понимает, то значит мы где-то не доработали. Просто надо находить к каждому клиенту подход.

вы странно внедряете сервисдески, обычно в рамках проекта (ну или без него) делается приказ о том, что все запросы идут через портал/почту и в случае их недоступности по звонку (главный смысл приказа — не было заявки, не было проблемы).

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

Поднимаем логи, записи разговоров — за весь день был только один звонок, оператор его обработал и полностью устранил проблему.

Вроде мы и ни при чем, однако осадок остался.

У пользователей размещается ярлык на портал на рабочем столе, а так же через банальный bginfo изменяется картинка рабочего стола, где прописываются контакты техподдержки и базовые свойства ПК. Никому ничего после такого объяснять не нужно.

Заставить людей писать через портал — весьма сложно. Ярлыки тут мало помогают. Им всегда проще позвонить. Максимум — написать письмо.
Интересная мысль про bginfo. Может сделаем внедрение.
Объяснять нужно всегда, без этого никак :)

Про мессенджеры добавлю, что можно, но крайне не желательно, если нет интеграции с сервисдеском.

Согласен. однако надо помнить — смартфоны есть далеко не у всех. В нашем случае мы много работает с регионами, там у девочек часто просто звонилки.

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

Важное требование нашего руководства (именно руководства фирмы, а не ИТ) — пользователь обязан знать кто решает его проблему. Какой конкретный человек. ФИО и как с ним связаться.
У нас пользователь крайне редко может дать нормальную исчерпывающую информацию по проблеме. Поэтому в половине случаев специалист связывается с пользователем для уточнения деталей.
И у нас именно пользователь должен подтвердить, что проблема устранена. Только после этого закрывается заявка.

Классика жанра — письмо от бухгалтера. Тема письма «сканер». Тело пустое. В итоге выяснили, что в МФУ закончился тонер, надо поменять.

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

В нашем случае система позволяет вести всю переписку через нее. Поэтому в заявке сохраняется вся история.