Шаблоны базы знаний, которые можно скопировать сегодня

Какой шаблон базы знаний выбрать

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

Шаблон справочной статьи: инструкция

Используйте для любой отдельной задачи, которую клиент выполняет в продукте: создать, настроить, подключить или экспортировать что-либо. Если в заголовке нужен союз «и», разделите статью на две.

• Начинайте заголовок с «Как» и глагола, используя слова, которые клиенты вводят в поиск.
• Ставьте ответ в одно предложение перед шагами, чтобы читатель и ИИ-ответы получили его сразу.
• Одно действие на шаг; выделяйте точные названия элементов интерфейса жирным.
• Заканчивайте ожидаемым результатом, чтобы читатель понял, что всё получилось.

# Как [выполнить задачу] в [Продукт]

[Ответ в одно предложение: чего достигнет читатель и самый короткий путь к этому.]

**Для кого:** [тариф / роль / платформа]
**Время:** [около 5 минут]

## Перед началом
- [Необходимые права или роль]
- [Что нужно настроить заранее]

## Шаги
1. Откройте **[Меню] > [Страница]**.
2. Нажмите **[Кнопка]**.
3. Введите [значение] в поле **[Поле]** и нажмите **Сохранить**.

## Результат
[Что видит читатель, если всё получилось.]

## Что дальше
- [Ссылка на связанную задачу]
- [Ссылка на статью по решению проблем]

Шаблон статьи по решению проблем

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

• Делайте заголовком точный текст ошибки: именно его вставляют в поиск.
• Объясните причину простыми словами до решения.
• Добавьте шаг проверки, чтобы читатель убедился, что проблема решена.
• Перечислите, что нужно поддержке (ID аккаунта, скриншот, время), чтобы сократить обращение.

# [Точный текст ошибки или симптом]

[Краткое описание самой частой причины и решения в одном предложении.]

## Симптомы
- [Что видит читатель, включая точный текст ошибки]

## Причина
[Почему это происходит, в одном-двух предложениях.]

## Решение
1. [Сначала самое вероятное решение]
2. [Как убедиться, что проблема решена]

## Если не помогло
- [Вторая причина]: [решение]
- [Третья причина]: [решение]

## Всё ещё не работает?
Напишите в поддержку и укажите: [ID аккаунта, скриншот, время ошибки].

Шаблон FAQ

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

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

# [Тема]: частые вопросы

## [Вопрос в формулировке клиента]?
[Прямой ответ в первом предложении.] [Одно-два предложения контекста.]
[Ссылка на полную статью]

## [Вопрос]?
[Ответ.]

## [Вопрос]?
[Ответ.]

Шаблон примечаний к релизу и changelog

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

• Формулируйте заголовок как результат («Экспорт отчётов в CSV»), а не как название внутренней задачи.
• Связывайте каждую новую функцию с её инструкцией.
• Оставляйте блок «Что нужно сделать», даже если ответ «Ничего»: читатели его ищут.

# [Версия или дата]: [Главная польза]

**Дата выпуска:** [ГГГГ-ММ-ДД]
**Доступно в:** [тарифы / платформы]

## Новое
- **[Название функции]**: [что теперь могут пользователи, одним предложением]. [Ссылка на инструкцию]

## Улучшено
- [Изменение и почему это важно]

## Исправлено
- [Ошибка, описанная через симптом, который видели пользователи]

## Что нужно сделать
[Что пользователям нужно изменить, или «Ничего».]

Шаблон статьи «Первые шаги»

Используйте один раз на продукт — как первую статью для новых клиентов. Это карта первой сессии, которая ведёт на подробные инструкции, а не повторяет их.

• Обещайте конкретный результат и реалистичное время в первом предложении.
• Ограничьтесь тремя-пятью пронумерованными этапами.
• Связывайте каждый этап с подробной инструкцией.
• Закрепите статью на главной странице справочного центра.

# Начало работы с [Продукт]

[Обещание в одном предложении: что у читателя заработает и сколько это займёт.]

## 1. [Создайте аккаунт или рабочее пространство]
[Два-три предложения.] [Ссылка на подробную инструкцию]

## 2. [Подключите или импортируйте первое]
[Два-три предложения.] [Ссылка]

## 3. [Пригласите команду]
[Два-три предложения.] [Ссылка]

## 4. [Получите первый результат]
[Как выглядит успех.]

## Что почитать дальше
- [Статья об основных понятиях]
- [Самая частая следующая задача]
- [Где получить помощь]

Структура разделов справочного центра для SaaS

Используйте как каркас нового справочного центра или при реорганизации разросшегося. Шести разделов верхнего уровня достаточно для большинства SaaS-продуктов; глубокая вложенность прячет статьи, а не упорядочивает их.

• Называйте разделы по тому, что делают клиенты, а не по названиям ваших внутренних команд.
• Используйте заголовки статей, ориентированные на задачу и начинающиеся с глагола.
• Выносите решение проблем в отдельный раздел, чтобы поиск по ошибкам вёл в одно место.
• Ставьте примечания к релизу последними: их часто читают, но редко просматривают.

Справочный центр
├── Первые шаги
│   ├── Начало работы с [Продукт]
│   └── Настройте аккаунт
├── Работа с [основная функция]
│   ├── Создайте [объект]
│   └── Измените или удалите [объект]
├── Интеграции
│   └── Подключите [Продукт] к [сервис]
├── Аккаунт и оплата
│   ├── Смените тариф
│   └── Скачайте счета
├── Решение проблем
│   └── [Точный текст ошибки]
└── Примечания к релизу
    └── [Версия]: [Главная польза]

Как писать для ИИ-ответов и RAG

ИИ-ассистенты и чат-боты справочных центров извлекают фрагменты, а не целые страницы. Retrieval-augmented generation (RAG) разбивает статьи на фрагменты по заголовкам, поэтому каждый фрагмент должен быть понятен сам по себе. Шаблоны выше построены именно так.

• Одна задача на статью: смешанные статьи дают фрагменты, которые отвечают на полвопроса.
• Описательные заголовки («Смена email для счетов», а не «Обзор») подсказывают поиску, что внутри фрагмента.
• Отвечайте в первом абзаце, чтобы цитируемый фрагмент уже содержал ответ.
• Называйте продукт и функцию явно вместо «он» или «эта страница».
• Пишите точные названия элементов интерфейса, тексты ошибок и лимиты: модели цитируют их дословно.

Как использовать эти шаблоны в Multibase

Multibase — white-label база знаний, где один аккаунт управляет многими брендированными порталами. Шаблоны работают в любом инструменте, но несколько функций Multibase помогают поддерживать их единообразие во всех порталах и языках.

• История версий: недавние версии каждой статьи сохраняются, их можно сравнить и восстановить прежнюю, если изменение шаблона пошло не так.
• Процесс ревью: назначайте ревьюеров, которые проверяют новые статьи на соответствие шаблону и оставляют комментарии до публикации.
• ИИ-генерация статей: опишите задачу в промпте, затем приведите черновик к структуре шаблона.
• ИИ-перевод: единая структура переводится чисто; Multibase создаёт черновик для каждого языка, а вы публикуете каждый язык независимо — всего 9 языков контента.
• Changelog и отложенная публикация: используйте шаблон примечаний к релизу в changelog и запланируйте публикацию на день запуска.
• Gap Finder (платные тарифы): запросы без результатов или со слабыми результатами, упорядоченные по частоте, показывают, какую инструкцию или статью по решению проблем написать следующей, — с черновиком в один клик.