База знаний есть, а сотрудники всё равно спрашивают? Проблема не в сотрудниках, а в инструкциях

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

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

Определите аудиторию: для кого вы пишете

Чаще всего можно выделить две основные группы:

1. Новички — сотрудники на онбординге, люди из других отделов, подрядчики.
2. Опытные пользователи/эксперты — те, кто делает одно и то же действие десятки раз в неделю и знает контекст.

Для новичков важно объяснить термины, дать больше скриншотов, включить блок «Зачем это вообще делается» и «Что должно получиться в итоге». Для экспертов важно убрать очевидное и оставить только отличия и тонкости: «Что поменялось после обновления», «Как действовать в нестандартной ситуации».

Пример формулировок для разных аудиторий:

1. Для новичка: «Эта инструкция поможет вам оформить первый договор с клиентом и проверить, что все поля заполнены правильно».
2. Для опытного: «Изменения в оформлении договора с 01.03: добавлены новые обязательные поля и проверки».

Если сомневаетесь, под кого писать, — делайте две версии: базовую (для новичков) и краткую «How‑to» (для тех, кто уже в теме). Это не роскошь, а нормальная практика редактора базы знаний.

Структурируйте материал: от цели к шагам

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

Рабочая структура статьи:

1. Цель. Формулировка, которая дает короткий ответ на вопрос: «Зачем это нужно?» и «В каких ситуациях это применяется?». «Инструкция для менеджера по продажам, чтобы оформить возврат платежа клиенту и не допустить блокировку операции».
2. Пререквизиты. Что должно быть готово до начала: доступы, документы, статусы. «Перед началом убедитесь, что: у вас есть доступ в раздел “Финансы”, клиент прошёл идентификацию, у вас есть номер операции».
3. Пошаговая последовательность. Нумерованный список действий, который даст читателю понимание, что делать шаг за шагом. «Шаг 1. Зайдите в Настройки. Шаг 2. Выберите пункт “Аккаунт”»
4. Итог. Что будет в конце: какой статус, какие документы, какие уведомления. «В результате клиент получает письмо с подтверждением возврата, а в системе появляется запись в разделе “Возвраты”».

Пишите просто и чётко: язык инструкций

Хороший редактор базы знаний пишет так, чтобы текст «озвучивался» без запинок. Основные правила просты, но требуют дисциплины:

• короткие предложения — максимум 8–10 слов;
• глаголы в повелительном наклонении: «Откройте», «Нажмите», «Выберите», «Введите»;
• минимум пассивного залога: «Система отправит письмо» вместо «Письмо будет отправлено системой».

Рассмотрим примеры.

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

Хорошо: «Нажмите на иконку профиля в правом верхнем углу. Выберите пункт “Настройки”».

Неудачно: «Необходимо как следует удостовериться в абсолютной корректности заполнения всех полей формы на предмет отсутствия ошибок».

Хорошо: «Проверьте, что заполнены все обязательные поля. Если поле подсвечено красным — исправьте ошибку».

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

Добавляйте наглядность там, где она действительно помогает

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

Чаще всего полезны:

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

Главное правило — наглядность должна помогать, а не отвлекать. Лучше один скриншот с выделенными областями и подписями, чем пять скринов подряд без пояснений. Для мобильных пользователей имеет смысл добавлять подпись «Скриншот с десктопной версии, на мобильной кнопка находится в нижнем меню».

Обеспечьте настоящую пошаговость

Плохой пример: «Откройте настройки и измените параметры».

Хороший:

1. Откройте меню «Настройки».
2. Перейдите во вкладку «Параметры».
3. В поле «Частота обновлений» выберите значение «Каждые 15 минут».
4. Нажмите «Сохранить».

Ветвления «Если… то…» стоит выделять либо отдельными подпунктами, либо простыми блок‑схемами:

• если клиент уже зарегистрирован, перейдите к шагу 5;
• если клиент новый, выполните шаги 2–4 и только потом переходите к шагу 5.

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

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

Добавьте предупреждения и лайфхаки

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

Форматы подачи:

1. Предупреждение — когда действие необратимо или может повлиять на клиентов и деньги. «Внимание: после удаления договора восстановить его будет нельзя. Сначала скачайте его в формате PDF в папку на компьютере или мобильном устройстве».
2. Совет — когда хочется поделиться удобным приёмом. «Чтобы не потерять изменения, используйте горячую клавишу Ctrl+S каждые 5–10 минут».

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

Разберите типичные ошибки в инструкциях

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

1. «Телепатия» — предположение, что читатель «и так знает»: «Как вы знаете, все обращения фиксируются в системе» — вместо «Все обращения фиксируются в системе X, даже если клиент пишет в чат или звонит по телефону».
2. Избыточность — длинные абзацы вместо действий: «Система предназначена для того, чтобы пользователям было удобно…» — это можно вынести в отдельный обзор, но не в рабочую инструкцию.
3. Нечёткие формулировки: «Нажмите соответствующую иконку справа». Либо «соответствующая иконка» сопровождается скриншотом, либо уточняем: «Нажмите на иконку шестерёнки в правом верхнем углу».
4. Отсутствие визуальных опор — когда текст описывает интерфейс, но нет ни одного скрина или схемы, а кнопки называются по‑разному (в системе — «Создать», в тексте — «Добавить»).
5. Игнорирование разных устройств — скриншоты только с десктопа, хотя половина сотрудников работает с телефона. В этом случае стоит хотя бы добавить сноску: «На мобильной версии пункт “Отчёты” находится в нижнем меню».

Хороший редактор базы знаний сознательно проверяет текст на эти ошибки и правит без жалости.

Проверьте и оптимизируйте: чек‑лист редактора

Перед тем как публиковать инструкцию, удобно пройтись по короткому чек‑листу:

1. Все ли шаги логичны и последовательны?
2. Можно ли выполнить процесс, следуя только тексту, без дополнительных вопросов?
3. Нет ли абзацев, которые можно сократить до одного действия?
4. Понятно ли, какой результат должен получиться в конце?

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

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