Service Desk *

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

В данной статье не будут рассматриваться вопросы управления коллективом, развертывания системы администрирования обращений и детали работы начальников отделов поддержки. Статья скорее является своеобразным введением в проблематику «поддержки IT продуктов»

На календаре май, а значит – «серая зона» праздников. Каждый, у кого выходил из строя сервис в праздники, знает, что такое две недели, в которых выходных больше, чем рабочих дней. По такому случаю рассказываем, как устроена наша техподдержка и что происходит с заявками, пришедшими в ночь с субботы на воскресенье. В конце статьи – небольшой чек-лист по составлению запроса в техподдержку. Чтобы на том конце провода вас правильно поняли и быстро смогли помочь.

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

— Доброе утро, это техподдержка Parallels. Могу я поговорить с Джо?
— Он умер! Не звоните сюда больше!

Так ранним воскресным утром началась моя очередная рабочая смена. Вообще люди часто обращаются к специалистам технической поддержки на эмоциональном взводе, готовые кричать и проклинать всех и вся. С одной стороны их можно понять, ведь если ты не справился с возникшей ситуацией сам, значит проблема действительно нерешаемая, срочная и важная. С другой стороны, представьте, что среднее время на обработку каждого обращения сотрудником контактного центра составляет около пяти минут. Рабочая смена консультанта длится по восемь часов. Итого: около девяти десятков эмоциональных диалогов в день. Конечно, не все они наполнены проклятиями, но шансы велики. Под катом несколько лайфхаков и историй из жизни. Надеюсь, кому-то из вас мои мысли помогут справиться со стрессом на работе, особенно сейчас, весной, когда количество странных обращений традиционно растет.

Традиционно именно специалисты службы клиентской поддержки обеспечивают взаимодействие разработчиков и игроков. Они официально общаются с пользователями от лица компании и оказывают им квалифицированную помощь: отвечают на вопросы, разъясняют правила, тонкости игровых процессов и предоставляют техническую поддержку в различных ситуациях.

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

• это наша первая линия технической поддержки. Дежурные следят за стеной мониторинга, общаются с клиентами, которые приходят в наши дата-центры, помогают устанавливать новое оборудование. Их четкая работа, доброжелательное отношение к клиентам, внимание к мелочам значат для нашего сервиса не меньше, чем работа инфраструктуры дата-центра: превысил время ответа на запрос, позволил пройти в дата-центр без бахил, просто не поздоровался – минус в нашу карму.
  
  
• это наша “кузница кадров”. Некоторые ребята потом вырастают до ведущих инженеров профильных технических групп и даже до руководителей отделов.

Но обо всем по порядку.

О технической поддержке написано много статей. Пишут все: пользователи, инженеры, тимлидеры, директора и даже владельцы бизнеса. Мне, как инженеру технической поддержки в прошлом и старшему инженеру Social Media Support в Parallels в настоящем, тоже есть чем поделиться.

«В старом мире, мы тратили 30% нашего времени на создание хорошего сервиса и 70% времени на то, чтобы рассказать о нём. В современном мире всё наоборот» — Джефф Безос, CEO, Amazon

“Это самый ужасный сервис на свете! Верните мне мои деньги немедленно!” — каждый инженер техподдержки хотя бы раз, но слышал такое от пользователя. Да что и говорить, чаще всего высказываются самые недовольные: “Я 27 минут висел на телефоне", “Мою проблему не могут решить уже четвертый день!”. Те, кто никогда не работал в саппорте судят о качестве предоставляемого сервиса по своему личному опыту. А как о нем судим мы, те, кто отвечает на звонки и решает проблемы? Как определить, хороший ли сервис вы предоставляете своим пользователям?

С чего начинается любой проект по ИТ-инфраструктуре? Если вы подумали о чем-то вроде: админы собрались, обсудили и кто-то предложил решение, — то с высокой вероятностью попали в точку. Именно так обстоят дела с эксплуатацией в российских компаниях, и у нас до недавнего времени тоже.

В статье расскажу о том, как мы потратили 5 миллионов и почти полгода на то, чтобы убедиться: отличных специалистов и энтузиазма недостаточно для внедрения чего-либо масштабного.

Клиенты всё меньше используют традиционные инструменты для связи с компаниями: телефон, почту, личные встречи. Все общение постепенно переходит в онлайн. В социальных сетях и мессенджерах клиенты читают новости, находят и покупают товары, общаются, работают — и если у них появляются вопросы, они пытаются задать их там же. Но!

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


Когда все клиенты решили что-то спросить

У бизнеса остаётся два выхода: нанять больше сотрудников, которые будут ежеминутно мониторить все цифровые каналы, либо объединить их и автоматизировать процесс общения с клиентами через социальные сети, онлайн-чаты и мессенджеры — в Открытых линиях Битрикс24.

Пришло время рассказать о том, как в нашей компании следят за соблюдением SLA (Service Level Agreement — в широком понимании, это соглашение на предоставление технической поддержки, включающее время реагирования на запрос) в обращениях клиентов за технической поддержкой, какие инструменты созданы для его соблюдения и какое место этот параметр занял в нашей системе приоритезации обращений описанной в моей предыдущей статье «Ваш звонок очень важен для нас? Или как работает система приоритизации заявок в сервисных подразделениях».

Кому-то материал покажется тривиальным, особенно профессионалам из крупных колл-центров, но для специалистов небольших и средних организаций, где процессы предоставления сервиса только начинают «созревать», материал будет полезен.

Представляю очередной перевод статьи. Сегодня это короткая рекламная статья из блога компании Optanix. «Why You Need to Manage Services, Not Just Infrastructure», автор: Kishore Ramamurthy.

Зачем Вам тратить свое время на очередную рекламу? Не спешите делать выводы. На мой взгляд, статья интересна, т.к. дает доходчивый пример описания ценности сервисного подхода к управлению ИТ. Ее можно брать как шаблон для обоснования полезности CMDB и сервисно-ресурсных моделей своему руководству, как от ИТ, так не от ИТ.

Интересно? Прошу под кат. Не согласны? Прошу оставлять комментарии. Не только не согласны, но и хотите понизить рейтинг публикации? Тем более прошу оставлять комментарии.

Здесь и далее курсивом, комментарии переводчика.

При рассмотрении статьи, посвященной системе приоритезации обращений в техническую службу АО «Инфовотч», может возникнуть логичный вопрос: каким образом проводился расчет весовых коэффициентов? «Уложить» алгоритм расчета в комментарий к статье с учетом его объема будет, мягко говоря, трудновато. Поэтому, предвидя подобные вопросы, мы решили дополнить предыдущую статью поэтапным рассмотрением алгоритмов расчета данных весовых коэффициентов.

Как было понятно из прошлой статьи “Четыре порока обслуживания”, мы активно внедряем ITSM подходы в нашей компании. Сегодня хотелось бы поговорить о том, с чего обычно начинается внедрение ITSM в компании — о каталоге услуг.

Выделение услуг оказалось не совсем простой задачей и мы столкнулись с массой сложностей:

• Можно принимать за ИТ-услугу программный комплекс или нет?
• Как выделить единого ответственного, если услуга составная и поддерживается двумя программными комплексами?
• Как определять по какой услуге зарегистрировать инцидент, если рухнула ИТ-инфраструктура в целом и почти все услуги не предоставляются.

Вот каких принципов мы придерживаемся при выделении любой услуги:

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

Представляю перевод статьи Стюарта Рейнса «Прошлое и будущее Управления ИТ Услугами» («The Past and Future of IT Service Management» by Stuart Rance), опубликованную в блоге ITSM.Tools.

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

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

Практика

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

1. Настройка синхронизации с AD и способов аутентификации

Настройки системы сконцентрированы во вкладке «настройки». Нас интересует пункт «Аутентификация – каталоги LDAP». На данный момент работа с системой предусмотрена исключительно из внутренней сети компании. Практически все произведенные настройки можно сразу проверить, используя вкладку «тест».

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

2. Настройка приёмников

Теперь нам стоит добавить ящик для приема заявок пользователей. Создаем электронную почту вида help@mycompamy.com и ищем вкладку «приёмники» в настройках. Добавляем новую почту, указываем сервер и настройки соединения. Во вкладке действия нам будет доступна кнопка «получить заявки сейчас» – актуально если зависло задание в crontask-e.

В силу специфики, при разработке облачного сервиса учета клиентских заявок — Okdesk, мы регулярно общаемся с сотнями различных сервисных компаний по всей территории нашей необъятной Родины. И, признаемся, получаем интересную пищу для размышлений.

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

Теперь, если в вашей компании появится вредитель, жаждущий перемен, вы сможете легко поставить новатора на место.

Мы решили поделиться опытом от внедрения этой непростой методологии внутри нашей компании и планируем написать ряд статей о том, как внедряем ITSM, какие сложности преодолеваем, и какие решения у нас есть. Надеемся, что статьи будут интересны IT-менеджменту.