Если у вас в ИТ несколько инженеров, то наверняка вы сталкивались с ситуацией, когда пользователи звонят им напрямую. причем звонят именно Васе, т.к. Вася сделает все быстро, а не Пете, который в прошлый раз 2 часа возился и так толком все и не починил.
Такие звонки напрямую специалистам приводят к следующим негативным последствиям:
Инженеры, выполняя работу по звонку, часто не вносят информацию об обращении (особенно если устранение заняло не более 10 минут). Квалифицированные инженеры более нагружены/перегружены, т.к. пользователи хотят общаться только с ними.
Инженеры с меньшим опытом оказываются задвинуты, и получают опыт медленнее, чем могли бы. Если пользователь не дозванивается до инженера, то он докладывает своему руководству, что в ИТ никто не берет трубку. При этом не пытается связаться с другими инженерами.
В результате вы не видите реальную картину происходящего: какие идут обращения от пользователей, как нагружены ваши специалисты. Появляются “слепые пятна” из-за которых могут быть приняты неправильные управленческие решения.
Например: удаленный офис, там штатный инженер. Согласно статистике у него 1-2 заявки в неделю. Принимается решение вывести его на аутсорс. Человека сокращают. И тут выясняется, что он целыми днями только то и делал, что бегал между пользователями и постоянно что-то чинил и настраивал. Вот только отчитываться об этом забывал/ не успевал.
Еще один минус при звонке напрямую — человека может просто не быть на месте. Он в отпуске, на больничном. Пользователь звонит, звонит, а ему никто не отвечает.
В нашем случае в роли единой точки доступа выступает отдельный номер, который был озвучен всем пользователям и много раз. В отделе были кадровые перестановки, менялась инфраструктура, система хождения звонка по очередям, была заменена АТС. Но для пользователей всегда был один номер, по которому надо звонить в случае проблем с компьютером.
Так же был заведен единый обезличенный почтовый ящик, на который все пользователи должны отправлять обращения. Мы всячески акцентируем, что лучше будет, если пользователи будут писать, а не звонить. Нам проще работать с почтой: меньше полей заполнять в заявке, можно быстрее обрабатывать, корректнее рассчитываются сроки.
Исходя из вышенаписанного, при построении службы ServiceDesk единая точка входа нужна. Все обращения пользователей (не важно как поданные) в итоге должны оказываться в одном месте. Для каждого канала передачи информации точка должна быть только одна. Это значит если телефон — то только один телефонный номер. Если почта — то только один почтовый адрес. Если скайп, то только один общий аккаунт для приема обращений.
Дальше ИТ отдел уже сам настраивает маршрутизации звонков и хождения писем.
После того, как вы создали единую точку для обращений следующий шаг — создание единой базы всех заявок. Т.к. звонки на один номер и все обращения в одном почтовом ящике это хорошо, но с ними еще надо работать. Делать аналитику, искать проблемные места и т.д.
Вид базы не имеет особого значения. Это может быть файл Excel, база 1С, самописное решение. Но она должна соответствовать вашим задачам. Уметь хранить информацию в удобном виде, предоставлять требуемую отчетность.
Что обязательно должно быть в заявке:
— Номер заявки (ее уникальный идентификатор)
— Инициатор
— Дата обращения
— Контактная информация
— Критичность
— Сервис
Это тот минимум, который необходим для того, чтобы инженер мог начать работать по заявке. Далее он уже вписывает требуемые комментарии, запрашивает дополнительную информацию и в итоге закрывает заявку.
В нашей практике был случай, когда один из пользователей отправлял письма на абсолютно чужую почту другой компании и жаловался, что ИТ отдел его игнорирует. Не разобравшись, пользователь донес жалобу до высшего руководства, по итогам разбирательства с пользователем еще раз провели беседу, куда звонить и писать в случае проблем.
Подводя итог: единая точка входа поможет уменьшить количество проблем связанных с коммуникациями и позволит иметь более полную картину по обращениям. На базе этой информации можно будет уже принимать управленческие решения.
Комментарии (18)
rd_nino
05.10.2016 22:50Имхо, мессенджеры в качестве каналов подачи заявок не очень подходят.
Не представляю в мессенджере развёрнутую заявку по услуге или подробное описание инцидента.
Скорее это будет короткое сообщение типа «У меня не работает <сервис/оборудование>».
Поэтому времени на первичную обработку такой заявки потратится больше — нужно будет запрашивать у пользователя дополнительную информацию.
orlovpyotr
06.10.2016 09:16Тоже так думал. Но попробовал в этом качестве телеграм. И выяснилось следующее:
— есть протокол переписки у обеих сторон (а в силу некомпетентности поддержка часто врет)
— можно отправить фотку или скриншот
— если сильно в лом — можно отправить войс
— нет тупого ожидания в виде «нажмите то, это, слушайте Шуберта 15 минут» — отправил запрос, и по мере готовности общаешься.
В общем — понравилось.
chieftain_yu
06.10.2016 15:10Гм.
Первые три пункта (ну правда — войс придется сперва писать в файл самолично, хотя, может, и можно синтегрировать АТС) вполне делаются кучей софта — хоть Омнитрекером, хоть HP SM, хоть многими иными специализированными поделками.
Но в отличие от — непосредственно в телеграме хрен посчитаешь соблюдение SLA, да и статистику не соберешь.
Плюс это — в грамотно организованной поддержке для широких народных масс есть таки первая линия (диспетчеры), которая сортирует запросы на профильных спецов. С кем предполагается списываться в телеграме? С диспетчерами или с самими инженерами?orlovpyotr
06.10.2016 15:17Я был пользователем ))
chieftain_yu
06.10.2016 15:25А, ну да, тогда вам, конечно, может быть и удобным. :)
Но это плохо ложится на ITSM без интеграции телеграма и трекера хоть в какой-то форме.
pan_KOST
06.10.2016 15:29Кстати, некоторые ServiceDesk системы уже имеют интеграцию с Телеграмом
Пример — Telegram Connect for Zendesk
chieftain_yu
06.10.2016 15:32Любопытно, не знал.
А оно предполагает, что в одном диалоге идет общение ровно по одному обращению?
Sergey-S-Kovalev
06.10.2016 08:46| Вид базы не имеет особого значения. Это может быть файл Excel, база 1С, самописное решение.
Имеет огромное значение. Плохой, тормозной, не оптимизированный и не удобный инструмент будет отбивать желание в нем работать. Это напрямую влияет на внедряемость и используемость, а на выходе на эффективность. А еще должна быть неизменяемость истории выполнения заявки, т.е. в идеале сервисдеск должен быть сторонним относительно ИТ отдела продуктом, в котором собственные ИТ специалисты не должны мочь внести изменения на уровне базы данных.
| Что обязательно должно быть в заявке:
| — Номер заявки (ее уникальный идентификатор)
| — Инициатор
| — Дата обращения
| — Контактная информация
| — Критичность
| — Сервис
— Номер должен выдаваться автоматически,
— с инициатором понятно все,
— помимо даты обязательно нужно и время, — иногда счет идет на минуты.
— контакты должны подхватываться из AD/учетной системы/откуда то еще, — например смена пароля производится по заявке, а новый пароль отправляется сотруднику по СМС. и только пароль прописанный в учетной системе или АД является доверенным.
— критичность пользователь зачастую определить самостоятельно не в силах, для него все срочно и важно. пункт вообще не обязателен.
— Сервис? Это описание проблемы? А если у пользователя ексель падает при запуске, это какой сервис?
| В нашей практике был случай, когда один из пользователей отправлял письма на абсолютно чужую почту.
Что ж у вас за сервисдеск, если пользователю автоматически не приходит письмо о регистрации заявки с назначенным номером? =) ну либо пользователь легендарно туп.
| с пользователем еще раз провели беседу
вы странно внедряете сервисдески, обычно в рамках проекта (ну или без него) делается приказ о том, что все запросы идут через портал/почту и в случае их недоступности по звонку (главный смысл приказа — не было заявки, не было проблемы). У пользователей размещается ярлык на портал на рабочем столе, а так же через банальный bginfo изменяется картинка рабочего стола, где прописываются контакты техподдержки и базовые свойства ПК. Никому ничего после такого объяснять не нужно.
Про мессенджеры добавлю, что можно, но крайне не желательно, если нет интеграции с сервисдеском. В идеале пользователь не должен знать, кто решал его проблему. Отправил заявку написав все что знает, получил через некоторое время ответ, что все починено. Нежелательно, потому что в рамках выполнения заявки вся переписка и взаимодействие с пользователем должна протоколироваться и сохраняться в одном месте.
victor_2004
06.10.2016 09:56Имеет огромное значение. Плохой, тормозной, не оптимизированный и не удобный инструмент будет отбивать желание в нем работать. Это напрямую влияет на внедряемость и используемость, а на выходе на эффективность.
Как я писал — вид не имеет никакого значения. Важен именно функционал.Вы можете в экселевских табличках в связке с аутлуком так все настроить, что внедрение на ура пройдет. И наоборот — в специализированном решении такого наваять, что все плеваться будут.
А еще должна быть неизменяемость истории выполнения заявки, т.е. в идеале сервисдеск должен быть сторонним относительно ИТ отдела продуктом, в котором собственные ИТ специалисты не должны мочь внести изменения на уровне базы данных.
Согласен. В нашем случае неизменяемость есть для операторов. Системный администратор теоретически может залезть в базу и прямым запросом внести изменения, но мне сложно представить ситуацию когда он это сделает без прямого указания вышестоящего руководства.
— контакты должны подхватываться из AD/учетной системы/откуда то еще, — например смена пароля производится по заявке, а новый пароль отправляется сотруднику по СМС. и только пароль прописанный в учетной системе или АД является доверенным.
Не обязательно. Это зависит уже от конкретной компании и от того как в ней организованы процессы и на сколько высок уровень автоматизации. Статья предназначена для тех кто собирается внедрять сервисдеск. А если он в компании только внедряется, то вполне может быть, что нет даже домена.
— критичность пользователь зачастую определить самостоятельно не в силах, для него все срочно и важно. пункт вообще не обязателен.
Так и не пользователь ее определяет. А специалист техподдержки при первичном анализе. Это важно, чтобы правильно сортировать заявки. У нас критичность определялась по двум параметрам — блокирует ли проблема его работу и к какому отделу он относится (ряд отделов имеет более высокий приоритет обслуживания, т.к. они напрямую влияют на прибыль компании).
— Сервис? Это описание проблемы? А если у пользователя ексель падает при запуске, это какой сервис?
Об этом я достаточно подробно писал здесь. Описанный вами случай попадает под категорию «Поддержка прикладного ПО» нашего текущего каталога услуг.
Что ж у вас за сервисдеск, если пользователю автоматически не приходит письмо о регистрации заявки с назначенным номером? =)
Вы не поверите, но приходит. И от тех ребят тоже пришло. Но они просто забили на это обращение. А пользователь не разобрался, что это чужой отбойник.
ну либо пользователь легендарно туп.
Пользователь это клиент. Если клиент что-то не понимает, то значит мы где-то не доработали. Просто надо находить к каждому клиенту подход.
вы странно внедряете сервисдески, обычно в рамках проекта (ну или без него) делается приказ о том, что все запросы идут через портал/почту и в случае их недоступности по звонку (главный смысл приказа — не было заявки, не было проблемы).
Приказ есть. Более того при приеме на работу каждый подписывается, что он с ним ознакомлен. Однако это не мешает пользователю транслировать на высшее руководство, что ИТ опять косячит, опять меня игнорирует, мы звоним-звоним, никто трубку не берет.
Поднимаем логи, записи разговоров — за весь день был только один звонок, оператор его обработал и полностью устранил проблему.
Вроде мы и ни при чем, однако осадок остался.
У пользователей размещается ярлык на портал на рабочем столе, а так же через банальный bginfo изменяется картинка рабочего стола, где прописываются контакты техподдержки и базовые свойства ПК. Никому ничего после такого объяснять не нужно.
Заставить людей писать через портал — весьма сложно. Ярлыки тут мало помогают. Им всегда проще позвонить. Максимум — написать письмо.
Интересная мысль про bginfo. Может сделаем внедрение.
Объяснять нужно всегда, без этого никак :)
Про мессенджеры добавлю, что можно, но крайне не желательно, если нет интеграции с сервисдеском.
Согласен. однако надо помнить — смартфоны есть далеко не у всех. В нашем случае мы много работает с регионами, там у девочек часто просто звонилки.
В идеале пользователь не должен знать, кто решал его проблему. Отправил заявку написав все что знает, получил через некоторое время ответ, что все починено. Нежелательно, потому что в рамках выполнения заявки вся переписка и взаимодействие с пользователем должна протоколироваться и сохраняться в одном месте.
Важное требование нашего руководства (именно руководства фирмы, а не ИТ) — пользователь обязан знать кто решает его проблему. Какой конкретный человек. ФИО и как с ним связаться.
У нас пользователь крайне редко может дать нормальную исчерпывающую информацию по проблеме. Поэтому в половине случаев специалист связывается с пользователем для уточнения деталей.
И у нас именно пользователь должен подтвердить, что проблема устранена. Только после этого закрывается заявка.
Классика жанра — письмо от бухгалтера. Тема письма «сканер». Тело пустое. В итоге выяснили, что в МФУ закончился тонер, надо поменять.
Нежелательно, потому что в рамках выполнения заявки вся переписка и взаимодействие с пользователем должна протоколироваться и сохраняться в одном месте.
В нашем случае система позволяет вести всю переписку через нее. Поэтому в заявке сохраняется вся история.Sergey-S-Kovalev
06.10.2016 10:58| в экселевских табличках в связке с аутлуком так все настроить, что внедрение на ура пройдет.
Не сможете. Не маштабируется, введение новых хотелок будет вызывать ад. А со временем запросы от руководства будут только расти.
| Пользователь это клиент. Если клиент что-то не понимает, то значит мы где-то не доработали. Просто надо находить к каждому клиенту подход.
Расскажите мне про это когда количество обслуживаемых вами пользователей через один портал перейдет, скажем, за 3 тысячи :)
| Заставить людей писать через портал — весьма сложно. Ярлыки тут мало помогают. Им всегда проще позвонить. Максимум — написать письмо.
Да, портал используется в значительно реже чем почта, но куда чаще чем звонки.
У нас нет диспетчера :) все разгуливает в 80%+ случаев система сортировки заявок, ошибки и потеряшки обрабатываются руководителями групп по направлениям.
А вот звонить нам не проще. Как только идет разговор про задачу не связанную с поломкой сети или почты, спецы заворачивают разговор в контекст отправки заявки в сервисдеск почтой или через портал. Формулировка проста — работы много, вот вы мне сейчас рассказываете, а через секунду другой звонок и я забуду чего там у вас, задача потеряется и мне за это ничего не будет.
Портал используют для специфических вещей: создание учетных записей — обязательные поля для заполнения и заявки только от кадровиков, учетные системы — используемые модули, версии и своя специфика, мониторинг транспорта — номера, марки машин, каталог неисправностей.
Все остальное почтой.
| И у нас именно пользователь должен подтвердить, что проблема устранена. Только после этого закрывается заявка.
У нас просто смотрятся возвраты в обработку. В закрывающем письме сказано, что если что то не так, нажмите ответить и письмо вернет заявку в работу. Соответственно на заявке тикает счетчик и падает в отчет. Ну а дальше просто разбор, почему счетчик тикнул. Это удобнее, потому что пользователь часто отправляет заявку и забивает даже на проверку исполнения. А гоняться за ним, что бы получить подтверждение это потеря времени специалиста.
| Классика жанра — письмо от бухгалтера. Тема письма «сканер». Тело пустое. В итоге выяснили, что в МФУ закончился тонер, надо поменять.
Если заявок много — то просто ответ на это письмо: А что с ним не так?
Если мало, то специалист может и позвонить и непосредственно выяснить что не так. У нас в требованиях указано что пользователь должен подробно описать проблему. Насколько хватит ума, знаний, понимания, но расписать должен. Те кто поумнее понимают, что подробно расписанная проблема решается быстрее.pan_KOST
06.10.2016 11:57Не сможете. Не маштабируется, введение новых хотелок будет вызывать ад. А со временем запросы от руководства будут только расти.
Полностью поддерживаю. Мы, в своё время по этой же причине изначально выбрали веб-решение ( Zendesk). Пускай и относительно кривое
Расскажите мне про это когда количество обслуживаемых вами пользователей через один портал перейдет, скажем, за 3 тысячи :)
Из своего опыта знаю, что уже 300 территориально распределённых сотрудников приведёт к обезличиванию
Все остальное почтой.
Почтовые заявки, кстати, в относительной степени и с определённым видом модерации реально обрабатывать сразу через ServiceDesk-систему, а если в компании что то типа Lotus Notes или есть возможность внедрить в почтовый клиент хотя бы частично формализованные заявки, то почтовый канал станет основным
Им всегда проще позвонить. Максимум — написать письмо.
Всё зависит от компании — в некоторых может быть ровно наоборот.
По поводу звонков — моё предложение — делать скрипты для операторов/диспетчеров — чтобы они во время звонка заводили заявки и выяснил всю необходимую информацию.
Если такой должности нет, то её стоит ввести — т.е. единый номер телефона для приёма заявок оператором. Немного пострадает клиентоориентированность, но на порядок снизится нагрузка на более квалифицированных сотрудников.
| И у нас именно пользователь должен подтвердить, что проблема устранена. Только после этого закрывается заявка.
Мы, со своей стороны, следуем такой схеме закрытия заявки в её жизненном цикле:
- Выполнена (Solved) — изменяется статус и инженер ТП описывает решение заявки в том или ином виде. После этого отправляется предложение оценки решения автору заявки ( даже если за него её завёл диспетчер). Из этого состояния заявка может быть переоткрыта (reopen).
- Закрыта (Closed) — пользователь оценил решение или автоматически через 2 недели при отсутствии реакции пользователя. Состояние финальное и переоткрытию не подлежит
У нас в требованиях указано что пользователь должен подробно описать проблему
Но не все эти требования выполняют.
Из своего опыта — наши сотрудники уточняют у автора заявки — что он имел ввиду ( если нет пометки «срочно» или это не VIP-клиент) в письменном виде и ждут уточнения ( SLA считается только тогда, когда заявка на стороне поддержки). Пользователей тоже надо учить правильно пользоваться сервисами.chieftain_yu
06.10.2016 15:23SLA считается только тогда, когда заявка на стороне поддержки
Как я вам завидую… Ну то есть завидовал бы пару месяцев назад…
- Выполнена (Solved) — изменяется статус и инженер ТП описывает решение заявки в том или ином виде. После этого отправляется предложение оценки решения автору заявки ( даже если за него её завёл диспетчер). Из этого состояния заявка может быть переоткрыта (reopen).
chieftain_yu
06.10.2016 15:20И у нас именно пользователь должен подтвердить, что проблема устранена. Только после этого закрывается заявка.
Хм.
Пользователь написал обращение «недоступен сервер Server».
Диспетчер порождает из обращения инцидент, инцидент уходит инженерам.
Сервер подняли, инцидент пометили выполненным.
Я так понимаю — обращение получило статус «Выполнено» — и пользователю ушло сообщение, дескать, мы тут считаем, что все хорошо — подтвердите, мы переведем обращение в «Закрыто».
А пользователь этот через 10 минут после обращения покинул компанию в связи с увольнением. И этот незакрытый инцидент будет висеть всю оставшуюся жизнь трекера, пока тепловая смерть вселенной не придет, и портить показатели ИТшников?
Обычно закрытие обращений делается автоматически, если пользователь в течение энного времени (например, 40 рабочих часов) не вернул его в доработку.
Или у вас не так?
AstorS1
В дополнение к указанным каналам входа, у нас в компании рассматриваются к интеграции с Service Desk сообщения от мессенджеров: WhatsApp, Viber. Как ни странно, пользователи вышли с такой инициативой.
victor_2004
Я так же заметил общую тенденцию к телеграмму. Как минимум у одного сотового оператора и одного банка видел, что в техподдержку можно через телеграмм написать.