Считается, что пользователи не любят читать документацию и некоторые стартапы используют это убеждение как повод не тратить ресурсы на ее разработку и поддержание в актуальном состоянии. На самом деле, все работает немного не так — пользователи не читают документацию, пока у них не возникнет вопрос, который она могла бы решить. И если документации нет или она плохая, у бизнеса возникают проблемы. Основатель King Servers Владимир Фоменко рассказал «Роем!», как этого избежать.
Когда базы знаний нет
Простой пример: мало кто изучает руководство пользователя машины, пока им не понадобится понять, что за ошибка высветилась на приборной панели или как поменять пробитое колесо. И если в такой момент документация им не поможет или ее не будет, то человеку придется действовать дальше, в случае интернет проектов — звонить в службу поддержки.
Для бизнеса это плохо сразу по нескольким причинам. Во-первых, компания тратит ресурсы службы поддержки на решение вопроса, с которым пользователь мог бы справиться самостоятельно при наличии хорошей документации. Во-вторых, никто не любит тратить время впустую, и если человек искал ответ на вопрос, не нашел его и ему пришлось куда-то звонить, чего многие не любят делать, то это не лучшим образом повлияет на впечатление о продукте или услуге. Кроме того, бизнес упускает возможность не просто сэкономить ресурсы, но и использовать документацию как маркетинговый инструмент.
Когда мы только запустили наш проект, на нашем сайте было не так много документации, в результате чего тем пользователям, которые раньше не пользовались услугами аренды оборудования, было сложно разобраться с тем, что подойдет именно им, как они могли бы улучшить инфраструктуру и как правильно настроить имеющуюся. В итоге мы столкнулись с постоянно растущим количеством обращений в службу поддержки — число заявок быстро стало исчисляться сотнями в неделю, при том, что мы работаем не только на российском рынке и у нас немало и иностранных пользователей, которым нужно было отвечать на английском.
Какой должна быть база знаний
Впоследствии мы начали уделять больше внимания обучающему разделу и стали публиковать в нём статьи, в которых простым языком объясняется, как решить ту или иную задачу — от настройки файрволла iptables и создания инкрементных архивов данных до более подробного описания услуг, подходящих различным группам пользователей, вроде VDS-серверов для начинающих веб-мастеров или защиты от DDoS, актуальной для крупных проектов.
Это позволило постепенно решить описанные выше проблемы. В процессе составления собственной базы знаний мы изучали опыт и известных зарубежных проектов — например, Freshdesk, Kayako, Zapier и Wix. На основе полученных знаний и собственного опыта мы сформулировали несколько критериев, которым должна соответствовать хорошая база знаний.
Снижается нагрузка на службу поддержки
Пользователи расстраиваются, когда им не удается в чем-то разобраться. Есть те, кто при любом вопросе хватается за телефон и звонит в поддержку или пишет письмо, но многим людям проще разобраться самим и никого не беспокоить. Проработанная документация позволяет им почувствовать себя молодцом, который справился со сложностями. А когда продукт дарит позитивные эмоции, это хорошо.
И даже более важно то, что такие довольные пользователи не нагружают службу поддержки, а могли бы висеть на телефоне или забивать helpdesk-систему своими тикетами. В нашем случае, по мере того как самые популярные вопросы по настройке инфраструктуры и выборе услуг были закрыты обучающими статьями, число обращений в поддержку по несложным вопросам снизилось в среднем на 25%, хотя количество пользователей постоянно растёт.
Сокращает время на решения запроса
Кроме того, наличие базы знаний с ответами на наиболее популярные вопросы пользователей помогает быстрее обслуживать тех, кто все-таки обратился в поддержку. Часто в процессе обсуждений возникают дополнительные вопросы, ответы на которые уже описаны. Тогда сотруднику проще дать ссылку на нужную статью, чем тратить время на объяснения. К тому же, многие пользователи просто могут не найти нужную статью в базе знаний или FAQ самостоятельно. По нашей статистике, при работе с серверами на стандартной технической поддержки так происходит в 5−10% случаев, и здесь вопрос также решается простой отправкой ссылки.
Помогает и членам команды
Даже те, кто работают над продуктом, могут не знать всех его тонкостей. Никого же не удивит дизайнер Toyota, который не знает, как поменять шину на «Приусе», или разработчик Apple, который сходу не вспомнит, как добавить дополнительную раскладку клавиатуры. Помощь может понадобиться и сотрудникам компании, так что база знаний помогает быстрее обрабатывать обращения клиентов, ведь лучший вариант решения в ней уже есть.
Помогает в маркетинге
Команда сервиса Zapier поделилась своим опытом использования контента базы знаний в маркетинговых целях. Компания отправляет пользователям «подогревающие» письма, чтобы те работали с продуктом активнее. В какой-то момент маркетологи стали включать в такие послания и ссылки на самые популярные статьи базы знаний. Это позволяет компании решать многие вопросы, еще когда у пользователя не возникло реальных проблем.
Маркетинговое письмо сервиса Zapier со ссылками на контент базы знаний.
Как создать хорошую базу знаний
С тем, какой база знаний должна быть, все довольно просто. Но как сделать так, чтобы она соответствовала выбранным критериям? Вот несколько советов, которые помогут добиться хорошего результата.
Сначала нужно решить, о чем писать
Представители Zapier и Крис Галло из Highrise CRM советуют начать описывать в базе знаний самые очевидные вещи. Нужно пройтись по всем этапам работы с продуктом и выписать моменты, на которых пользователи могут столкнуться с трудностями. Если продуктом уже пользуются, то у службы поддержки уже должно быть представление о наиболее часто задаваемых вопросах.
В базе знаний должна быть структура
Любая документация эффективна только при наличии грамотной и корректной структуры. Если составители мануала к автомобилю забудут написать о том, что прежде чем откручивать колесо для замены шины стоит поднять автомобиль домкратом, то они рискуют получить очень недовольного клиента (а в худшем случае, — и судебный иск).
В базе данных проекта Smartsheet статья о создании новой таблицы расположена перед статьей о вставки в нее столбцов.
В нашей базе данных сначала идет общая информация о выборе , а уже затем описываются системы управления им и различные типы серверов для аренды.
Объяснять нужно все
Неважно, что именно описано в базе данных, документация должна быть ясной. Основатель проекта Fog Creek Software и известный программист Джоэль Спольски считает, что документация должна быть настолько понятной, чтобы «этого было достаточно для обучения людей, вообще незнакомых с областью применения продукта».
Поэтому в базе знаний стоит подробно остановиться не только на фактах о самом продукте, но и рассказать об области его применения. Спольски приводит в пример американский бухгалтерский сервис Quickbooks, в базе знания которого содержится не только информация о том, как генерировать отчеты и выставлять счета, но и о базовых подходах к бухгалтерии. Мы, в свою очередь, затрагиваем не только вопросы настройки серверов и построения инфраструктуры, но и — о том, зачем вообще нужны те или иные ее элементы, вроде CDN-сетей.
Нужно постоянно обновлять базу знаний
Если бизнес развивается, то ее продукты и услуги не стоят на месте, а значит, документация будет постепенно устаревать. Особенно это актуально для сферы IT, где за год компания может выпустить несколько версий одного решения. Если пользователь увидит статью с описанием интерфейса, который не соответствует тому, что он реально видит в продукте, это вряд ли ему понравится. Выпуск новых функций и услуг следует сопровождать и созданием соответствующей документации.
Для облегчения поддержания базы в актуальном состоянии следует создать правило, согласно которому информация в статьях базы знаний не может повторяться. Вместо этого в том месте, где хочется процитировать уже имеющуюся статью, нужно давать ссылку на оригинальный документ. В таком случае правки нужно будет вносить только в одном месте.
Нет предела совершенству
Даже самую лучшую базу знаний можно улучшить. Для этого нужно прислушиваться к клиентам — анализировать поступающие в службу поддержки тикеты и просто задавать прямой вопрос о том, помогла ли им конкретная статья. Если документация не решает проблемы максимального количества пользователей, ее стоит переписать.
Некоторые существующие движки баз знаний позволяют встраивать в статьи голосования о степени полезности или получать статистику о том, сколько тикетов в поддержку были созданы после безуспешного поискового запроса в базе знаний.
Заключение: полезные ссылки
В завершение — несколько полезных материалов, которыми мы вдохновлялись при создании своей базы знаний и написании этой статьи:
- Write the Docs Guide — руководство от сообщества экспертов по создании документации софта;
- Write articles for the Knowledge Base — советы по созданию статей базы знаний для Firefox от Mozilla;
- How to Build an Effective Support Knowledge Base: Everything You Need to Know about Documentation — подробное руководство от команды сервиса Zapier;
- 5 Best Practices for Keeping a Killer Knowledge Base — советы от сотрудников helpdesk-сервиса Kayako;
- 5 Tips for Building a Powerful Knowledge Base with Confluence — руководство Atlassian по созданию баз знаний на Confluence;
- The Power of An Effective FAQ Page (& How to Create One) — советы по разработке FAQ-страниц в блоге конструктора сайтов Wix.
