Всем привет! Меня зовут Алексей Волков.
Вместе с моим коллегой разработчиком Александром Соловьевым ( такжев ), мы делаем внутренние веб-сервисы в DataLine. Этой осенью мы запустили нашу службу поддержки, которая заменит BMC Remedy. В этом посте я расскажу, почему мы отказались от готового решения и сделали все сами.
В среднем через службу поддержки в день обрабатывается 450 запросов.
Что нам не понравилось в Remedy?
Я начал работать с Remedy практически сразу после того, как попал в DataLine. После неоднократных попыток настроить его под свои цели, мы решили сделать свою службу поддержки.Вот не такой уж и краткий список причин, по которым мы решили отказаться от системы запросов на устранение последствий BMC: Неудобный интерфейс.
Чтобы зарегистрировать заявку, обработать ее и отметить одобрением, потребовалось 100 500 кликов.
Страница инцидента.
Взять, к примеру, поля для содержания сообщения, которое нужно было открыть в специальном окне.
Целый каскад вкладок нужно открыть, чтобы написать решение или перенаправить инцидент другому исполнителю.
Интеграция с другими клиентскими интерфейсами и любыми модификациями тоже были танцы с бубном.
Программное обеспечение было фирменным, места для маневра почти не было.
Единственной лазейкой были веб-сервисы, которые могли общаться с Remedy, но они были очень капризны и нестабильны.
Некоторые вещи мы делали полностью вручную и коряво: помню, как мы настроили выгрузку отчетов об инцидентах с помощью селекторов из базы данных.
Конечно, был и другой путь: нанять подрядчика и выполнять любой свой каприз.
На тот момент на рынке этого программного обеспечения был только один подрядчик, и он об этом знал.
Производственные процессы корректируются, и улучшения будут необходимы постоянно.
С учетом этого ценник оказался негуманным и стартовал с 5 миллионов.
Лицензий не хватило.
В какой-то момент на заре существования DataLine мы купили 100 лицензий.
С тех пор компания сильно выросла.
Лицензии конкурировали.
Все чаще возникали ситуации, когда инженеру приходилось ждать выдачи лицензии, чтобы приступить к своей работе.
Собственно, это было последней каплей.
Фиксация всех действий, связанных с происшествием .
Мы хотели, чтобы все, что касается технической поддержки наших клиентов, было отражено в службе поддержки.
Remedy фактически только регистрирует запросы.
Вся реальная работа по инциденту велась в почтовой переписке, по телефону, в курилке — где угодно, только не в Remedy. Особенно, если это была сложная заявка и в ней участвовали специалисты нескольких отделов.
Проблема была решена, но в Remedy от нее не осталось и следа.
В результате инцидент документировался фрагментами, а иногда и вовсе не отображался в Remedy. Было очень сложно что-либо контролировать, понимать и анализировать.
Служба поддержки 2.0
Средства защиты было легко заменить.Основная задача новой службы поддержки — собрать всю деятельность техподдержки в «одном окне»: контакты, рабочую переписку, документы.
Мы хотели получить своеобразное логирование всего, что происходит после того, как клиент отправляет запрос в нашу поддержку.
Попутно мы хотели автоматизировать многие вещи, чтобы снизить нагрузку на первую линию поддержки и максимально исключить человеческий фактор.
Вот наиболее важные функции, которые мы реализовали в новой службе поддержки: Передача инцидента.
К нам часто поступают сложные запросы, которые по цепочке выполняют специалисты разных отделов.
Самое простое — это приложение для физического доступа к оборудованию в дата-центре.
Сначала диспетчер выдает пропуск, затем передает данные клиента и номер пропуска дежурному инженеру, который встречает и сопровождает клиента в дата-центре.
Есть запросы, которые обрабатываются последовательно 5 отделами.
Для всех таких случаев в интерфейсе появилась отдельная кнопка «Перевести».
Переписка с клиентом и коллегами.
Эта функция как раз для того, чтобы корреспонденция по поводу инцидента не «утекла» на почту и вся история общения сохранилась у нас.
Пока что здесь все очень минималистично.
В планах сделать полнотекстовый редактор с возможностью загрузки файлов, таблиц и т.д. 
История поручений и история всех действий по инциденту.
Эти вкладки помогут разобраться в спорных вопросах и внутренних расследованиях.
Сейчас выгружаю отчеты из истории, чтобы отслеживать, как часто диспетчеры допускают ошибки при отнесении инцидента к специализированной группе.
Вот так выглядит история назначений по внутреннему инциденту «Увольнение сотрудника».
История происшествия.
Здесь мы его еще украсим, но основная задача уже решена — все протоколировано.
Наблюдатель.
Бывает, что в письме-заявке клиент прикрепляет к копии заинтересованные лица.
Все эти товарищи появятся во вкладке «Наблюдатели» и будут следить за выполнением данного запроса.
Они будут получать уведомления о статусе запроса и при желании смогут переписываться с нашей техподдержкой.
Эта функция востребована и внутри компании: менеджеры сервиса могут вписаться в любой запрос своего клиента и контролировать его выполнение.
Список наблюдателей можно редактировать: удалять и добавлять новых.
Шаблоны инцидентов.
Типичных запросов много.
Чтобы не заполнять заявки на пропуск или вывоз мусора десятки раз в день, мы добавили возможность создавать шаблоны инцидентов.
Вам достаточно нажать кнопку «Создать инцидент», и откроется заранее заполненный шаблон с указанным исполнителем, типом, приоритетом и статусом.
В работе дата-центров возникает множество регулярно повторяющихся запросов: обходы, тестирование, проверка инженерного оборудования с помощью чек-листов и т. д. Для всего этого настраиваются автоинциденты, которые автоматически включаются в трекер с заданной периодичностью.
Аналитика.
У Remedy не было встроенных инструментов аналитики; стандартными средствами ничего скачать не удалось.
Здесь мы предусмотрели выгрузку всего для последующего анализа.
Например:
- количество запросов в день;
- скорость реагирования;
- поздние запросы;
- типы запросов;
- загрузка по отделам;
- работа диспетчеров;
- частота и качество проблем, с которыми сталкивается клиент;
- различные зависимости, например, скорость выполнения от типа запроса.
Отчеты можно формировать прямо в службе поддержки с помощью фильтров.
Загрузка данных в различных форматах.
Вы можете выбрать поля, которые будут отображаться при загрузке.
API для интеграции с другими внутренними сервисами.
С простого момента: служба поддержки извлекает информацию из справочников со списком компаний-клиентов, договоров, списком заказанных услуг и ответственных лиц, которые могут отправлять запросы.
Раньше приходилось сначала проверять отдельный файл, чтобы определить, является ли автор клиентом и может ли он писать запросы для компании.
«Обход дежурной смены» — еще одна наша внутренняя служба, с которой теперь может взаимодействовать служба поддержки.
Это электронный чек-лист, согласно которому дежурные и инженеры по эксплуатации несколько раз в день проверяют дата-центры на предмет поломок и беспорядка.
Примерная ситуация: во время обхода дежурный наткнулся на клиентскую стойку с неправильно установленным оборудованием.
Он просто делает соответствующую запись в программе Обход, и инцидент по проблеме автоматически отправляется в службу поддержки.
Дежурный идет дальше по объездному маршруту, и они уже начинают решать проблему со счетчиком.
Вы можете создать инцидент, используя любой из пунктов контрольного списка.
Форма для инцидента внутри программного обеспечения Bypass. Выше приведены инциденты при работе на том же объекте.
Мелочи.
На странице интерфейса мы отобразили все наиболее распространенные типы запросов.
После выбора приоритета пользователь видит крайний срок и индикатор выполнения, показывающий, сколько времени ему осталось на завершение инцидента.
Выполнение
В ходе опытной эксплуатации мы протестировали работу службы поддержки по внутренним запросам.Мы обучались около месяца на кафедрах управления, капитального строительства, управления производством и сервисом.
Через Remedy продолжали поступать внешние запросы и запросы из других отделов.
Затем мы договорились с тремя клиентами протестировать обработку внешних приложений.
Вот тут и начались первые проблемы.
Когда мы только начинали делать новую службу поддержки, я лелеял надежду, что наш умный парсер электронной почты сможет регистрировать запросы, распределять их по профильным отделам и группировать сообщения по одной и той же проблеме в один инцидент. В долгосрочной перспективе это означало отказ диспетчеров обрабатывать письменные запросы.
В Remedy люди очень привыкли полагаться на электронную переписку, ее оказалось больше, чем мы ожидали.
Во время тестирования парсер дал сбой: он мог запутать отделы при назначении запроса, а новые сообщения об уже открытом инциденте он регистрировал как новые инциденты.
Были и более тривиальные трудности: парсер не мог прочитать письмо, пришедшее с почты с сертификатом; Я не понял нестандартную кодировку и отправил текст из вопросов.
Пришлось добавить ручной труд — появилась Диспетчерская.
Это чистилище для всех заявлений, полученных на [email protected] .
Оттуда диспетчеры вручную распределяют запросы по отделам.
На клиентской стороне логика взаимодействия с техподдержкой осталась прежней, изменился только тип подсказок.
В первые дни с ними было несколько проблем, в основном из-за неверных контактных данных в справочниках.
Итак, у одного из клиентов было 23 ответственных человека и у всех был один общий адрес электронной почты, например, info@.
Служба поддержки послушно всех оповестила, за час выполнив дневную норму входящих на этот ящик.
Что дальше?
В ближайшем будущем - интеграция с Личным кабинетом .Вся переписка и история обращений будут отображаться в профиле клиента.
Теоретически это шанс исключить электронную почту из общения с техподдержкой и окончательно перетащить клиента в наш веб-интерфейс.
Посмотрим, как это приживется в жизни.
Реализация параметризованного запроса .
Бывают запросы, которые содержат множество параметров и значений, и важно в них ничего не перепутать.
Например, когда клиент просит добавить виртуальные ресурсы в пул или создать виртуальные машины определенных размеров.
Для таких случаев мы планируем сделать конструктор с параметрами.
Он будет автоматически анализировать аналогичные клиентские запросы, полученные по почте.
Он также будет использоваться диспетчерами при приеме заявок по телефону.
Вот как выглядит параметризованный запрос.
Оценка работы технической поддержки.
Пресловутая «оцените наш сервис по пятибалльной шкале» с возможностью написать в свободной форме все, что клиент думает о нашем сервисе.
Мы хотим развить ту самую Dispatch Room, которая возникла как костыль в помощь парсеру почты, в полноценную.
автоматизированное рабочее место диспетчера (АРМ) .
Теперь диспетчеру приходится заглядывать в различные интерфейсы (учет оборудования, список ответственных лиц, клиентские службы), чтобы собрать необходимую информацию о клиенте.
На АРМ все будет в одном окне: клиентские инциденты, контакты, договоры, заказанные услуги и их параметры и т.д. данные.
Что ж, не будем терять надежду автоматическое распределение заявок по отделам .
Сейчас мы думаем над системой хэштегов для парсера электронной почты.
*** Служба поддержки работает в рабочем режиме с ноября, и все это время я наблюдаю стабильный рост количества инцидентов (+40%), в первую очередь за счет внутренних обращений.
Смею надеяться, что это связано с тем, что новая служба поддержки более дружелюбна во всех отношениях и запросы перестали ускользать мимо нее.
Еще одним преимуществом новой службы поддержки является гибкость.
Мы уже разработали несколько индивидуальных решений для отдельных клиентов, которые можно интегрировать с их внутренними службами поддержки или просто адаптировать к их производственным процессам.
Раньше на это уходили месяцы и миллионы, а сейчас достаточно письма разработчику и 1-2 недели, в зависимости от сложности задачи.
Теги: #Service Desk #helpdesk #techsupport #Help Desk Software #helpdesk
-
Ssd-Vds И Ssd-Хостинг В Нидерландах И Сша
19 Oct, 24 -
Directaccess В Windows 7. Часть 2
19 Oct, 24
