Service Desk — быстрый старт. 3 часть. Создание единой точки входа
Если у вас в ИТ несколько инженеров, то наверняка вы сталкивались с ситуацией, когда пользователи звонят им напрямую. причем звонят именно Васе, т.к. Вася сделает все быстро, а не Пете, который в прошлый раз 2 часа возился и так толком все и не починил.
Такие звонки напрямую специалистам приводят к следующим негативным последствиям:
Инженеры, выполняя работу по звонку, часто не вносят информацию об обращении (особенно если устранение заняло не более 10 минут). Квалифицированные инженеры более нагружены/перегружены, т.к. пользователи хотят общаться только с ними.
Инженеры с меньшим опытом оказываются задвинуты, и получают опыт медленнее, чем могли бы. Если пользователь не дозванивается до инженера, то он докладывает своему руководству, что в ИТ никто не берет трубку. При этом не пытается связаться с другими инженерами.
В результате вы не видите реальную картину происходящего: какие идут обращения от пользователей, как нагружены ваши специалисты. Появляются «слепые пятна» из-за которых могут быть приняты неправильные управленческие решения.
Например: удаленный офис, там штатный инженер. Согласно статистике у него 1–2 заявки в неделю. Принимается решение вывести его на аутсорс. Человека сокращают. И тут выясняется, что он целыми днями только то и делал, что бегал между пользователями и постоянно что-то чинил и настраивал. Вот только отчитываться об этом забывал/ не успевал.
Еще один минус при звонке напрямую — человека может просто не быть на месте. Он в отпуске, на больничном. Пользователь звонит, звонит, а ему никто не отвечает.
В нашем случае в роли единой точки доступа выступает отдельный номер, который был озвучен всем пользователям и много раз. В отделе были кадровые перестановки, менялась инфраструктура, система хождения звонка по очередям, была заменена АТС. Но для пользователей всегда был один номер, по которому надо звонить в случае проблем с компьютером.
Так же был заведен единый обезличенный почтовый ящик, на который все пользователи должны отправлять обращения. Мы всячески акцентируем, что лучше будет, если пользователи будут писать, а не звонить. Нам проще работать с почтой: меньше полей заполнять в заявке, можно быстрее обрабатывать, корректнее рассчитываются сроки.
Исходя из вышенаписанного, при построении службы ServiceDesk единая точка входа нужна. Все обращения пользователей (не важно как поданные) в итоге должны оказываться в одном месте. Для каждого канала передачи информации точка должна быть только одна. Это значит если телефон — то только один телефонный номер. Если почта — то только один почтовый адрес. Если скайп, то только один общий аккаунт для приема обращений.
Дальше ИТ отдел уже сам настраивает маршрутизации звонков и хождения писем.
После того, как вы создали единую точку для обращений следующий шаг — создание единой базы всех заявок. Т.к. звонки на один номер и все обращения в одном почтовом ящике это хорошо, но с ними еще надо работать. Делать аналитику, искать проблемные места и т.д.
Вид базы не имеет особого значения. Это может быть файл Excel, база 1С, самописное решение. Но она должна соответствовать вашим задачам. Уметь хранить информацию в удобном виде, предоставлять требуемую отчетность.
Что обязательно должно быть в заявке:
— Номер заявки (ее уникальный идентификатор)
— Инициатор
— Дата обращения
— Контактная информация
— Критичность
— Сервис
Это тот минимум, который необходим для того, чтобы инженер мог начать работать по заявке. Далее он уже вписывает требуемые комментарии, запрашивает дополнительную информацию и в итоге закрывает заявку.
В нашей практике был случай, когда один из пользователей отправлял письма на абсолютно чужую почту другой компании и жаловался, что ИТ отдел его игнорирует. Не разобравшись, пользователь донес жалобу до высшего руководства, по итогам разбирательства с пользователем еще раз провели беседу, куда звонить и писать в случае проблем.
Подводя итог: единая точка входа поможет уменьшить количество проблем связанных с коммуникациями и позволит иметь более полную картину по обращениям. На базе этой информации можно будет уже принимать управленческие решения.
Комментарии (5)
5 октября 2016 в 21:57
0↑
↓
В дополнение к указанным каналам входа, у нас в компании рассматриваются к интеграции с Service Desk сообщения от мессенджеров: WhatsApp, Viber. Как ни странно, пользователи вышли с такой инициативой.5 октября 2016 в 22:16
0↑
↓
Я так же заметил общую тенденцию к телеграмму. Как минимум у одного сотового оператора и одного банка видел, что в техподдержку можно через телеграмм написать.
rd_nino
5 октября 2016 в 22:50
0↑
↓
Имхо, мессенджеры в качестве каналов подачи заявок не очень подходят.
Не представляю в мессенджере развёрнутую заявку по услуге или подробное описание инцидента.
Скорее это будет короткое сообщение типа «У меня не работает <сервис/оборудование>».
Поэтому времени на первичную обработку такой заявки потратится больше — нужно будет запрашивать у пользователя дополнительную информацию.
Fanta
5 октября 2016 в 23:03 (комментарий был изменён)
0↑
↓
В первых двух статьях>
дайте линки
5 октября 2016 в 23:18
0↑
↓
Первая часть — https://habrahabr.ru/post/294244/
Вторая часть — https://habrahabr.ru/post/295248/
