Пять лет назад в воздухе запахло революцией — социальная сеть Facebook изменила свой интерфейс, и пользователи моментально возненавидели его. До гильотины дело не дошло, потому что вскоре страсти улеглись и все забыли, каким был старый интерфейс и был ли он вообще. Год назад история повторилась в менее впечатляющих масштабах, но с менее благополучным сценарием — сменил свой облик портал «Кинопоиск», и волна отрицательной обратной связи оказалась настолько сильной, что она практически смыла новый интерфейс всего за двое суток.
Так пользователи реагируют на интерфейс приложений, которыми им хочешь, не хочешь, приходится пользоваться. А что делать нам, когда мы внедряем клиентское приложение для сервис-деска ради того, чтобы упростить жизнь себе и пользователям — и они его даже не замечают? Мы-то ожидаем, что получив в свои руки удобный интранет-сервис, пользователи забудут и контактный электронный адрес службы поддержки, и тем более дорогу на наш этаж. Но получается наоборот — когда у конечного пользователя появляется проблема, он в лучшем случае сразу пишет нам письмо, а в худшем — приходит в наш офис и начинает нависать над ближайшим свободным специалистом. Почему же это происходит?
Обычно те, кто внедряет программное обеспечение сервис-деска, не думают о том, как оно выглядит с точки зрения клиента, а если и получают обратную связь — то не у того, у кого надо. Не у конечного пользователя. Мы показываем результат своим коллегам и руководителями — и, разумеется, ни те, ни другие не представляют себе, что такое запрашивать поддержку, находясь в ситуации пользователя. Не то, чтобы им все равно — просто они слишком долго находятся по другую сторону баррикады.
Поэтому возьмите за правило привлекать конечных пользователей на этапе внедрения приложения для сервис-деска. Есть определенное противоречие в том, что приложение, предназначенное для обычных сотрудников компании, разрабатывают, а главное, тестируют «технари». Отзывы ваших коллег, ИТ-профессионалов, не помогут вам по одной простой причине — вы будете уверены, что всем нравится ваше приложение, а на поверку окажется, что понятие «все» не включает в себя самих пользователей, т.е. ваших клиентов. На самом деле современные пакеты программного обеспечения сервис-десков позволяют полностью настраивать портал конечного пользователя, вопрос в том, как именно это сделать.
Поэтому еще до внедрения приложения призовите на помощь добровольцев из бизнес-подразделений и постарайтесь собрать их непредвзятые мнения.
Во-первых, весьма возможно, что это заставит вас задуматься о тех особенностях интерфейса и функциональности вашего сервиса совершенно по-новому. Например, они подскажут вам, что «Напишите, в чем заключается техническая проблема» гораздо понятнее, чем «Введите текст инцидента», и вообще научат вас быть понятнее и дружественнее для вашей аудитории. Также они, возможно, предложат вам разработать вместо поля «Напишите…» форму с ниспадающим меню, в котором будут перечислены основные темы обращений, вроде «Не включается ноутбук» или «Не печатает принтер».
Во-вторых, посмотрев на ваши попытки сделать техническую базу знаний более доступной для пользователей, специалисты по продажам и маркетингу поделятся с вами опытом создания ресурсов, дружественных для клиентов — с картинками, скриншотами, GIF-последовательностями и короткими видео, а также с использованием счетчиков переходов, которые позволят вам определить, какие области вашего сервиса более популярны среди пользователей, а какие нуждаются в улучшении.
В-третьих, и это вам точно понравится, узнав ваше приложение получше, добровольцы станут вашими агентами влияния на стороне пользователей с момента запуска сервиса. Они с удовольствием поделятся с коллегами своими знаниями и будут пропагандировать новый способ обращения в сервис-деск куда успешнее, чем вы сами.
Мы видели две крайние стратегии автоматизации обслуживания пользователей сервис-десков — 100%-ная открытость службы технической поддержки и 100%-ный безальтернативный перевод всех сотрудников на «общение» с порталом самообслуживание. Не исключено, что оптимальной стратегией является «золотая середина» — а как поставили дело вы?
Пожалуй выскажусь.
Речь, как я понял, идет о возможности пользователей самостоятельно регистрировать инциденты. Если вы надеетесь, что это позволит вам избавиться от первой линии, то забудьте – не позволит. В любом случае вам понадобится человек, который сможет (обладает/обучен соответствующим технологиям) изьять из пользователя знания, достаточные для максимально точной классификации, категоризации и приоритезации события. Строить опросники, отвечая на которые пользователь сам все это сделает, безполезно. Во-первых, это не его, пользователя, работа и не для того он обратился в поддержку, чтобы отвечать на бесконечные(в его понимании) вопросы. Максимум, на что можно расчитывать – грубое определение области возникновения инцидента.
А вот по заявкам – доугое дело. Пользователь точно знает, что ему надо, и поэтому он в ссотоянии выбрать из того, что ему предлагется в каталоге. И на это у него есть время, поскольку в отличие от инцидента, работ не простаивает.