Снова на связи продуктовый аналитик отечественной service desk. В прошлый раз мы рассказывали про нашего клиента, сервисную компанию “Брант”, которая внедрила нашу платформу во время активного роста своего бизнеса.
Одновременно с ростом числа заявок у “Бранта” выросло и число объектов обслуживания — количественно и территориально. Как следствие, понадобилось больше разъездов на большие расстояния, и бюджет на расходы по ГСМ значительно увеличился. Как автоматизация диспетчерской службы помогла уберечь ее от этих расходов, хочу рассказать в этом посте.
Итак, “Брант” — достаточно крупная сервисная компания. На обслуживании у нее более 1 000 объектов — это магазины, офисы, салоны, аптеки — и в каждом из них периодически требуется выполнить текущий ремонт, аварийный ремонт или гарантийное обслуживание. В среднем в день поступает 100-200 заявок.
Сеть объектов конкретного заказчика объединялась в отдельный проект. За каждым проектом закреплялся отдельный диспетчер и формировался штат сервисных специалистов. Долгое время такой вариант структуры обслуживания считался в компании “Брант” максимально эффективным.
Сформированная под конкретный проект команда могла принимать поступающие заявки в том формате, в котором удобно заказчику, а сервисные специалисты знали всю специфику выполнения заявок именно на этих объектах. Это позволяло решать задачи по обслуживанию качественно, но с большим количеством «ручной» работы.
Диспетчер «Бранта» получал заявку, затем сверялся со списком объектов: какой специалист закреплен по данному адресу? Успевает ли он в срок при текущей загрузке? Если нет, то кому с соседних участков можно передать заявку?
Вручную этот процесс не быстрый и прозрачным его тоже не назовешь — приходится обращаться все к тем же громоздким таблицам и уточнять у исполнителей, готовы ли они принять заявку.
В 2019 году у «Бранта» резко выросло число объектов обслуживания, и это показало несостоятельность имеющейся структуры. А именно:
Стало очевидно, что для решения проблем нужно поступить следующим образом:
Это позволит создать территориально сформированную сетку сервисных специалистов, готовых выполнить все заявки по своей зоне без привязки к специфике того или иного Заказчика.
Реструктуризацию удалось провести быстро и без ущерба качеству оказываемых услуг. Это позволило снизить затраты на ГСМ и избежать увеличения штата инженеров и диспетчеров. Был создан единый диспетчерский центр для всех Заказчиков. Закрепление сотрудников всех уровней производилось по территориальному признаку.
В административной панели нашей платформы HubEx предусмотрена гибкая настройка автоматического распределения заявок. Список объектов, который импортируется в HubEx из Excel-файла, уже содержит поле с указанием ответственного, поэтому при создании заявки по своему объекту Сервисный специалист получает ее сразу, без участия диспетчера.
Последующее распределение можно задать в настройках. Например, если в течение нескольких часов назначенный исполнитель не переводит заявку на стадию “Принята в работу” — заявку “наследует” другой подходящий исполнитель. Настройки позволяют выбрать запасного ответственного, либо ближайшего, который владеет нужными навыками для ремонта по конкретной заявке. Вот как это выглядит:
Благодаря GPS-навигации, всегда можно контролировать, действительно ли был сотрудник на объекте, и где конкретно он находится в данный момент времени.
И снова — оптимизация времени всех сотрудников компании, причем значительная. Повышение прозрачности выполнения (или невыполнения) работ на всех этапах.
С помощью платформы стало возможно реализовать технический надзор за работами и оперативную техническую поддержку сервисному специалисту.
В случае, если сотрудник сталкивается с проблемами при выполнении заявки, то он сообщает об этом в самой заявке, диспетчер оперативно подключает к общению по заявке инженера. В любой момент времени на любой вопрос заказчика оперативно дается обратная связь по любой заявке. Руководители проектов, еще только принимая запрос от заказчика, могут открыть заявку и дать всю актуальную информацию по работам. Особенно актуально это при выполнении аварийных и трудоемких заявок.
Так автоматизация диспетчерской службы сэкономила не только время сотрудников, но и значительно сократила расходы на горючее. Система аналитики агрегирует все данные и дает наглядное представление о статусах всех заявок, помогая тем самым «Бранту» контролировать качество своих услуг и планировать дальнейшие работы.
Читайте 1 часть истории компании «Брант»: Что делать, если ваш бизнес растет?
3 часть: Как сервисной компании избежать штрафов от заказчика?
Одновременно с ростом числа заявок у “Бранта” выросло и число объектов обслуживания — количественно и территориально. Как следствие, понадобилось больше разъездов на большие расстояния, и бюджет на расходы по ГСМ значительно увеличился. Как автоматизация диспетчерской службы помогла уберечь ее от этих расходов, хочу рассказать в этом посте.
Итак, “Брант” — достаточно крупная сервисная компания. На обслуживании у нее более 1 000 объектов — это магазины, офисы, салоны, аптеки — и в каждом из них периодически требуется выполнить текущий ремонт, аварийный ремонт или гарантийное обслуживание. В среднем в день поступает 100-200 заявок.
Как все было ДО автоматизации диспетчерской службы
Сеть объектов конкретного заказчика объединялась в отдельный проект. За каждым проектом закреплялся отдельный диспетчер и формировался штат сервисных специалистов. Долгое время такой вариант структуры обслуживания считался в компании “Брант” максимально эффективным.
Сформированная под конкретный проект команда могла принимать поступающие заявки в том формате, в котором удобно заказчику, а сервисные специалисты знали всю специфику выполнения заявок именно на этих объектах. Это позволяло решать задачи по обслуживанию качественно, но с большим количеством «ручной» работы.
Диспетчер «Бранта» получал заявку, затем сверялся со списком объектов: какой специалист закреплен по данному адресу? Успевает ли он в срок при текущей загрузке? Если нет, то кому с соседних участков можно передать заявку?
Вручную этот процесс не быстрый и прозрачным его тоже не назовешь — приходится обращаться все к тем же громоздким таблицам и уточнять у исполнителей, готовы ли они принять заявку.
В 2019 году у «Бранта» резко выросло число объектов обслуживания, и это показало несостоятельность имеющейся структуры. А именно:
- начались территориальные накладки объектов. Случалось, что в один областной город ехали 2-3 сервисных специалиста для выполнения заявок от разных заказчиков. Аналогично 1-2 диспетчера управляли этими специалистами, которые в одном городе буквально в соседних зданиях.
- понадобилось увеличить штат сервисных специалистов, а также инженеров и диспетчеров, управляющих проектами и специалистами;
- как следствие — резко выросли затраты на ГСМ;
- стало невозможно оперативно получать аналитические данные по исполнению заявок: сотрудников и информации теперь слишком много.
Как все стало ПОСЛЕ автоматизации диспетчерской службы
Стало очевидно, что для решения проблем нужно поступить следующим образом:
- собирать все поступающие заявки в одном месте, а не в рамках одного рабочего проекта
- переводить все поступившие заявки в единый формат
- внедрить стандарт выполнения заявки, вне зависимости от какого заказчика поступила эта заявка.
Это позволит создать территориально сформированную сетку сервисных специалистов, готовых выполнить все заявки по своей зоне без привязки к специфике того или иного Заказчика.
Реструктуризацию удалось провести быстро и без ущерба качеству оказываемых услуг. Это позволило снизить затраты на ГСМ и избежать увеличения штата инженеров и диспетчеров. Был создан единый диспетчерский центр для всех Заказчиков. Закрепление сотрудников всех уровней производилось по территориальному признаку.
В административной панели нашей платформы HubEx предусмотрена гибкая настройка автоматического распределения заявок. Список объектов, который импортируется в HubEx из Excel-файла, уже содержит поле с указанием ответственного, поэтому при создании заявки по своему объекту Сервисный специалист получает ее сразу, без участия диспетчера.
Последующее распределение можно задать в настройках. Например, если в течение нескольких часов назначенный исполнитель не переводит заявку на стадию “Принята в работу” — заявку “наследует” другой подходящий исполнитель. Настройки позволяют выбрать запасного ответственного, либо ближайшего, который владеет нужными навыками для ремонта по конкретной заявке. Вот как это выглядит:
Благодаря GPS-навигации, всегда можно контролировать, действительно ли был сотрудник на объекте, и где конкретно он находится в данный момент времени.
И снова — оптимизация времени всех сотрудников компании, причем значительная. Повышение прозрачности выполнения (или невыполнения) работ на всех этапах.
С помощью платформы стало возможно реализовать технический надзор за работами и оперативную техническую поддержку сервисному специалисту.
В случае, если сотрудник сталкивается с проблемами при выполнении заявки, то он сообщает об этом в самой заявке, диспетчер оперативно подключает к общению по заявке инженера. В любой момент времени на любой вопрос заказчика оперативно дается обратная связь по любой заявке. Руководители проектов, еще только принимая запрос от заказчика, могут открыть заявку и дать всю актуальную информацию по работам. Особенно актуально это при выполнении аварийных и трудоемких заявок.
Преимущества онлайн-диспетчерской
Так автоматизация диспетчерской службы сэкономила не только время сотрудников, но и значительно сократила расходы на горючее. Система аналитики агрегирует все данные и дает наглядное представление о статусах всех заявок, помогая тем самым «Бранту» контролировать качество своих услуг и планировать дальнейшие работы.
Читайте 1 часть истории компании «Брант»: Что делать, если ваш бизнес растет?
3 часть: Как сервисной компании избежать штрафов от заказчика?
