Шаблон инструкции базы знаний: структура и пример

Что включить в статью

В KCS описание проблемы, окружения и решения помогает находить и применять знания в подходящем контексте. Необязательно превращать это в длинную анкету. Назовите проблему словами пользователя и укажите условия, при которых инструкция проверена.

Название: действие или симптом словами пользователя
Для кого и для какой системы:
Когда применять / когда не применять:
Что потребуется перед началом:
Шаги с ожидаемым результатом:
Как проверить успех:
Что делать, если не получилось:
Владелец, дата проверки, версия окружения:

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

Пример: собрать сведения об ошибке входа

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

1. Запишите название системы и адрес страницы без секретных параметров ссылки.
2. Скопируйте текст ошибки. Если его нет, опишите, на каком шаге останавливается вход.
3. Укажите время последней попытки и часовой пояс.
4. Отметьте, откуда подключаетесь: офис или согласованный удалённый канал.
5. Приложите снимок ошибки, скрыв посторонние данные.
6. Отправьте сведения через установленный канал поддержки.

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

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

Как писать шаги без двусмысленности

В одном шаге оставляйте одно понятное действие. Называйте элементы так, как они подписаны в интерфейсе. После действия, которое может дать разные результаты, добавляйте ожидаемый признак успеха и ветку на случай ошибки.

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

Скриншот помогает найти кнопку, но не должен быть единственным носителем инструкции. Текст доступнее для поиска, копирования и программ чтения экрана. У изображения должен быть осмысленный альтернативный текст; изменения интерфейса нужно учитывать при проверке актуальности.

Как проверить инструкцию до публикации

1. Попросите коллегу, не участвовавшего в написании, выполнить безопасный сценарий в тестовой среде.
2. Отмечайте вопросы, пропущенные условия и отличия названий элементов.
3. Проверьте все ссылки и доступность статьи для её аудитории.
4. Убедитесь, что пользователь распознает как успех, так и неуспех.
5. Запишите дату, окружение и ответственного за следующий пересмотр.

Если коллега справился только после устных подсказок автора, внесите эти подсказки в текст. Для разных версий системы лучше явно обозначить различия, чем оставлять читателю угадывать, какой экран правильный.

Как поддерживать материал в рабочем состоянии

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

Не оценивайте базу знаний только количеством статей. Смотрите, помогает ли материал решить конкретную задачу и уменьшает ли необходимость уточнений. Обратную связь об ошибке в инструкции сделайте простой.

В TIQQET предусмотрена база знаний; этот шаблон описывает редакционный процесс и не предполагает автоматического контроля всех перечисленных полей. Для более широкой методики см. материал о KCS.

Источники и границы рекомендаций

Материал подготовлен 23 сентября 2026 года. Приведённые шаблоны и примеры предлагаются для адаптации под вашу службу поддержки; это не обязательные требования стандарта.

• Consortium for Service Innovation: структура статьи KCS