Дизайн базы знаний: как создать структуру, с которой не воюют ни поддержка, ни клиенты

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

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

В этой статье разберём, как спроектировать базу знаний, которая реально работает: для поддержки, для клиентов и для самого бизнеса. Попробуем принцип «ядро + гибкие блоки», покажем пример c условной компанией и посмотрим, как TEAMLY AI вписывается в дизайн и развитие такой системы.

Зачем вообще заморачиваться со структурой

Можно сколько угодно полировать статьи, но если структура кривая, пользователи до них просто не доберутся. Даже самые опытные операторы в такой базе знаний  (БЗ) живут с вечным чувством «я где‑то это уже видел, но не помню где».

Хорошо спроектированная база знаний:

• снижает входящую нагрузку на поддержку (часть вопросов уходит в самообслуживание);

• ускоряет ответы операторов и уменьшает количество ошибок;

• облегчает онбординг новых сотрудников;

• делает сервис прозрачным: клиент понимает, как всё устроено, и меньше нервничает.

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

Базовые принципы: не начинать с оргструктуры

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

Принципы, от которых лучше не отходить

• Логика от общего к частному. Сначала крупные разделы, затем сценарии и уже внутри — конкретные инструкции. Не надо закапываться в 7‑уровневую вложенность: 3–4 уровня — комфортный максимум.

• Ориентация на пользователя. Структура строится от задач: «как начать работать», «как оплатить», «как вернуть», а не от внутренних отделов. В одном и том же процессе может быть задействовано несколько департаментов, и это никак не должно отражаться на структуре для пользователя — ему это всё равно.

• Простота и ясность. Названия разделов должны быть интуитивными, без внутреннего жаргона. Если заголовок нужно «объяснять новичку» — это плохой заголовок.

• Масштабируемость. Структура должна выдерживать рост: новые продукты, новые регионы, дополнительные роли. Если при запуске нового направления приходится перекраивать половину дерева — что‑то пошло не так.

• Консистентность. Единые принципы именования, общий шаблон статьи, одинаковая логика заголовков и подзаголовков. Это критично и для людей, и для поиска внутри БЗ.

Внутренняя база знаний: сердце поддержки

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

Задачи внутренней базы знаний

• оперативная помощь оператору «в момент звонка/чата»

• стандартизация решений (одинаковые кейсы — одинаковые действия)

• обучение новых сотрудников и поддержка старых при изменениях

Универсальное ядро: что должно быть у всех

В любой адекватной внутренней БЗ почти всегда есть набор «обязательных» разделов, общих для всех:

• Продукты и услуги. Что именно продаётся или предоставляется: тарифы, лимиты, исключения, ограничения. Это фундамент контекста.

• Процедуры и стандарты (SOP). Пошаговые инструкции: «Как оформить возврат», «Порядок эскалации тикетов», «Что делать при споре по оплате». Формат: коротко, по шагам, без философии. Кстати, у Teamly есть не просто статьи, а пошаговые сценарии с возможностью возврата к предыдущим шагам.

• Политики компании. Тон общения, правила в спорных ситуациях, политика возвратов, конфиденциальность, юридические рамки.

• Инструменты и софт. CRM, тикет‑система, чат‑боты, админка. Как зайти, что можно и нельзя делать, типичные ошибки.

• FAQ и сложные кейсы. Свалка всего «странного», что регулярно всплывает: баги, пограничные сценарии, редкие ошибки.

Гибкие блоки: под конкретный бизнес

То, что уже зависит от бизнес‑модели:

• по типам клиентов: B2B vs B2C;

• по каналам поддержки: чат, звонки, соцсети;

• по регионам: свои правила для разных регионов/стран;

• по продуктовым линейкам: разные ветки под SaaS, хостинг, домены, дополнительные сервисы.

Смысл: ядро едино для всех, а гибкие блоки отражают реальность именно вашего бизнеса и ролей.

Публичная база знаний: самообслуживание без боли

Публичная база знаний — витрина для клиента. Она должна отвечать на вопрос: «Как мне решить свою задачу самому, быстро и без звонка в поддержку?»

Что выносить наружу

Основной критерий простой: всё, что помогает человеку спокойно и безопасно справиться самому, без ущерба для бизнеса и безопасности:

• частые и простые вопросы (пароль, оплата, где посмотреть статус);

• инструкции по старту работы: подключение, первые шаги, базовая настройка;

• обучающие материалы и гайды: как подключить интеграцию, как не допустить типичных ошибок;

• публичные политики: оферта, условия использования, гарантии;

• анонсы обновлений, changelog, новости.

Что оставлять внутри

Некоторые вещи не должны покидать внутренний контур:

• внутренние SOP и шаблоны переписки;

• мотивация и KPI сотрудников;

• подробности внутренних сбоев, особенно до их полного решения;

• коммерческие детали, партнёрские условия, спеццены.

Как строить структуру для клиента

Для клиента дерево должно быть ещё проще, чем для оператора. Хорошая стартовая рамка:

• Начало работы.

• Оплата и счета.

• Решение проблем.

• Руководства и гайды.

Плюс два обязательных компонента:

• нормальный поиск (с подсказками и синонимами);

• перекрёстные ссылки между статьями — из серии «вам также может быть полезно».

Киллер-фича — дать возможность поиска с помощью AI. Например, с помощью виджета.

Пример: как живёт база знаний QuickBuy

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

Задача: сделать единую внутреннюю БЗ для операторов и отдельные внешние порталы для покупателей, продавцов и курьеров.

TEAMLY AI как рабочий инструмент дизайна базы знаний

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

TEAMLY AI, в принципе, может:

• собрать начальное дерево разделов;

• найти дубли и криво названные ветки;

• проверить консистентность статей и тональности.

Промпт для TEAMLY AI: проектирование структуры

Основная ошибка начинающих пользователей ИИ-сервисов — «умолчания». Многое в окружающем мире мы воспринимаем как само собой разумеющееся, но «железному болвану» о некоторых особенностях надо рассказать. Какая-то база, сформированная обучением нейросети, есть у любой LLM, но конкретные нюансы нужно либо уточнить, либо дать команду на анализ.

Вот промпты, которые подойдут для любой нейросети — лишь бы она могла получить доступ до вашей базы знаний и других ресурсов, которые ей стоило бы учесть в работе. Если модель поддерживает «пространства» или «беседы», промпты можно выполнять последовательно, уточняя и дорабатывая промежуточные результаты на каждом этапе. Обычно модель позволяет загружать документы и умеет читать их, но объём может быть ограничен — либо текстовым окном самой LLM, либо тарифом.

Вот промпты:

Изучи сайт компании quickbuy.sale. Изучи имеющуюся базу знаний. Прочти методические материалы из прикрепления.

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

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

Добавь обозначения [SOP] для стандартных операционных процессов.

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

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

Внутренняя структура QuickBuy

Логика: верхний уровень — по аудиториям, плюс общее ядро. Внутри каждой аудитории — путь пользователя: от старта до проблем.

БАЗА ЗНАНИЙ QUICKBUY (Внутренняя)

│

├── 1. ОБЩЕЕ ЯДРО КОМПАНИИ

│   ├── 1.1. Наши продукты и политики

│   │   ├── Описание тарифов (для продавцов)

│   │   ├── Публичная оферта

│   │   └── Политика возвратов и гарантий

│   ├── 1.2. Процедуры поддержки (SOP)

│   │   ├── Алгоритм эскалации инцидентов

│   │   ├── Стандарты общения (тон, шаблоны)

│   │   └── Работа с возражениями и конфликтами

│   └── 1.3. Инструменты и софт

│       ├── Инструкция по CRM (Service Desk)

│       ├── Работа с чат-ботами

│       └── Админка платформы: основные настройки

│

├── 2. НАПРАВЛЕНИЕ: ПОКУПАТЕЛИ

│   ├── 2.1. Поиск и выбор товара

│   ├── 2.2. Оформление и оплата заказа

│   │   ├── [SOP] Отмена заказа покупателем

│   │   └── [SOP] Ошибка при оплате

│   ├── 2.3. Доставка и отслеживание

│   └── 2.4. Возвраты и претензии

│       └── [SOP] Стандартный процесс возврата денег

│

├── 3. НАПРАВЛЕНИЕ: ПРОДАВЦЫ

│   ├── 3.1. Кабинет продавца: настройка

│   ├── 3.2. Товары и склады

│   │   ├── Добавление и редактирование карточек

│   │   └── [SOP] Блокировка товара модератором

│   ├── 3.3. Заказы и финансы

│   │   ├── Обработка заказов

│   │   ├── Выплаты и отчеты

│   │   └── [SOP] Решение спора по заказу

│   └── 3.4. Продвижение и аналитика

│

└── 4. НАПРАВЛЕНИЕ: КУРЬЕРЫ

    ├── 4.1. Регистрация и подключение

    ├── 4.2. Приложение курь��ра: работа с заказами

    └── 4.3. Оплата и рейтинг

        └── [SOP] Что делать при проблеме с доставкой?

Пояснения к логике

• [SOP] помечают стандартные операционные процедуры — это скелет обучения и контроля качества.

• Раздел 1 (ядро) обязателен для всех операторов, независимо от специализации.

• Разделы 2–4 — вариативные; оператор может специализироваться на одной аудитории, но при этом иметь доступ ко всем разделам, чтобы разруливать кросс‑кейсы: спор между покупателем и продавцом, задержка доставки с участием курьера и продавца и т.д.

• Логика «от задачи»: внутри каждой аудитории путь строится по шагам — от «как начать» до «что делать, если всё пошло не по плану».

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

Аудит структуры:

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

Проверка консистентности статей:

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

TEAMLY AI удобно «встраивать» в регламенты: как только вы меняете структуру или массово обновляете статьи, прогоняете их через такие промпты и ловите проблемы до того, как ими начнут спотыкаться операторы.

Как из внутренней базы знаний рождаются внешние порталы

На базе этого дерева можно довольно прозрачно строить клиентские порталы.

Портал для покупателей. Берём раздел 2, язык очеловечиваем, убираем внутренние пометки и SOP. Добавляем интерактивные инструкции — визуальные гайды, шаги с картинками: как оформить заказ, как вернуть товар, как отследить доставку.

Портал для продавцов. Берём раздел 3. Технические инструкции (например, по API) переписываем в формат понятных гайдов. Добавляем тарифы и комиссии из 1.1, кейсы в стиле «Как увеличить продажи», «Лучшие практики продвижения».

Портал для курьеров. Берём раздел 4. Добавляем видеоинструкции по приложению курьера, расписание и правила выплат, условия бонусов, ответы на типовые вопросы типа «Что делать, если клиент сбрасывает звонок».

Что эта схема даёт бизнесу

• Структура повторяет бизнес‑модель — операторам не нужно перестраивать мышление.

• При запуске новых услуг (например, «QuickBuy Электронные книги») можно просто добавить подраздел к нужной ветке, не ломая всё дерево.

• Контент‑менеджеры правят критичные статьи (про оплату, возвраты) один раз в ядре и дальше синхронизируют с внешними порталами. Или просто выводят ту же статью на портал с помощью технологии самой платформы БЗ.

• Добавление нового региона — это расширение ядра (новые SOP по локальным законам), а не перестройка всей архитектуры.

Этапы внедрения базы знаний: от свалки документов к системе

Если сейчас у вас хаос в документах, нормальный путь выглядит так:

1. Аудит. Собираете всё: файлы, страницы, заметки, презентации, ответы из мессенджеров. Помечаете, что актуально, что устарело, что дублируется.

2. Карта мыслей (mind map). Переводите всё в визуальную карту: роли, продукты, процессы, политики. Смотрите, где провалы (например «У нас ничего нет про возвраты»), а где узлы перегружены.

3. Прототип структуры. Собираете дерево в  Teamly или аналогичной системе — ну или хотя бы в документе/таблице. Определяете ядро и вариативные блоки, прописываете уровни доступа.

4. Тестирование на фокус‑группе. Даете структуру живым операторам и лояльным клиентам (для внешней части). Важен не только фидбек, но и наблюдение: сколько кликов до ответа, где они теряются, успевают ли получить ответ и помощь в приемлемое время.

5. Наполнение и запуск. Переносите контент, переписываете «голую» техническую документацию в нормальный читаемый вид.

Метрики и итерации. Смотрите на количество входящих запросов, среднее время решения, CSAT или внутренний NPS по БЗ. Поисковые запросы в самой базе — отдельное золото для понимания, каких статей не хватает.

Чек‑лист дизайна базы знаний

Ниже — компактный чек‑лист, который можно использовать как контрольный, когда вы проектируете или реформируете базу знаний. Кстати, можно скормить этот документ AI и попросить проверить БЗ по нему.

1. Логика и структура

• Понимание целевых аудиторий: операторы, клиенты, партнёры.

• Чётко сформулированные цели БЗ: снижение тикетов, ускорение ответов, сокращение онбординга.

• Дерево от общего к частному, не более 3–4 уровней вложенности.

• Разделение на ядро (продукты, политики, SOP, инструменты) и гибкие блоки (аудитории, регионы, продукты).

2. Контент и оформление

• Во всех разделах информация сгруппирована по задачам пользователя, а не по отделам компании. 

• Для статей есть единый шаблон: контекст → шаги → нюансы → связанные материалы.

• Язык живой, без корпоративного канцелярита, короткие абзацы, списки вместо сплошного полотна.

• В статьях есть перекрёстные ссылки и блок «что почитать ещё».

3. Внутреннее vs публичное

• Внешняя БЗ содержит FAQ, онбординг для покупателей, продавцов и курьеров, гайды, публичные политики, обновления.

• Внутри остаются SOP, шаблоны переписки, внутренняя аналитика, мотивация, инциденты, чувствительные данные, онбординг для сотрудников.

• Для каждой статьи заранее определён уровень доступа и, при необходимости, её «публичный близнец».

4. Метрики и итерации

• Отслеживаются показатели: количество обращений, среднее время ответа, время до решения, CSAT.

• Анализируются поисковые запросы внутри БЗ — на их основе появляются новые статьи и правятся существующие.

• Раз в квартал структура пересматривается: упрощаются ветки, удаляются устаревшие разделы, консолидация дублей.

Есть у базы знаний начало, нет у базы знаний конца

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

Лучшее, что можно сделать:

• разделить БЗ на устойчивое ядро и гибкие блоки;

• привязать структуру к реальным задачам пользователей;

• связать внутреннюю и внешнюю базы в единую живую систему;

• добавить ИИ — например,  TEAMLY AI — как постоянного «редактора» структуры и контента.

Если хочется начать прямо сейчас — начните с самого приземлённого шага: проведите честный аудит того, что уже есть, и нарисуйте первую карту разделов. А потом можно накидывать теги, шаблоны, типографику, инфографику и все остальные приятные детали. И, главное, решать — кто всю эту красоту будет реализовывать.