Шаблони бази знань, які можна скопіювати сьогодні

Який шаблон бази знань обрати

Більшість контенту довідкового центру вкладається у п'ять типів статей. Обирайте шаблон за питанням, з яким приходить читач, а не за функцією, яку хочете описати. Єдина структура допомагає читачам швидко переглядати статті, рев'юерам — помічати прогалини, а пошуковикам і ШІ-асистентам — цитувати чіткі, передбачувані розділи.

Шаблон довідкової статті: інструкція

Використовуйте для будь-якого окремого завдання, яке клієнт виконує в продукті: створити, налаштувати, підключити або експортувати щось. Якщо в заголовку потрібен сполучник «і», розділіть статтю на дві.

• Починайте заголовок з «Як» і дієслова, використовуючи слова, які клієнти вводять у пошук.
• Ставте відповідь в одне речення перед кроками, щоб читач і ШІ-відповіді отримали її одразу.
• Одна дія на крок; виділяйте точні назви елементів інтерфейсу жирним.
• Завершуйте очікуваним результатом, щоб читач зрозумів, що все вдалося.

# Як [виконати завдання] в [Продукт]

[Відповідь в одне речення: чого досягне читач і найкоротший шлях до цього.]

**Для кого:** [тариф / роль / платформа]
**Час:** [близько 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 (платні тарифи): запити без результатів або зі слабкими результатами, впорядковані за частотою, показують, яку інструкцію чи статтю з вирішення проблем написати наступною, — із чернеткою в один клік.