Знову на зв'язку продуктовий аналітик вітчизняного service desk. Минулого разу про нашого клієнта, сервісну компанію "Брант", яка запровадила нашу платформу під час активного зростання свого бізнесу.
Одночасно зі зростанням кількості заявок у “Бранта” зросла і кількість об'єктів обслуговування – кількісно та територіально. Як наслідок, знадобилося більше роз'їздів на бобільші відстані, і бюджет на витрати на ПММ значно збільшився. Як автоматизація диспетчерської служби допомогла вберегти її від цих витрат, хочу розповісти у цьому пості.
Отже, "Брант" - досить велика сервісна компанія. На обслуговуванні більше 1 000 об'єктів — це магазини, офіси, салони, аптеки — і в кожному з них періодично потрібно виконати поточний ремонт, аварійний ремонт або гарантійне обслуговування. У середньому на день надходить 100-200 заявок.
Як все було ДО автоматизації диспетчерської служби
Мережа об'єктів конкретного замовника об'єднувалася в окремий проект. За кожним проектом закріплювався окремий диспетчер та формувався штат сервісних фахівців. Довгий час такий варіант структури обслуговування вважався у компанії "Брант" максимально ефективним.
Сформована під конкретний проект команда могла приймати заявки, що надходять у тому форматі, в якому зручно замовнику, а сервісні фахівці знали всю специфіку виконання заявок саме на цих об'єктах. Це дозволяло вирішувати завдання з обслуговування якісно, але з великою кількістю ручної роботи.
Диспетчер «Бранта» отримував заявку, потім звірявся зі списком об'єктів: який фахівець закріплений за цією адресою? Чи встигає він у строк при поточному завантаженні? Якщо ні, то кому із сусідніх ділянок можна передати заявку?
Вручну цей процес не швидкий і прозорим його теж не назвеш — доводиться звертатися до тих самих громіздких таблиць і уточнювати у виконавців, чи готові вони прийняти заявку.
У 2019 році у «Бранта» різко зросла кількість об'єктів обслуговування, і це показало неспроможність наявної структури. А саме:
- розпочалися територіальні накладки об'єктів. Траплялося, що до одного обласного міста їхали 2-3 сервісні фахівці для виконання заявок від різних замовників. Аналогічно 1-2 диспетчери керували цими фахівцями, які в одному місті буквально у сусідніх будинках.
- знадобилося збільшити штат сервісних фахівців, а також інженерів та диспетчерів, які керують проектами та спеціалістами;
- як наслідок - різко зросли витрати на ПММ;
- стало неможливо оперативно отримувати аналітичні дані щодо виконання заявок: співробітників та інформації тепер надто багато.
Як усе стало ПІСЛЯ автоматизації диспетчерської служби
Стало очевидно, що для вирішення проблем потрібно вчинити так:
- збирати всі заявки, що надходять, в одному місці, а не в рамках одного робочого проекту
- переводити всі заявки, що надійшли, в єдиний формат
- впровадити стандарт виконання заявки, незалежно від якого замовника надійшла ця заявка.
Це дозволить створити територіально сформовану сітку сервісних фахівців, які готові виконати всі заявки по своїй зоні без прив'язки до специфіки того чи іншого Замовника.
Реструктуризацію вдалося провести швидко і без шкоди якості послуг. Це дозволило знизити витрати на ПММ та уникнути збільшення штату інженерів та диспетчерів. Було створено єдиний диспетчерський центр всім Замовників. Закріплення співробітників усіх рівнів проводилося за територіальною ознакою.
В адміністративній панелі нашої платформи HubEx передбачено гнучке налаштування автоматичного розподілу заявок. Список об'єктів, який імпортується в HubEx з Excel-файлу, вже містить поле із зазначенням відповідального, тому при створенні заявки на свій об'єкт Сервісний спеціаліст отримує її відразу, без участі диспетчера.
Подальший розподіл можна встановити в налаштуваннях. Наприклад, якщо протягом кількох годин призначений виконавець не переводить заявку на стадію "Прийнята в роботу" - заявку "успадковує" інший відповідний виконавець. Налаштування дозволяють вибрати запасного відповідального, або найближчого, який має необхідні навички для ремонту за конкретною заявкою. Ось як це виглядає:
Завдяки GPS-навігації, завжди можна контролювати, чи справді був співробітник на об'єкті, і де саме він знаходиться зараз.
І знову оптимізація часу всіх співробітників компанії, причому значна. Підвищення прозорості виконання (чи невиконання) робіт всіх етапах.
За допомогою платформи стало можливо реалізувати технічний нагляд за роботами та оперативну технічну підтримку сервісному фахівцю.
У випадку, якщо працівник стикається з проблемами при виконанні заявки, він повідомляє про це в самій заявці, диспетчер оперативно підключає до спілкування за заявкою інженера. У будь-який момент часу на будь-яке запитання замовника оперативно надається зворотний зв'язок за будь-якою заявкою. Керівники проектів, тільки приймаючи запит від замовника, можуть відкрити заявку і дати всю актуальну інформацію про роботи. Особливо актуально це при виконанні аварійних та трудомістких заявок.
Переваги онлайн-диспетчерської
Так автоматизація диспетчерської служби заощадила не лише час працівників, а й значно скоротила витрати на пальне. Система аналітики агрегує всі дані та дає наочне уявлення про статуси всіх заявок, допомагаючи тим самим «Бранту» контролювати якість своїх послуг та планувати подальші роботи.
Джерело: habr.com