Регламент ведения базы знаний: образец

Кратко

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

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

Готовый образец

РЕГЛАМЕНТ ВЕДЕНИЯ БАЗЫ ЗНАНИЙ

Утверждён: <должность, ФИО>

Дата введения: <ДД.ММ.ГГГГ>

Пересмотр самого регламента: не реже раза в <12> месяцев

1. Назначение

1.1. Регламент определяет порядок создания, проверки, публикации и вывода из обращения статей базы знаний <название организации>.

1.2. База знаний делится на два контура: внешний (виден клиентам и пользователям) и внутренний (виден только сотрудникам поддержки). Правила ниже действуют для обоих, если не указано иное.

2. Роли

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

3. Когда заводится статья

3.1. При третьем однотипном обращении за <30> дней — обязательно.

3.2. По итогам разбора инцидента, если он потребовал более одного объяснения клиентам.

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

3.4. Статья, заведённая не по правилам 3.1–3.3 (например, «на будущее»), допустима, но не считается обязательной нормой выработки.

4. Порядок публикации

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

4.2. Проверяющий рассматривает черновик в течение <3> рабочих дней с даты создания.

4.3. При замечаниях статья возвращается автору с конкретным указанием, что поправить — не общей пометкой «доработать».

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

5. Пересмотр и устаревание

5.1. Ответственность за пересмотр несёт владелец темы, а не автор: автор может уже не работать в компании к моменту планового пересмотра.

6. Контроль

6.1. <Руководитель службы> раз в месяц смотрит: число статей без пересмотра дольше срока из п.5, число статей с низкой долей «помогло» в оценке читателями, список запросов без результата поиска.

6.2. Отчёт по этим трём пунктам — основа плана статей на следующий месяц.

Как заполнять

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

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

Срок устаревания без обращений (180 дней в таблице п.5) — берите из своей статистики. Для быстро меняющегося продукта интервал короче, для стабильного — можно длиннее; фиксированное число из чужого регламента не отражает скорость изменений именно у вас.

Пункт 3.4 нужен явно. Без него формальное правило «статья только при третьем обращении» останавливает инициативу тех, кто хочет описать что-то заранее, до того как накопится статистика обращений.

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

Как проверить, что регламент выполняется

1. Возьмите пять последних опубликованных статей — у каждой должна быть зафиксирована дата утверждения и имя проверяющего, отличное от автора.
2. Посчитайте долю опубликованных статей, у которых плановый пересмотр (п.5) просрочен. Растущая доля — верный признак, что обязанность 5.1 существует на бумаге, а не в работе.
3. Проверьте три статьи, заведённые по правилу 3.1: действительно ли по теме было три обращения до публикации, а не мнение автора, что тема важная.

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

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

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

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

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

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

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

Чем регламент ведения базы знаний отличается от шаблона статьи базы знаний?

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

Кто должен утверждать положение о базе знаний в компании?

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

Как часто пересматривать регламент ведения базы знаний?

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

Как это устроено в TehProf.kz Support

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

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

• Шаблон статьи базы знаний поддержки: образец структуры
• Как сделать базу знаний, чтобы обращений стало меньше
• Регламент технической поддержки: готовый образец
• Что такое база знаний службы поддержки и как её собрать
• Клиентский портал (обзор)