Битва екстрасенсів в технічній підтримці, або як допомогти користувачеві правильно проставити пріоритет інциденту

Користувач Василь звертається в техпідтримку «Не виділяється номер при реєстрації документа помилка 1234, для виправлення доводиться перезапускати службу сервера додатків. Помилка виникла 05.05 приблизно в 15:10-15:50. Вплив інциденту: Знижена ефективність роботи користувачів».

А насправді Василь не сказав, що перезапуск сервера додатків призводить до помилок при оновленні користувальницьких онлайн звітів у всіх працівників компанії. Іншими словами, один користувач може подивитися актуальні онлайн звіти за існуючими документами, що рівносильно зупинці документообігу в компанії в принципі. Виходить, Василь не дав необхідної інформації для того, щоб його зверненням присвоїли правильний пріоритет – і це незважаючи на те, що у нього була така можливість. І, якщо реальний пріоритет нижче заявленого — це не так страшно, то в протилежному випадку це може мати небезпечні наслідки. У зв'язку з чим закономірною постає питання: як дізнатися, що хотів донести користувач, але з якоїсь причини засоромився і в останній момент повідомив зовсім інше?



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

Звичайно, служба техпідтримки формулює ці правила у формі відкритої оферти, але хто її читає?.. Будь-який співробітник технічної підтримки напевно стикався з ситуацією, коли користувач мав на увазі зовсім не те, що повідомив при зверненні. З неправильною пріоритезації інцидентів користувачами я зустрічаюся на практиці настільки часто, що бачу підстави виділити це в якості проблеми. На моїй практиці приблизно в кожному 3 інцидент з'ясовується, що пріоритет повинен був бути іншим.

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



Після введення даної форми в експлуатацію, створених інциденти користувачі почали надавати значно більше інформації ніж раніше. А іноді навіть прикладали необхідні логи для аналізу проблемної поведінки, що безсумнівно великий плюс! Але, що нас, все ще не задовольняє в знайденому нами рішення, так це те, що чимала кількість користувачів ставлять ознаки неправильно, внаслідок чого отримують некоректний пріоритет в інциденті. Що саме по собі закладена бомба ескалації з темою (цитую) «У мене все горить, а техпідтримка вирішує мій інцидент повільно!!!111».

Чому відбувається так, що користувачі ставлять неправильно ознаки, що безпосередньо впливають на проставлення пріоритету? Після аналізу низки інцидентів стало зрозуміло, що люди не завжди розуміють взаємозв'язок інформації, яку вони дають, та пріоритету, який після проставляється в інциденті. І що з цим робити?

Панацея?
Чи є панацея, яка могла б допомогти в таких випадках? Які є ще варіанти уникнути такого непорозуміння?

  • Найняти 100500 фахівців 1 лінії, які разом з користувачем будуть створювати кожен інцидент, задаючи йому правильні навідні запитання, інтерпретувати відповіді, проставляти правильні ознаки для визначення пріоритету – ефективно, але невигідно.

  • Зобов'язати компанії, користувачі якої звертаються до вас за техпідтримкою, навчати своїх колег премудростям повідомлення в інцидентах необхідної інформації, яка безпосередньо впливає на виставлення пріоритету. Варіант, як мені здається, непоганий у теорії. На практиці нам поки такого реалізувати не вдалося.

  • Задати ліміт на створення інцидентів з можливістю самостійно проставляти високий пріоритет. При цьому кожне наступне звернення, створене понад ліміт, йде з додаткової вартості. З одного боку, це змусить колег більш уважно ставитися до наданої інформації про критичність і терміновості впливу інцидентів на роботу, з іншого боку, це може спонукати питання на кшталт «А чому ми повинні платити гроші за баги у вашому продукті?». Варто додати, що така практика — не вигадка, я сам з нею зустрічався, правда, в зарубіжних компаніях.
Ми поки не знайшли панацею, яка б дозволила нам уникнути цього впливу «людського фактору» і випливає з нього неоптимальною витрати ресурсів – як наших, так і користувача.

Цікаво, стикаються з проблемою виставлення коректного пріоритету інші компанії і які рішення ви зустрічали?
Джерело: Хабрахабр

0 коментарів

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