Руководство пользователя: как повысить ценность продукта и сэкономить на техподдержке

Ценность продукта для клиента – один из важных критериев для построения эффективного и успешного бизнеса. Но даже идеальный с точки зрения пользовательских характеристик продукт может провалиться на рынке, если у него нет качественной технической и сервисной поддержки. Один из ключевых элементов такой поддержки – грамотная справочная документация. О том, как повысить ценность IT-продукта с помощью руководства пользователя, в своей авторской статье для портала Biz360.ru рассказал основатель компании «Индиго Байт» Денис Журавлёв.

Сразу хочу задать несколько вопросов уважаемым читателям:

• Как вы считаете, что делает ваш продукт ценным в глазах клиента?

• За что пользователь ценит и любит ваш продукт?

• Что должно произойти, чтобы клиент посоветовал воспользоваться вашей программой или сервисом своим коллегам и друзьям?

В случае с программным обеспечением – это и приятный, продуманный до мелочей интерфейс, и скорость работы, и производительность, т.е. возможность быстро и качественно делать в программе то, для чего она предназначена.

Но дело не только в продукте. За любой разработкой стоит команда, а в ней большую роль играет отдел техподдержки. Именно поддержка общается с клиентами и решает их проблемы, являясь, по сути, лицом компании.

Если у пользователя возникла проблема, единственное, что ему важно - быстро получить предметный ответ на волнующий его вопрос, понятное и максимально простое решение. Вот он – аспект, который прямо не относится к продукту, но влияет на его ценность – сервис.

А что, если клиенты изо дня в день заваливают техподдержку вопросами, из-за чего команда может не справляться с потоком и, соответственно, отвечает медленнее, реже и менее компетентно? Как следствие, падает качество обслуживания, а с ним и ценность продукта в восприятии клиента.

Кроме того, большая загрузка техподдержки – это ещё и прямые затраты на оплату рабочих часов специалистов, оплату входящих звонков, если вы используете номер 8-800, оплату более дорогих планов helpdesk-систем.

В таких случаях любой специалист (да и неспециалист) скажет, что необходимо оптимизировать временные затраты поддержки на консультирование клиентов и минимизировать количество повторений ответов на одни и те же вопросы. Но как это сделать? 

Понятно, что нужно работать и с самим продуктом, улучшая его дизайн и UX-факторы. Но что делать, если проблемы в самом продукте не очевидны, а запросы в поддержку продолжают поступать?

И тут на помощь может прийти качественная пользовательская документация.

Есть устойчивый миф, что в наше время сопроводительную документацию никто не читает. Могу с уверенностью сказать – это не так.

Пользователь – ленив, и это факт. Задыхающийся от информационного шума современный человек никогда добровольно не откроет руководство пользователя и не прочитает, что там написано. Но только до тех пор, пока он не столкнётся с проблемой!

Если перед человеком стоит задача получить определённый результат в вашей программе, он постарается её выполнить, даже если упрётся в трудности. Преодолеть возникшие трудности он сможет тремя путями:

1. Загуглить вопрос в открытых источниках – на профильных сайтах, в Youtube, на форумах;

2. Читать документацию – в самом программном продукте или на сайте;

3. Обратиться в поддержку – по email или телефону.

Наш опыт показывает, что клиенты (а особенно IT-шники и иже с ними) в первую очередь попытаются самостоятельно найти ответ на свой вопрос первыми двумя способами. И это очень удачная для нас, как для владельцев бизнеса, ситуация. 

Почему? Потому, что в обоих случаях клиент получает решение своей проблемы самостоятельно, не вовлекая в это ресурсы компании и уберегая нас от переменных затрат на обслуживание его запроса. 

Следовательно, мы просто обязаны сделать так, чтобы большинство проблемных сценариев закрывались клиентом самостоятельно. Самообслуживание – путь к масштабированию бизнеса. 

Снабжая программный продукт или сервис качественной контекстной помощью, а также публикуя пользовательскую документацию на сайте, мы резко повышаем долю клиентов, которые решат свои проблемы самостоятельно. Даже те, кто не обратятся к документации напрямую, а пойдут вводить свои запросы в поисковик, с большой долей вероятности будут приведены поисковиком именно на страницы вашей онлайн-справки. Конечно, для этого она должна существовать, быть хорошо структурированной, открытой для индексирования поисковиками и содержать описания искомых решений.

В поддержку же обратятся только те, кто не захотел или не смог найти ответ в файле справки или онлайн-руководстве. Но их будет уже существенно меньше, поэтому их запросам техподдержка сможет уделить больше внимания и ответить им более фокусно – т.е. дать им именно ту ценность, за которой они пришли. И эта ценность будет ассоциироваться с вашим продуктом.

Мы собрали под сотню кейсов наших клиентов, пользователей продукта Dr.Explain, со всего мира – и все пользователи отмечают, что создание и публикация документации позволили им повысить качество клиентского сервиса и ценностного восприятия их продуктов, а так же снизить нагрузку на техподдержку кратно! Вы можете ознакомиться с этими кейсами на наших российском и англоязычном сайтах.

Итак, делаем вывод, что пользовательская документация – это способ повлиять на значимость и ценность продукта и на расходы компании.

Однако, это влияние может быть как в хорошую, так и в плохую сторону. Так что делает документацию качественной?

Выделю три самых важных фактора, при наличии которых пользовательская документация является эффективной с точки зрения решения задач бизнеса:

1. Структурированность.

2. Многоформатность и доступность.

3. Качество контента.

Фактически, дальнейший текст можно считать чек-листом для создания хорошей документации.

Представьте, что вы работаете в сложной профессиональной программе и, поэтапно продвигаясь, решаете свою задачу. Где-то в середине процесса сталкиваетесь с незнакомой настройкой или неожидаемым поведением программы. Вызываете файл справки или открываете онлайн-инструкцию, а там – длинная «простыня» сплошного текста, изредка перемежаемого подзаголовками, либо есть несколько крупных разделов с нечёткой логикой изложения материала.

Найти что-то конкретное в подобной документации – ещё та задача, которая займёт много времени и совсем не порадует пользователя. Минус балл к ценности продукта.

Надо понимать, что читать документацию будут люди, а не роботы, которые к тому же вряд ли на сто процентов знакомы с программой и даже предметной областью. Человеку невероятно сложно разобраться в плохо структурированном тексте, написанном повествовательным тоном, без информативных названий разделов, подзаголовков, иллюстраций и визуальных якорей.

Наша задача – максимально облегчить людям доступ к вспомогательной информации и её усвоение.

Совет №1: структурируйте руководство пользователя под задачи пользователя

Поставьте себя на место пользователя и представьте его путь выполнения разных задач в вашей программе – что он будет делать в первую очередь, что во вторую и так далее. Используйте этот путь (customer journey) как основу для структуры документации. Для построения customer journey map очень полезно общаться с реальными пользователями и понаблюдать за их работой с вашим продуктом.

Совет №2: нарезайте контент на разделы

Если документация правильно поделена на разделы, то её проще писать и обновлять, она лучше индексируется поисковиками, с ней удобнее работать не только вашим пользователям, но и сотрудникам техподдержки. Если каждый узко-тематический раздел оформлен отдельной страницей и имеет свой адрес, поддержке очень удобно давать ссылку на такой раздел документации в переписке или чате.

Совет №3: делайте помощь контекстно-зависимой

Совет из разряда профессиональных – связать конкретные элементы интерфейса программы или веб-сервиса с соответствующими разделам в документации. Таким образом, вы создадите контекстно-зависимую справку.

• Пример: если вы работаете в нашем продукте для создания пользовательской документации и зайдёте в настройках проекта в раздел «Аннотирование экрана», вы увидите там целый набор опций: стили аннотации, тени, фон, эффекты и так далее. Предположу, что вы можете не знать ничего об аннотации скриншотов вообще. Однако, при нажатии клавиши F1 или кнопки «Помощь» перед вами открывается руководство пользователя именно на том разделе, где рассказано об процессе аннотирования экранов приложения в документации.

Удобно, не правда ли?

Уверен, что вы и сами хотя бы раз пользовались контекстной справкой в каких-то программных продуктах. Чёткое попадание в контекст человека гарантирует дофаминовый ответ в его мозгу и плюс балл к ценности продукта.

За 20 с лишним лет работы в сфере проектирования и разработки ПО, я регулярно сталкиваюсь с ситуацией, когда справку по продукту тяжело найти или её просто нет в нужном формате – подходящем для распечатки или, наоборот, для работы в контексте продукта.

Пользователь всегда должен иметь доступ к документации – и не важно, работает он сейчас с продуктом или нет. Отсюда – следующая рекомендация.

Совет №4: предоставьте пользовательскую документацию в различных форматах

Выложите инструкцию на сайт, интегрируйте её в продукт в виде файла помощи и создайте печатную PDF-версию, чтобы пользователь мог скачать её, переслать коллеге или распечатать.

Другая проблема – доступность: справка может быть написана, но найти её – отдельная задача.

Совет №5: сделайте информацию легко находимой и доступной

Разместите ссылку на руководство в меню сайта так, чтобы она была доступна с любой страницы, и добавьте кнопку «Помощь» в интерфейс вашего приложения, желательно на всех значимых экранах.

Совет №6: в документации должны быть описаны все элементы интерфейса и все типовые сценарии, с которыми может столкнуться пользователь

Разделы документации должны отвечать на два типа вопросов – «Что я сейчас вижу перед собой?» и «Как мне сделать…». Документация должна описывать и сам продукт, и задачи, которые с его помощью можно решить. Очень часто разработчики забывают либо первую часть, либо вторую.

Совет №7: не допускайте ошибок и не нарушайте единства стиля

Проверьте весь контент на отсутствие ошибок и используйте единый стиль оформления текста, заголовков, иллюстраций, врезок и навигации. Ничто так не портит впечатление, как неряшливость и недоделки по мелочи.

Совет №8: руководство должно быть максимально простым и ёмким

Стиль изложения должен быть максимально простым, а текст – «обезвоженным». Используйте простые директивные предложения и фразы, не допускающие двусмысленных трактовок. Терминология в идеале должна быть понятна даже неопытному пользователю, а не только разработчику.

Совет №9: обязательно визуализируйте информацию

Помните про немаловажный фактор, влияющий на качество справки – достаточное количество иллюстраций, скриншотов, схем и видео. Как говорится, лучше один раз увидеть, чем сто раз услышать.

Сложные иллюстрации снабжайте аннотациями и подписями. Учтите это, потому что пользователю будет гораздо приятнее работать с документацией, если в ней все наглядно показано. А наличие видео ускорит процесс решения проблемы для пользователя и точно добавит ценности вашему продукту.

В завершении хочется отметить, что данная статья основана на опыте общения с нашими пользователями, работающими в программе Dr.Explain – инструменте для создания руководств пользователя и баз знаний. Все вышеуказанные рекомендации изначально заложены в концепция программе Dr.Explain, которая минимизирует рутину и делает процесс создания руководств и инструкций проще и удобней.

Спасибо за внимание и удачи в бизнесе!

Чтобы не пропустить интересную для вас статью о малом бизнесе, подпишитесь на наш Telegram-канал, страницу в «ВКонтакте» и канал на «Яндекс.Дзен».
biz360