Структура базы знаний: разделы и пример

Кратко

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

Актуально на 23 сентября 2026 года.

Эта статья — про то, как разбить базу знаний на разделы. Как собрать саму базу и с чего начинать писать статьи, разобрано отдельно: Что такое база знаний службы поддержки и как её собрать.

Два способа построить структуру

Чистый вариант «по типу вопроса» удобен для внутренней базы операторов, которые уже знают продукт. Для внешней базы, которую открывает клиент впервые, лучше работает гибрид: верхний уровень — по теме продукта (она же обычно совпадает с этапом использования), а форма статей внутри раздела — по типу вопроса.

Пример структуры для типичной службы поддержки

Раздел «Частые вопросы» держат отдельно от остальных не потому, что вопросы в нём особенные, а потому что читатель заходит туда, когда не понял, к какому разделу отнести свой случай — это предохранитель от потерянных статей, а не полноценный раздел с собственной темой. Как оформить сам этот раздел — отдельная статья, см. Вопросы и ответы для техподдержки: как составить FAQ.

Сколько уровней вложенности держать

Правило простое: не больше двух уровней — раздел и статья внутри него. Третий уровень (раздел → подраздел → статья) технически возможен почти в любой системе, но на практике до него доходят единицы: человек либо находит статью через поиск, либо теряется на втором клике и уходит писать в поддержку. Если внутри раздела набирается больше 15–20 статей, разумнее не добавлять подраздел, а разбить сам верхний раздел на два новых, а не углублять дерево.

Как называть разделы

Раздела «Прочее» или «Разное» в структуре быть не должно вовсе: как только он появляется, туда начинают складывать статьи, которым просто не придумали место, и раздел быстро становится крупнее любого тематического.

Как проверить структуру базы знаний

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

Частые ошибки

Структуру строят по организационной схеме компании, а не по вопросам клиента: отдел продаж, отдел техподдержки, бухгалтерия — вместо понятных клиенту тем. Клиент не знает, в каком отделе работает человек, который решит его вопрос.

Разделы дублируют друг друга по смыслу — например, «Настройка» и «Конфигурация» существуют параллельно, и новые статьи попадают то в один, то в другой без системы.

Оглавление показывает только названия разделов, без количества статей и без примера частого вопроса внутри — человеку приходится открывать каждый раздел по очереди, чтобы понять, туда ли он попал.

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

Частые вопросы

В каком формате лучше оформить базу знаний — списком или деревом разделов?

Для внешней базы, которую открывает клиент, работает плоский список из 5–8 разделов первого уровня без глубокой вложенности — так проще ориентироваться с первого взгляда. Дерево с несколькими уровнями оправдано только во внутренней базе для операторов, где ищут через поиск, а не листают оглавление.

Сколько разделов должно быть в базе знаний?

Ориентир — от пяти до десяти разделов первого уровня. Меньше пяти — разделы становятся слишком широкими и превращаются в свалку разных тем; больше пятнадцати — человек не может охватить список взглядом и теряется, какой раздел выбрать.

Нужна ли таблица в описании раздела базы знаний?

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

Что должно быть в содержании базы знаний на главной странице?

Список разделов с коротким описанием того, какие вопросы туда попадают, и поиск по всей базе — а не полный список всех статей сразу: длинный плоский список статей работает хуже, чем два уровня «раздел → статья».

Связанные статьи

• Что такое база знаний службы поддержки и как её собрать
• Как сделать базу знаний, чтобы обращений стало меньше
• Как оформить раздел частых вопросов службы поддержки
• Внутренняя база знаний для сотрудников: как устроить
• Готовые системы базы знаний или собственная страница: что выбрать