Меня зовут Дарья, я продуктовый аналитик. Основной продукт моей компании — service desk, облачная платформа, которая автоматизирует бизнес-процессы: например, ремонтные работы, техническое обслуживание различных объектов. Одна из моих задач — участие в процессе внедрения нашей платформы в бизнес клиентов, при этом нужно погрузиться в специфику работы конкретной компании как можно глубже.
Хочу поведать, как удалось автоматизировать трудоемкие бизнес-процессы одному из наших клиентов, сервисной компании “Брант”. Компания обратилась к нашей платформе, когда количество ее клиентов, и, соответственно, заявок на обслуживание, стало стремительно расти. Бизнес активно развивается, ведь это отлично, в чем подвох? В том, что резко растет и количество однотипных рутинных процессов, и эту опасность нельзя недооценивать. А кроме того, становится очевидно, что нельзя пользоваться теми же инструментами, которые работали, когда заявок было меньше.
Знакомо?
Итак, история спасения.
Именно сервисные компании задействуют функционал нашей платформы максимально полно, ведь они нуждаются в оперативной коммуникации между несколькими сторонами. Что это за стороны?
Каждая из крупных сетей настаивала, чтобы вся работа по сопровождению заявки велась в их программах учета. Автоматизация взаимодействия эффективна и для заказчика, и сервисной компании, и оправдана в сфере комплексного обслуживания. Однако, когда заказчиков более двух, работа сервисной компании сразу в нескольких программах создает сложности.
Сеть «Полянка» использует программу 1С: ТОиР; «Доктор А» — подает заявки через систему Intraservice; «Доктор Б» и «Оп Мобайл» — через собственные Service Desk. Несетевые заказчики передают заявки с помощью электронной почты, телефонных звонков или даже через WhatsApp и Viber.
Сбор всех поступивших заявок производился в excel-файле. Количество заявок одномоментно могло быть более 4 тысяч – и это только активные заявки, а ведь еще необходимо хранить историю выполненных заявок.
Сводный файл просто угрожал умереть в любой момент, и приходилось постоянно делать копии, чтобы не потерять базу заявок. Сбор заявок из всех источников и перенос их в Excel-файл занимал недопустимо много времени. А затем еще было необходимо вручную рассылать заявки исполнителям посредством СМС-сообщений, электронной почты, Viber и WhatsApp.
При этом заявка, отправляемая сервисному специалисту, должна содержать максимум информации, нужной для ее выполнения. После выполнения заявки нужно было собрать информацию о выполнении и фотоотчеты. И еще где-то это хранить.
Можно представить, насколько нелегко давалась подобная мультиканальность приема, учета и распределения заявок. Учитывая, что компания получала новых клиентов на обслуживание, и нанимала все больше специалистов, процесс отчаянно нуждался в автоматизации и повышении прозрачности. Тем не менее, отказаться работать с заявками так, как удобно клиенту нельзя, ведь это предусмотрено условиями договора.
Значит, требуется отдельная система, которая позволит:
И при этом она должна быть удобной для исполнителя — выездного сотрудника, у которого с собой только телефон в качестве средства связи.
После изучения рынка программных продуктов «Брант» выбрал нашу систему — платформу HubEx.
Шаг 1: С помощью Excel-импорта были перенесены в платформу данные о всех обслуживаемых объектах (на момент старта их было более 900) — теперь вся необходимая информация о каждом объекте хранится веб-паспорте объекта: адрес, геолокация на карте, техническая документация, контакты, история обслуживания. Все, что может потребоваться для оперативного выполнения заявки.
Шаг 2: — Загрузка заявок в общую систему была произведена быстро. Импорт в системе HubEx происходит в два клика, и вот уже все заявки по каждому объекту собраны в одном месте. Альтернативный способ сбора заявок из систем заказчиков — настройка механизма приема заявок прямо по электронной почте. Такой вариант также доступен в платформе.
Результат: Диспетчеры компании «Брант» видят все заявки в одной программе и распределяют их между выездными сотрудниками.
У каждого сотрудника в кармане — телефон с мобильным приложением, которое сообщит о новой назначенной заявке. А в самом приложении специалист видит актуальный список своих заявок:
Важный момент: теперь все коммуникации по заявке производятся не с помощью телефонного разговора и не через мессенджеры, а строго в самой заявке.
Это позволяет хранить историю выполнения заявки, четко сегментировать общение по каждой из них, и сделать так, чтобы ничего важного не потерялось. Исполнитель может запросить дополнительные сведения о выполнении работ, сообщить об опоздании, пригласить в обсуждение нужного участника — например, другого специалиста — который обслуживал этот объект раньше.
Теперь при передаче заявки другому специалисту вся нужна информация по предыдущим действиям доступна новому сотруднику.
Так, внедрение сервис деска позволило «Бранту» объединить все свои проекты в единую систему. Кроме того, рутинные процессы, которые угрожали «утопить» в себе компанию, значительно сократились: несмотря на то, что количество объектов обслуживания возрастало, не потребовалось раздувать штат новыми сотрудниками лишь для того, чтобы покрыть рост количества однотипных задач.
Хочу поведать, как удалось автоматизировать трудоемкие бизнес-процессы одному из наших клиентов, сервисной компании “Брант”. Компания обратилась к нашей платформе, когда количество ее клиентов, и, соответственно, заявок на обслуживание, стало стремительно расти. Бизнес активно развивается, ведь это отлично, в чем подвох? В том, что резко растет и количество однотипных рутинных процессов, и эту опасность нельзя недооценивать. А кроме того, становится очевидно, что нельзя пользоваться теми же инструментами, которые работали, когда заявок было меньше.
Знакомо?
Итак, история спасения.
Именно сервисные компании задействуют функционал нашей платформы максимально полно, ведь они нуждаются в оперативной коммуникации между несколькими сторонами. Что это за стороны?
- Заказчик, у которого что-то сломалось
- Диспетчер сервисной службы, который принимает заявку, назначает исполнителя и контролирует ее выполнение
- Ведущий инженер, который обеспечивает контроль за качеством выполняемых работ и оказывает техническую поддержку при выполнении сложных заявок
- Сервисный специалист, который приедет на точку и будет устранять неисправность
Справка о компании «Брант»
- Оказываемые услуги: ремонт и гарантийное обслуживание оборудования, строительно-монтажные работы; клининг;
- Больше 1000 объектов обслуживания расположены в Москве и ближнем Подмосковье;
- В штате более 60 сервисных специалистов.
- Ежемесячно компания выполняет более 4500 заявок.
- Для обозначения клиентов «Бранта» в этом тексте мы используем псевдонимы. Это: федеральная сеть продуктовых магазинов – назовем ее «Полянка»; две аптечные сети – «Доктор А» и «Доктор Б»; центры обслуживания оператора связи «Оп Мобайл»; а также несколько производственных объектов;
Каждая из крупных сетей настаивала, чтобы вся работа по сопровождению заявки велась в их программах учета. Автоматизация взаимодействия эффективна и для заказчика, и сервисной компании, и оправдана в сфере комплексного обслуживания. Однако, когда заказчиков более двух, работа сервисной компании сразу в нескольких программах создает сложности.
Как все было ДО внедрения Service Desk
Сеть «Полянка» использует программу 1С: ТОиР; «Доктор А» — подает заявки через систему Intraservice; «Доктор Б» и «Оп Мобайл» — через собственные Service Desk. Несетевые заказчики передают заявки с помощью электронной почты, телефонных звонков или даже через WhatsApp и Viber.
Сбор всех поступивших заявок производился в excel-файле. Количество заявок одномоментно могло быть более 4 тысяч – и это только активные заявки, а ведь еще необходимо хранить историю выполненных заявок.
Сводный файл просто угрожал умереть в любой момент, и приходилось постоянно делать копии, чтобы не потерять базу заявок. Сбор заявок из всех источников и перенос их в Excel-файл занимал недопустимо много времени. А затем еще было необходимо вручную рассылать заявки исполнителям посредством СМС-сообщений, электронной почты, Viber и WhatsApp.
При этом заявка, отправляемая сервисному специалисту, должна содержать максимум информации, нужной для ее выполнения. После выполнения заявки нужно было собрать информацию о выполнении и фотоотчеты. И еще где-то это хранить.
Можно представить, насколько нелегко давалась подобная мультиканальность приема, учета и распределения заявок. Учитывая, что компания получала новых клиентов на обслуживание, и нанимала все больше специалистов, процесс отчаянно нуждался в автоматизации и повышении прозрачности. Тем не менее, отказаться работать с заявками так, как удобно клиенту нельзя, ведь это предусмотрено условиями договора.
Значит, требуется отдельная система, которая позволит:
- собрать в одном месте задачи из всех систем заказчиков;
- стандартизировать поступившие в разных форматах заявки;
- передать заявки сервисным специалистам со всей необходимой информацией;
- получить отчет о выполнении заявки;
- хранить историю по выполненным заявкам.
И при этом она должна быть удобной для исполнителя — выездного сотрудника, у которого с собой только телефон в качестве средства связи.
Как все стало после внедрения Service Desk
После изучения рынка программных продуктов «Брант» выбрал нашу систему — платформу HubEx.
Шаг 1: С помощью Excel-импорта были перенесены в платформу данные о всех обслуживаемых объектах (на момент старта их было более 900) — теперь вся необходимая информация о каждом объекте хранится веб-паспорте объекта: адрес, геолокация на карте, техническая документация, контакты, история обслуживания. Все, что может потребоваться для оперативного выполнения заявки.
Шаг 2: — Загрузка заявок в общую систему была произведена быстро. Импорт в системе HubEx происходит в два клика, и вот уже все заявки по каждому объекту собраны в одном месте. Альтернативный способ сбора заявок из систем заказчиков — настройка механизма приема заявок прямо по электронной почте. Такой вариант также доступен в платформе.
Результат: Диспетчеры компании «Брант» видят все заявки в одной программе и распределяют их между выездными сотрудниками.
У каждого сотрудника в кармане — телефон с мобильным приложением, которое сообщит о новой назначенной заявке. А в самом приложении специалист видит актуальный список своих заявок:
Важный момент: теперь все коммуникации по заявке производятся не с помощью телефонного разговора и не через мессенджеры, а строго в самой заявке.
Это позволяет хранить историю выполнения заявки, четко сегментировать общение по каждой из них, и сделать так, чтобы ничего важного не потерялось. Исполнитель может запросить дополнительные сведения о выполнении работ, сообщить об опоздании, пригласить в обсуждение нужного участника — например, другого специалиста — который обслуживал этот объект раньше.
Теперь при передаче заявки другому специалисту вся нужна информация по предыдущим действиям доступна новому сотруднику.
Так, внедрение сервис деска позволило «Бранту» объединить все свои проекты в единую систему. Кроме того, рутинные процессы, которые угрожали «утопить» в себе компанию, значительно сократились: несмотря на то, что количество объектов обслуживания возрастало, не потребовалось раздувать штат новыми сотрудниками лишь для того, чтобы покрыть рост количества однотипных задач.
botka4aet
Те сперва все эти 900 заявок надо было привести к одному виду, я правильно понимаю?
Загрузка каких заявок? Старых? Ну ок, импорт, все дела. Но тогда зачем в этом же шаге что-то про прием заявок по почте?(очевидно новых)
По поводу скринов до и после. В первом случае чат с диспетчером, а во втором — чат с работником на объекте. Что мешало сделать такой же чат в первом случае?
DashaV Автор
Все верно
Прием заявок по электронной почте — это еще одна, дополнительная возможность системы. Клиент пишет письмо на определенный адрес, и оно автоматически заводится в системе как заявка. Именно «Брант» ее не использует эту функцию, но если бы все клиенты этой компании предпочитали оставлять заявки по почте, такая возможность была бы кстати.
В первом случае работник на объекте и диспетчер общаются в своем регулярном диалоге WhatsApp. Обсуждение по каждому случаю слилось в единую кашу, но не заводить же отдельный чат по каждой заявке. Часто по каждому случаю требуется только 1-2 уточнения: «скиньте инструкцию», «не успеваю» итд.
Во втором диспетчер и работник общаются уже в конкретной заявке, и никакой путаницы.