Автоматизация диспетчерской службы, или Как сервисной компании сократить транспортные расходы на 30%

Снова на связи продуктовый аналитик отечественной service desk. В прошлый раз мы рассказывали про нашего клиента, сервисную компанию «Брант», которая внедрила нашу платформу во время активного роста своего бизнеса.

Одновременно с ростом числа заявок у «Бранта» выросло и число объектов обслуживания — количественно и территориально. Как следствие, понадобилось больше разъездов на большие расстояния, и бюджет на расходы по ГСМ значительно увеличился. Как автоматизация диспетчерской службы помогла уберечь ее от этих расходов, хочу рассказать в этом посте.

-1cdhpf29l1bzqjb84eqhdl_jp4.jpeg
Итак, «Брант» — достаточно крупная сервисная компания. На обслуживании у нее более 1 000 объектов — это магазины, офисы, салоны, аптеки — и в каждом из них периодически требуется выполнить текущий ремонт, аварийный ремонт или гарантийное обслуживание. В среднем в день поступает 100–200 заявок.

Как все было ДО автоматизации диспетчерской службы


Сеть объектов конкретного заказчика объединялась в отдельный проект. За каждым проектом закреплялся отдельный диспетчер и формировался штат сервисных специалистов. Долгое время такой вариант структуры обслуживания считался в компании «Брант» максимально эффективным.

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

Диспетчер «Бранта» получал заявку, затем сверялся со списком объектов: какой специалист закреплен по данному адресу? Успевает ли он в срок при текущей загрузке? Если нет, то кому с соседних участков можно передать заявку?

me0b2t5i5bx5yyud9vlvxqte-r8.jpeg

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

В 2019 году у «Бранта» резко выросло число объектов обслуживания, и это показало несостоятельность имеющейся структуры. А именно:

  • начались территориальные накладки объектов. Случалось, что в один областной город ехали 2–3 сервисных специалиста для выполнения заявок от разных заказчиков. Аналогично 1–2 диспетчера управляли этими специалистами, которые в одном городе буквально в соседних зданиях.
  • понадобилось увеличить штат сервисных специалистов, а также инженеров и диспетчеров, управляющих проектами и специалистами;
  • как следствие — резко выросли затраты на ГСМ;
  • стало невозможно оперативно получать аналитические данные по исполнению заявок: сотрудников и информации теперь слишком много.


Как все стало ПОСЛЕ автоматизации диспетчерской службы


Стало очевидно, что для решения проблем нужно поступить следующим образом:

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


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

jyinsegb8bjaphgbfj1w6qmjufi.png

В административной панели нашей платформы HubEx предусмотрена гибкая настройка автоматического распределения заявок. Список объектов, который импортируется в HubEx из Excel-файла, уже содержит поле с указанием ответственного, поэтому при создании заявки по своему объекту Сервисный специалист получает ее сразу, без участия диспетчера.

Последующее распределение можно задать в настройках. Например, если в течение нескольких часов назначенный исполнитель не переводит заявку на стадию «Принята в работу» — заявку «наследует» другой подходящий исполнитель. Настройки позволяют выбрать запасного ответственного, либо ближайшего, который владеет нужными навыками для ремонта по конкретной заявке. Вот как это выглядит:

ljwoh-dheo3efcwr_5ghtcjs1kc.jpeg

Благодаря GPS-навигации, всегда можно контролировать, действительно ли был сотрудник на объекте, и где конкретно он находится в данный момент времени.

И снова — оптимизация времени всех сотрудников компании, причем значительная. Повышение прозрачности выполнения (или невыполнения) работ на всех этапах.

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

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

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

eoevacsrcqranzx3gwoknczt-xg.jpeg

Читайте 1 часть истории компании «Брант»: Что делать, если ваш бизнес растет?

© Habrahabr.ru