Итак, в предыдущей статье мы начали работу с сообщениями в продукте, позволяющую быстро и точно выяснить, какие ошибки и предупреждения наиболее часто видит пользователь. Что, в частности, позволяет выловить и починить плохо поддающиеся воспроизведению по команде проблемы вроде таймаутов или злоупотребления кнопкой 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 свеженькую статью с инструкцией по починке, и техподдержка вздыхает с облегчением. Когда же проблема исчерпала себя, другой командой на веб-сервере под ссылку возвращается ее привычная основная статья.
И еще
Использование такой системы подразумевает довольно пристальное наблюдение за задействованными в ней статьями: поскольку они автоматически превращаются в наиболее посещаемые, их лучше бы держать в тонусе, обновлять, полировать и всячески наводить лоск. Но та же система помогает и делать это. Практически все программы для техподдержки позволяют ассоциировать статьи из баз знаний с заявками от пользователей. Просмотрев заявки, ассоциированные с определенной статьей, можно понять, как и почему в этой ситуации пользователь вообще пришел в техподдержку: не заметил ссылку? не смог применить описанное решение? оно не сработало? – и тут же принять меры.
Таким образом, ценой небольшого одноразового усилия все участники процесса, от программистов до пользователей, могут сэкономить немало времени, денег и нервов, а также сделать для себя множество полезных выводов.
