Програмне забезпечення служби підтримки: створіть надійний процес обробки заявок
Програмне забезпечення для служби підтримки найкорисніше тоді, коли воно підтримує зрозумілий спосіб роботи. Придбання інструмента не визначає, хто відповідає за запит, коли тікет має очікувати або що вважається вирішеним. Спочатку ці рішення має ухвалити ваша команда.
Цей посібник покаже, як розробити практичний робочий процес для тікетів на основі вашої наявної адреси електронної пошти служби підтримки. У ньому основна увага приділяється операційній моделі, а не порівнянню функцій. Якщо ви хочете побачити, як електронна пошта, призначення, статус, пріоритет, теги, нотатки та історія тікета поєднуються в одному продукті, перегляньте функції спільної скриньки та тікетингу Deskhero, виконуючи ці кроки.
Почніть із шляху, який має пройти запит клієнта
Перш ніж щось налаштовувати, накресліть стандартний шлях від надходження запиту до його вирішення. Корисна перша версія може бути простою: повідомлення надходить, хтось його переглядає, потрібна людина бере на себе відповідальність, команда виконує роботу, а клієнт отримує остаточну відповідь.
Потім перелічіть винятки, які регулярно порушують цей шлях. Питання щодо оплати може потребувати залучення іншої команди. Технічна проблема може вимагати розслідування. Клієнт може припинити відповідати. Два повідомлення можуть описувати одну й ту саму проблему. Ці випадки покажуть, які статуси, передавання відповідальності та запобіжні заходи потрібні вашому робочому процесу.
Зосередьте карту процесу на рішеннях. Для кожного етапу дайте відповіді на такі запитання:
- Хто відповідає за наступну дію?
- Яка інформація має бути наявною, перш ніж тікет перейде далі?
- Що має відбутися, якщо відповідальна особа недоступна?
- Як інший User може зрозуміти поточний стан, не просячи короткого підсумку?
- Яка подія означає, що запит справді завершено?
Робочий процес є ефективним, коли будь-який User може відкрити тікет і зрозуміти, що сталося, що відбудеться далі та хто відповідає за наступний крок.
Використовуйте невеликий набір статусів із точними значеннями
Назви статусів часто здаються очевидними, але різні команди тлумачать їх по-різному. Визначайте кожен статус за тим, хто має виконати наступну дію. Це просте правило допомагає уникнути багатьох тікетів, що зависають.
| Призначення статусу | Використовуйте його, коли | Хто діє далі |
|---|---|---|
| Нова робота | Запит надійшов, але його ще не переглянули | Команда, яка обробляє вхідні запити |
| Активна робота | User досліджує питання або готує відповідь | Призначений User |
| Очікування | Команді потрібна інформація або дія від клієнта чи іншої сторони | Вказана зовнішня сторона, а всередині команди — відповідальний за подальші дії |
| Вирішено | Команда виконала запитувану роботу та надіслала результат | Ніхто, якщо тільки клієнт не відповість |
Не створюйте окремий статус для кожного відділу, теми чи рівня терміновості. Для відповідальності використовуйте призначення або групи, для тем — теги, а для терміновості — пріоритет. Коли кожне поле має одне призначення, Users можуть однаково читати чергу.
Розділяйте відповідальність, пріоритет і класифікацію
Ці три поняття відповідають на різні запитання. Відповідальність показує, хто має діяти. Пріоритет — наскільки швидко потрібна увага. Класифікація — про який тип запиту йдеться. Їх змішування створює нечіткі черги та ненадійні звіти.
Призначайте відповідальним одного User або групу
Кожен відкритий тікет має мати очевидного відповідального. Спільна відповідальність легко перетворюється на відсутність відповідальності. Група може отримувати нову роботу, але щойно робота розпочинається, її має перебрати конкретний User. Визначте правило заміни на час відсутності та правило передавання відповідальності, коли потрібна інша експертиза.
Визначайте пріоритет за умовами, які можна спостерігати
Формулюйте правила пріоритету простою мовою. Наприклад, збій, що впливає на багатьох клієнтів, має мати вищий пріоритет, ніж загальне запитання. Не дозволяйте перетворювати пріоритет на спосіб позначати кожен нетерплячий запит як терміновий. Коротке письмове визначення дає Users обґрунтування, якого вони можуть послідовно дотримуватися.
Використовуйте теги для майбутніх дій, а не для оздоблення
Створюйте тег лише тоді, коли він допомагає команді спрямувати роботу, знайти корисний сегмент або відповісти на повторюване запитання. Періодично переглядайте теги та об’єднуйте майже однакові. Менший словник створює чистіші подання й надійніший аналіз.
Проєктуйте передавання відповідальності зі збереженням контексту
Передавання відповідальності має змінювати відповідального, не змушуючи наступного User відновлювати історію справи. Зберігайте відповіді клієнтам і приватні нотатки на часовій шкалі тікета. Перед передаванням додайте поточний висновок, питання, яке залишається, і наступну очікувану дію.
Використовуйте внутрішні нотатки для співпраці, яку не слід надсилати клієнту. Надсилайте відповідь клієнту, коли потрібно підтвердити отримання, запросити інформацію або пояснити затримку. Це розмежування робить розмову зрозумілою та надає колегам потрібний контекст.
Коли два тікети стосуються однієї проблеми, визначте, який запис є основним джерелом інформації. Об’єднайте дублікат з основним тікетом, а потім продовжуйте роботу в одному місці. Паралельні записи сприяють суперечливим відповідям і розділяють історію.
Додавайте цільові показники обслуговування після стабілізації робочого процесу
Цільові показники не можуть виправити нечітку відповідальність. Спочатку переконайтеся, що нову роботу переглядають, призначення є видимими, а для тікетів в очікуванні існує шлях подальших дій. Потім визначте очікування щодо відповіді та вирішення з урахуванням годин, у які ваша команда фактично працює.
Слідкуйте за тікетами, які наближаються до цільового показника, а не лише за тими, що вже його порушили. Мета — спонукати до дії, поки час ще є. Політики SLA Deskhero підтримують цільові показники першої відповіді та вирішення, розклади робочих годин, фільтри, сповіщення та подання на інформаційній панелі.
Перевірте робочий процес на реальних сценаріях
Перш ніж запроваджувати процес, пройдіть типові запити крок за кроком. Додайте просте запитання, запит, у якому змінюється відповідальний, випадок очікування відповіді від клієнта, дублікат і повторно відкриту розмову. Для кожного сценарію перевірте, чи залишаються очевидними наступна дія та відповідальний.
Проводьте тестування з Users, які не розробляли робочий процес. Якщо їм потрібні усні пояснення, правила або назви полів ще недостатньо зрозумілі. Скоригуйте процес, а потім повторіть сценарії.
Під час упровадження ведіть короткий журнал винятків. Записуйте ситуації, у яких Users не знають, який статус, відповідального або пріоритет обрати. Регулярно переглядайте цей журнал і змінюйте робочий процес лише тоді, коли з’являється повторювана закономірність. Це не дасть системі накопичити одноразові правила.
Вимірюйте рух роботи, а не активність заради самої активності
Корисні звіти мають показувати, де клієнти очікують, а де робота зупиняється. Почніть із кількості тікетів, часу до першої відповіді, часу до вирішення, віку черги та повторно відкритих запитів. Аналізуйте тенденції та сегменти, а не сприймайте одне середнє значення як повну картину.
Пов’язуйте кожен показник із рішенням. Зростання кількості старих тікетів у черзі може вимагати чіткішого розподілу відповідальності або збільшення ресурсів. Повільні перші відповіді можуть свідчити про недостатнє покриття обробки вхідних запитів. Часті повторні відкриття можуть вказувати на неповне вирішення або незрозумілі відповіді. Для детальнішого плану вимірювань перегляньте наш посібник із показників звітності служби підтримки.
Переглядайте робочий процес, коли дані показують повторюване вузьке місце. Не додавайте поля або кроки просто тому, що програмне забезпечення це дозволяє. Найкраще налаштування служби підтримки — це найменша система, яка надійно робить видимими відповідальність, контекст і наступні дії.
Практичний контрольний список упровадження
- Складіть карту стандартного шляху запиту та поширених винятків.
- Визначте кожен статус за тим, хто має виконати наступну дію.
- Розділіть відповідальність, терміновість і класифікацію за темою.
- Задокументуйте, що має містити повне передавання відповідальності.
- Перевірте робочий процес на реалістичних сценаріях підтримки.
- Додайте цільові показники обслуговування після того, як маршрутизація та відповідальність стануть надійними.
- Оберіть невеликий набір показників, пов’язаних з операційними рішеннями.
- Переглядайте винятки та спрощуйте правила, які Users застосовують непослідовно.
Щойно ці рішення буде записано, налаштування стане значно простішим. Ваш інструмент має робити узгоджений процес видимим і повторюваним, водночас залишаючи достатньо гнучкості для нестандартних випадків.