Пов’яжіть описаний симптом із перевіркою для конкретної моделі, зрозумілим результатом і повним передаванням запиту до підтримки.
Інтерактивний посібник ставить доречні запитання та пов’язує кожну відповідь із затвердженим наступним кроком. Спершу він визначає продукт і спостережуваний симптом, показує відповідні перевірки й фіксує, чи проблему розв’язано, чи потрібна допомога фахівця.
Покроковий процес не повинен обіцяти розв’язання для кожної ситуації. Якість залежить від процедури-джерела, цільового користувача та того, наскільки добре враховано невизначеність.
Зафіксуйте модель, варіант, потрібну версію та точний текст повідомлення на екрані, якщо він є. Розрізняйте початкове налаштування, звичайне використання й проблему після обслуговування чи заміни. Навіть однаковий симптом може потребувати різної документації залежно від початкових умов.
Запитуйте про те, що користувач може надійно побачити чи повідомити, а не вимагайте діагностувати компонент. Відокремлюйте спостереження від дії. Зазначайте, що саме підтверджує кожна відповідь і яка затверджена перевірка йде далі. Якщо користувач не може відповісти, передбачте корисний маршрут для невизначеного випадку.
Для кожної перевірки вкажіть джерело, потрібну роль, очікуваний результат і дозволену наступну дію. Використовуйте фото, схему чи інтерактивний ракурс, щоб пояснити, на що дивитися. Дотримуйтеся вимог виробника щодо доступу й ізоляції обладнання; процес для клієнта не має непомітно перетворюватися на ремонтну процедуру для техніка.
Приклад процесу: спершу визначається модель приладу й точне спостереження користувача, а потім наводяться відповідні перевірки з посібника власника. Якщо симптом не відповідає жодній підтримуваній гілці, процес збирає текст повідомлення та контекст налаштування для сервісної служби. Лише за симптомом він не діагностує несправність електричного компонента.
Додайте ідентифікацію продукту, симптом, версію джерела, виконані перевірки, спостережувані результати й потрібні докази. Розрізняйте успішну перевірку та перевірку, яку користувач не зміг виконати. Поясніть, яка команда отримає проблему та що відбудеться далі за реальним процесом підтримки.
Перевірте типовий випадок, незрозумілу відповідь, непідтримувану модель і завдання поза межами процесу. Переконайтеся, що кожна гілка завершується затвердженим результатом або передаванням фахівцю. Аналізуйте повторювані тупикові гілки й результат завдань, а не вважайте кількість повідомлень чатбота показником успіху підтримки.
Оберіть типовий симптом із затвердженою відповіддю.
Попросіть відповідального за джерело перевірити кожну гілку.
Перевірте, чи можна визначити пріоритет невирішених випадків.
Дерево рішень задає логіку розгалуження. Повний посібник також містить контекст продукту, відповідні зображення, перевірки на основі джерел, спостережувані результати й маршрут передавання запиту.
Використовуйте затверджені гілки для процедурних рішень. Розмовний помічник може пояснити або знайти інформацію, а непідтримувані запитання мають надходити до відповідного процесу підтримки.
Структуру можна повторно використовувати. Конкретні перевірки й дозволені ролі мають визначатися відповідною документацією продукту.
Відстежуйте задокументовані вирішення, належні передавання фахівцям і запити, що потребують уточнення. Сам факт відвідування сторінки не доводить, що несправність усунуто.
Надішліть наявну затверджену інструкцію, схеми або фотографії. Замовте безкоштовну демонстрацію, щоб команда перевірила одне завдання для продукту, перш ніж вирішувати, як розширювати проєкт.
