Как мы оптимизировали обслуживание выездных заявок

Post image full

Вводная

Есть компания по ИТ-аутсорсингу, на обслуживании у которой более 1500 единиц оборудования. Максимальный упор делается на удаленное решение заявок и сейчас эта цифра в районе 85%, по оставшимся же 15% надо ездить.

Теги

А ещё у нас есть замечательный сервис — «Плановый выезд», в рамках которого мы регулярно навещаем клиента для:

  1. проведения регламентных работ по компьютерам и серверам;
  2. решения неаварийных обращений, требующих присутствия на месте.

Проблематика

Звонит клиент:

  • — А где ваш сотрудник? Он должен был быть 15 минут назад уже у нас. Мы ждём. Работа стоит!
  • — Координатор (тот кто отвечает за распределение и контроль выездов) судорожно звонит инженеру с вопросом «Ты где ****?»

А инженер в этот момент либо попал в пробку и вот уже паркуется и его отвлекают, либо вообще уже у клиента, просто в соседнем кабинете занимается заявкой.

Ну или так — инженер куда-то ездит всю неделю, а потом выясняется, что у клиентов он ни разу и не был… И что делать?

Вариант 1. Ввести регламент:

  1. Приехал к клиенту — звони координатору о прибытии.
  2. Он отмечает в таблице.
  3. Уехал — звони координатору, он отмечает в эксельке отъезд.

Что может пойти не так:

  • Звонить забываем. Вечно напоминать или штрафовать — не выход.
  • Можно позвонить и сказать, что приехал, а сам дома чай пьёшь с плюшками.

Вариант 2. Всё тоже самое, но добавим сюда подтверждение присутствия на месте, например, звонок с телефона клиента или передавать трубку клиенту для подтверждения факта прибытия. Решение так себе — напоминает детский сад.

Вариант 3. Доходим до паранойи: берём подпись с клиента о нашем прибытии. Терпим непонимающий взгляд клиента и копим тонну макулатуры. Тоже не очень разумно.

Вариант 4. Автоматизация. И как она выглядит? Есть наш замечательный HelpDesk, наше детище http://admaxe.ru/, в нем есть две сущности:

  • аварийный выезд.
  • плановый выезд;

По ним необходимо фиксировать прибытие\отбытие и прочую полезную информацию.

Что мы сделали

Создали свой GPS трекер для Android. Выглядит вот так:

Трекинг инженеров по обслуживанию компьютеров

Позаботились и о конфиденциальности инженеров — трекер выключается в нерабочее время. Он отправляет данные на наш сервер HelpDesk, а здесь они сохраняются и обрабатываются.

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

Далее, для каждого клиента указан ореол координат, его офиса\склада\филиала и т.д. При попадании координат инженера в данный ореол, HD отсчитывает определённый промежуток времени (чтобы исключить вариант когда проезжали мимо) и, если всё ок, сообщает о прибытии инженера к клиенту.

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

Что получили полезного из этого

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

Трекинг инженеров по обслуживанию компьютеров

  • Можем заранее предупредить клиента, что инженер задержится, т.к. пробка и КАД опять перекопали.
  • Можем следить за продуктивностью работы инженера на месте. Мы считаем время, проведённое на месте, а также время, затраченное непосредственно на работу над заявками (наш HD и такое умеет).
  • Если получим, что у клиента были 3 часа, а работали только 1 час, то либо работа идёт в обход заявок, а это не наш метод, либо инженер гоняет чаи у клиента, что совсем непозволительно.

Трекинг инженеров по обслуживанию компьютеров

  • Сделали оповещение о пробках. Если инженер, находясь в пути, слишком долго стоит на одном месте, то, значит, пробка и надо проверить, сможем ли мы уложиться в сроки, озвученные клиенту. Лучше предупредить заранее, что мы можем задержаться, чем в последний момент.
  • Также отслеживаем, когда путь занимает подозрительно много времени, например, больше 1 часа. Стоит посмотреть, почему так: либо пробки, либо инженер присел отдохнуть.

Трекинг инженеров по обслуживанию компьютеров

  • Аналитика. Можно смотреть, сколько занимает время устранения аварии: сколько ехали до клиента, сколько работали на месте. Очень помогает при проектировании SLA.
  • Аналитика. Следим, чтобы у клиента были не слишком мало. Мы не занимаемся «очковтирательством», если приехали, то надо делать дело, а в ИТ оно всегда найдётся. Также не стоит делать слишком много — смотрим, почему так. Может, у клиента есть проблемы, которые надо системно решить, чтобы более они не повторялись?