Структура базы знаний, или как помочь клиентам читать статьи (часть 2)
Это вторая статья из обещанной пачки про базы знаний, в первой части (“Паттерны чтения, или как помочь клиентам читать статьи и документацию”) мы разбирались с содержанием статей, сейчас давайте разберёмся с общей структурой базы знаний 💪
Ссылку на видео с лекцией, на основе которой я написала эти тезисы, как обычно оставлю в конце.
Как понять, работает ли база знаний в принципе
Посмотрите на критерии ниже, каждый из них или несколько разом — сигнал, что база знаний не работает:
- Сотрудники прокачиваются, получают все новую экспертизу, а время решения вопросов не сокращается.
- База знаний растет, количество клиентов увеличивается, а вопросы от них всё те же.
- Вы сделали крутые онбординг-тренинги, но новенькие все равно буксуют.
- Только ограниченный круг людей пишет в базу знаний.
- Ни новые фичи, ни фикс багов не улучшают NPS продукта, либо улучшают его незначительно.
- Сотрудники и/или топ-менеджмент не понимают, зачем нужна база знаний.
Если вы увидели в списке что-то из ваших случаев, то откройте в соседней вкладке вот эту статью, где для каждого критерия расписаны решения, а мы пока что двигаемся дальше и смотрим на структуры баз знаний 👇
Подходы к структурированию базы знаний
- От частых вопросов
Анализируем тикеты по частоте и времени закрытия и выделяем самые часто задаваемые вопросы. - По смыслу
Пляшем от типичных задач или проблем пользователя.
Можно прямо вот пройти по по пользовательскому пути и протэгировать все тикеты в базе знаний по этапам этого пути. - От структуры продукта/проекта
Выделяем области продукта, ищем в компании эксперта по ним, начинаем донимать его вопросами, а потом делаем N разделов в базе знаний. - От роли пользователя
- От платформы (мобильные приложения)
- От версии ПО
Подходы можно совмещать, например, в базе знаний LinkedIn в поиск есть большие разделы (структурирование “от продукта/проекта”), а есть shortcuts и recommended topics (структурирование “от частых вопросов”):
Структура главной страницы и вложенности статей
- Древовидная / иерархия
Не рекомендуется больше 3 уровней вложенности - Тематические категории
- Топики
В одной статье собираем несколько разделов, например, замена батарейки и утилизация - Микс из разных подходов
Например, у Finom есть глобальное разделение (общие вопросы и вопросы владельцев бизнес-аккаунтов), а внутри — суб-разделы с ответами на популярные вопросы.
Получается как раз 2 уровня вложенности:
У Carrot Quest на главной странице тематические категории:
Жанры статей в базе знаний
Здесь нам на помощь придёт фреймворк Diataxis, согласно которому вс документация делится на 4 вида и каждый вид решает разные задачи пользователей. Это может быть справка, инструкция, обучающее видео и т.п.
Чтобы не потонуть на схеме выше, возьмём пример с велосипедами. Сравните верхнюю и нижнюю картинки: согласно фреймворку, у нас будет tutorial (который научит кататься), общее объяснение (например, как работает баланс при езде на велосипеде), практический how-to guide (например, как заменить деталь) и некоторое количество референсов (например, какие запчасти могут понадобиться и где их достать).
💡 Самый важный аспект: целеполагание статей
Перед написанием любой статьи, надо ответить на вопросы ниже. Без ответов на них статья бессмысленна и её будет тяжело (да и незачем) поддерживать в актуальном состоянии:
- кто читатель
- его задача / боль
- как он будет читать
(помимо пресловутых паттернов чтения статей клиентами, сюда же относятся все важные аспекты, например, что ваши клиенты в 90% случаев читают статьи с телефонов, а не с больших мониторов) - какая задача/боль бизнеса
От себя могу добавить, что это супер-важный аспект, я уже наступала в прошлом на грабли, что я писала статьи в базу знаний техподдержки, не имея чёткого понимания, какую клиентскую боль или боль бизнеса я этой статьёй закрываю, такое себе удовольствие! 🤔
Бонусные статьи в тему 🔥
Ссылка на видео:
