Предотврати це: полегшуємо життя клієнта і собі заодно

imageОтже, у попередній статті ми почали роботу з повідомленнями в продукті, що дозволяє швидко і точно з'ясувати, які помилки і попередження найбільш часто бачить користувач. Що, зокрема, дозволяє виловити і полагодити погано піддаються відтворенню по команді проблеми начебто таймаутів або зловживання кнопкою Cancel. У цій же статті ми поговоримо про те, як донести до користувача і рішення проблеми до того, як він звернеться в техпідтримку – благо, для цього нам знадобиться зовсім небагато: наявний реєстр повідомлень, база знань і одна невелика зміна в GUI.

Пункт перший: допрацьовуємо реєстр повідомлень
Учасники: аналітик, головний по базі знань.

Припустимо, що реєстр повідомлень ми спорудили ще в попередній раз, і тепер всі наші APP_ERR і APP_WARN стрункими рядами розгорнуті в ексель. До кожного з повідомлень генеруємо посилання виду yourdomain.com/app_err_1 і далі. Потім ловимо людини, відповідального за базу знань, і запитуємо, що він може нам запропонувати. Як показала практика нашої компанії, приблизно 70% повідомлень закривається вже існуючими статтями, написаними за матеріалами звернень в техпідтримку. Над рештою доведеться подумати, але, як правило, по кожному попередженню або помилку в результаті знаходиться що сказати.

Отже, до списку повідомлень з короткими описами контексту і нашими новенькими посиланнями додається ще один стовпець: посилання на відповідні до нагоди статті.

Пункт другий: реалізація
Учасники: аналітик, продуктовий програміст, головний по веб-сервера.

Час пускати в справу обидва набору посилань. Той з них, який yourdomain.com/app_err_1, вставляємо у власне повідомлення від продукту – під слова «Read more», наприклад, або «Help me fix the problem». Другий набір – реальні посилання на статті – буде працювати перенаправленням для першого, під яким на сервері не лежить ніяких реальних сторінок.

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

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

Ця ж система відмінно підходить для екстрених повідомлень. Якщо що-то в програмі пішло не так, і мільйон користувачів у світі щодня отримує від вас помилку номер 125, однією командою на веб-сервері ви підкладаєте під yourdomain.com/app_err_125 свіженьку статтю з інструкцією з лагодження, і техпідтримка зітхає з полегшенням. Коли ж проблема вичерпала себе, іншою командою на веб-сервері посилання повертається її звична основна стаття.

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

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

0 коментарів

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