Ваш дзвінок дуже важливий для нас? Або як працює система пріоритезації заявок в сервісних підрозділах

imageЗдрастуй, дорогий Читачу. Сьогодні я розповім тобі, як влаштована система визначення пріоритетів звернень в технічну підтримку компанії, наявність якої в організації дозволяє істотно скоротити час реакції на запит, правильно розподілити обмежені ресурси сервісного підрозділу, максимально швидко і ефективно реагувати на гострі проблеми клієнтів, що не терплять зволікань. Особливості роботи системи ми розглянемо на реальному прикладі нашої компанії.

Отже, уявимо ситуацію, що ти звернувся в організацію X за якоюсь послугою/продуктом. Можливо, ще на етапі покупки у тебе виникали сумніви щодо розумності вибору компанії, але з якихось причин послугу/продукт ти все-таки придбав. Як виявилося згодом – дуже даремно. Якість послуги/продукту не відповідає очікуванням, повернення не передбачено, але змусити це виріб працювати все одно треба. Вихід – служба підтримки. Але ось невдача. Служба підтримки ніби не помічає твоїх прохань про допомогу, по телефону з ними не контактувати, електронні повідомлення ніби відразу відправляються в спам. Знайоме?

З чим можуть бути пов'язані такі проблеми і чи має це відношення до нераціонального розподілу ресурсів у сервісних підрозділах і неправильної пріоритезації звернень замовників? На ці питання я і спробую пролити світло на прикладі системи пріоритезації звернень АТ «Инфовотч».

Ми розглянемо основні критерії підвищення або зниження пріоритету звернення до служби технічної підтримки, механіку їх роботи, розглянемо в якому порядку шикуються заявки для співробітників і їхніх безпосередніх керівників. Для початку давайте з'ясуємо, як система виставлення пріоритетів звернень клієнтів виглядає зсередини.

Розстановка пріоритетів звернень в сервісних підрозділі при роботі з чергами часто викликає питання. Організація повинна дорости до певного рівня зрілості, щоб почати надавати цьому аспекту надання послуг потрібну увагу. Звичайно, обсяг запитів повинен досягти того рівня, щоб і критерії розстановки пріоритетів «дозріли», і кількість помилок через «людського фактора» зросла до неприйнятних величин (що легко помітити по зростаючій кількості «крикливих» замовників і ескалацій від керівництва), та економічний ефект від автоматизації процесу став відчутним.

Ви коли-небудь аналізували, скільки часу витрачається працівниками на рутинне адміністрування бізнес-процесів в вашому підрозділі? Думаю, що навіть якщо і доводилося цим займатися, то не дуже часто. Між тим, рутина може віднімати значна кількість робочого часу співробітника. Не можна сказати, що вона не важлива, адже вона забезпечує функціонування всього механізму, але, разом з тим, така робота не приносить і вимірюваного результату, який керівництво бажає бачити в KPI. Наприклад, в службі технічної підтримки навряд чи комусь цікаво, скільки співробітник витратив часу на адміністрування заявок (тобто проставлення пріоритетів, заповнення службових полів та інше супутнє підкручування гвинтиків великої механізму заявки в CRM-системі). На контролі, як правило, тільки кількість оброблених і вирішених заявок, результати перевірки якості і CSAT (Customer Satisfaction). Між тим, практика показує, що займатися цим питанням потрібно:

Одна-дві хвилини на заявку * кількість заявок =?
А скільки це в тиждень? А в місяць? А в рік?
А якщо помножити цю кількість годин на середній ФОП сервісної служби?

У менеджерів завжди є більш важливі завдання, що не терплять зволікань, і інвестувати час, щоб автоматизувати частину рутини, та ще отримати згоду і підтримку суміжних підрозділів, чиї інтереси ця автоматизація зачіпає, не завжди представляється можливим. До (не)щастя, у сучасній економічній моделі трапляються кризи, які стимулюють компанії працювати в режимі економії і звернути свій погляд до оптимізації монструозных процесів, накручених в буремні роки. Раніше нетермінові завдання з оптимізації та автоматизації процесів виходять на перший план. Так сталося і в нашій організації.

Економічна ситуація в країні не сприяє найму співробітників під кожну нову задачу, а криза зростання в умовах економії створює унікальну ситуацію, в якій у керівників підрозділів не залишається іншого виходу, крім як зайнятися ревізією процесів, щоб і сервіс не постраждав, і ФОП не розростався.

Отже, мета – забезпечити колишній рівень KPI техпідтримки в умовах зростання кількості звернень та обмеження найму нових співробітників.

Завдання:

  • Спрощення і унифицирование визначення пріоритету звернень для інженера технічної підтримки;
  • Забезпечення правильної черговості обробки заявок.
Проблема – роботи стає більше, кількість робочих рук не росте або росте дуже повільно, вимоги щодо пріоритетів не відображають реальної ситуації з великою кількістю різних нюансів.

Способи вирішення:

  • Контроль робочого часу співробітників (у цій статті не розглядатиметься);
  • Підвищення кваліфікації і продуктивності співробітників (теж як-небудь іншим разом);
  • Зниження трудовитрат на рутинне адміністрування процесів, зокрема процесу виставлення пріоритетів заявками (те, про що і піде мова далі).
У середньому співробітник витрачає до півтора хвилин на те, щоб просто кваліфікувати звернення і призначити йому правильний пріоритет, виходячи з певного набору вимог. Це обов'язкова частина процесу роботи зі зверненнями у будь-якому контакт-центрі, від якої ні за яких обставин не позбутися. У нашому випадку одного разу призначений пріоритет у зверненні зберігався з ним протягом всієї роботи з заявкою і ніколи не перераховувався з урахуванням нових даних. Така ситуація не вимагала автоматизації, поки керівник підрозділу був в змозі тримати в голові весь ескалації, що надійшли від суміжних підрозділів, встигав переглядати всі відкриті звернення і застосовувати «ручне управління» до черговості обробки заявок від замовників. На малих обсягах у команді, де є тільки один менеджер, такий підхід виправданий і достатній. Але його ефективність досить обмежена, не підходить для компаній з двома і більш змінами, і не виключає «людський фактор». Завжди є ймовірність допустити помилку, недоглядеть або просто забути про якусь заявці, не вчасно повідомити колезі з наступної зміни про який-небудь ескалації. В результаті таких збоїв страждають, як правило, замовники, а це неприйнятно. У підсумку ми прийняли рішення повністю переробити систему пріоритезації заявок в технічну підтримку, максимально виключити «людський фактор», вирішити проблему «не оновлюваних» показників пріоритету в кейсах.

В силу того, що CRM-система використовується в компанії досить давно, ми вже накопичили пристойну кількість даних як про клієнта, так і про найбільш типові проблеми і ситуаціях в роботі організації з замовником, замовника з продуктом, продукту з інфраструктурою замовника і т. п. Проконсультувавшись з колегами по цеху і вивчивши досвід побудови подібних систем динамічної пріоритезації в інших компаніях, ми розробили власну, що відповідає нашим реаліям і вкладається в наші бізнес-процеси.

Вирішено було побудувати систему пріоритетів у вигляді числових значень від 0 до 1, де найвищим пріоритетом мають звернення зі значенням пріоритету «1». Вони повинні бути оброблені в першу чергу. Відповідно значення «0» володіє найменшим пріоритетом і потрапляє в поле зору інженера технічної підтримки тільки після обробки всіх більш значущих заявок. Загальна схема виглядає наступним чином:

image

Як бачимо, за базис пріоритету обігу були прийняті існуюча система SLA та особливі джерела надходження заявок. У нашої компанії є три типи контрактів технічної підтримки, які пропонують замовникам різні SLA. Кожен з таких контрактів отримав своє базове число. Це ж стосується і джерел надходження заявки. При цьому система автоматично проставляє більш високий пріоритет при виборі з двох базових. А далі почалося найцікавіше. Базові значення ніяк не враховують всі можливі нюанси в роботі технічної підтримки.

Наведу приклад:

Дуже великий і неймовірно важливий замовник написав нам на пошту з пропозицією змінити піктограму в інтерфейсі. Як нам вчинити? Чи повинні ми терміново кинути всі сили на пошук недбайливого дизайнера, намалювала таку огидну піктограму, змусити його/її негайно все переробити, затвердити макет, напружити технічний департамент і без зволікання випустити хотфикс для цього замовника?

В цей же час менш великий клієнт відчуває серйозні труднощі з продуктом, з-за яких у нього фактично зупинився бізнес, і направляє запит в нашу службу підтримки.
Чи слід нам знизити в пріоритеті перший запит і допомогти другому клієнтові, нехай і не такому великому і неймовірно важливого, але чия проблема стоїть більш гостро?

Погодьтеся, маючи в арсеналі лише обмежену кількість ресурсів, неможливо бути доступним на першу вимогу відразу для всіх бажаючих. І переважна більшість замовників-це прекрасно розуміють. Не стане навіть самий великий і важливий замовник наполягати на негайному вирішенні питання з негарною піктограмою, так як це лише дрібне незручність, а не реальна проблема, що перешкоджає нормальній роботі. Тому розміщення правильних пріоритетів в умовах обмежених ресурсів дуже важлива. Не менш важлива акуратність і простота цього механізму.

Відштовхуючись від цієї логіки, ми доповнили базову систему пріоритезації певними коефіцієнтами, що активізуються в різних ситуаціях:




Тобто кінцева формула виглядає так:

Базовий показник + плаваючий показник = Підсумкове значення пріоритету.
Спробую для наочності провести розрахунок за наведених раніше прикладів.

Для прикладу №1 розрахунок виглядає так:

Premium SLA + Передпродажна ескалація + Постпродажная ескалація + Вага організації*кількість користувачів більше 10000 + Серйозність проблеми * побажання по функціональності + тривалість роботи = 0.07+0+0+0.03*0.38+0.56*0.02-0 = 0.07+0.0114+0.0112 = 0.09 Як бачите, підсумковий показник пріоритету досить низький, незважаючи на пристойні ввідні дані (Premium підтримка, великий клієнт).

Для прикладу №2 розрахунок виглядає так:

Extended SLA + Передпродажна ескалація + Постпродажная ескалація + Вага організації*кількість користувачів 100 + Серйозність проблеми * Критична проблема + тривалість роботи = 0.04+0+0+0.03*0.03+0.56*0.42=0.04+0.0009+ 0.24=0.28 Тут ситуація зворотна. Незважаючи на те, що організація зовсім не велика і має більш скромний контракт на технічну підтримку, з-за високого рівня важливості проблеми значення пріоритету заявки перевищує заявку з прикладу №1.

Тобто, маючи в своєму арсеналі весь набір необхідних даних, система автоматично підняла більш критичну проблему від невеликої організації над низькопріоритетною, незважаючи на більш високий вагу першого замовника. Система вміє автоматично перераховувати пріоритет заявки з дев'яти різних параметрах, підвищувати базовий показник пріоритету з 18 допомогою різних коефіцієнтів, тим самим збільшуючи або зменшуючи базове число пріоритету. Цей показник не є статичним. Він змінюється при появі нових даних в класифікації обігу і миттєво змінює розташування заявок в черзі на обробку. Це дозволяє нам розподіляти заявки саме в тій черговості, в якій їх необхідно обробляти.

image

Ось так тепер виглядає чергу звернень для інженера технічної підтримки. Більше немає необхідності з'ясовувати пріоритет заявки. Інженери технічної підтримки просто обробляють заявки зверху вниз у порядку черги.

Як бачите, при створенні системи пріоритезації ми постаралися врахувати всі можливі нюанси, що виникають при обробці звернення: це і серйозність проблеми заявника, і SLA, який зафіксовано у договорі на технічне обслуговування, і різні види ескалацій і навіть тривалість роботи з поводженням з моменту його відкриття в нашій CRM-системі. А беручи до уваги те, що більшість цих параметрів проставляються автоматично, наші інженери більше не витрачають час на адміністрування пріоритету обігу та можуть сконцентруватися на вивченні проблеми замовника і вироблення рішень, бути на зв'язку з тими, хто гостро потребує термінової допомоги. Керівникам змін більше не потрібно постійно тримати в голові інформацію про всіх «особливих» заявках і вчасно реагувати на їх перевідкриття, а замовники можуть бути впевнені, що всі їхні звернення будуть оброблені в максимально стислі терміни і ніколи не зникнуть з поля зору технічної підтримки до їх повного дозволу.

Нова система впроваджена в нашій CRM і функціонує з початку грудня 2016 (51 тиждень). За час її пілотної експлуатації ми вже помітили зниження кількості ескалацій:



Уважний читач, безсумнівно, зверне увагу на те, що в поточній реалізації ніяк не враховується «Backlog». Вся справа в тому, що це вже наступний етап задуманої нами автоматизації. Як тільки механізм автоматичного розрахунку Бэклога буде готовий, ми додамо його в існуючу систему пріоритезації і заново перерахуємо коефіцієнти. Поки ж «стеження» за бэклогом здійснюється в ручному режимі. Опису механізму розрахунку бэклога буде присвячено окремий пост, після того як механізм буде повністю готовий і впроваджений.

Найближчим часом так само вийде стаття з докладним описом математичного апарату розрахунку коефіцієнтів описаного вище механізму пріоритезації.

За сім у мене все, буду радий поспілкуватися в коментарях.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.