Антон Дегтярёвбаза знаний в битрикс24: как правильно её собрать
На аудите почти в каждой компании база знаний уже есть — но живёт в трёх местах сразу: часть в закреплённых сообщениях чата, часть в личных заметках менеджеров, часть в файле, который последний раз обновляли полтора года назад. Новый сотрудник в такой ситуации учится не по документам, а по вопросам коллегам. Собрать нормальную базу знаний в Битрикс24 — не про технологию, а про то, кто и когда её будет обновлять.
зачем база знаний, если есть чаты и созвоны
Устный ответ в чате решает вопрос одного человека один раз. Через месяц тот же вопрос задаст другой сотрудник, и кто-то снова потратит 10 минут на объяснение. На аудите я считал: в отделе из 8 человек одни и те же типовые вопросы — как оформить возврат, куда класть документы по новому клиенту, кому эскалировать спорную сделку — задаются в среднем 3-4 раза в месяц каждый.
База знаний решает это не потому что она «современный инструмент», а потому что переносит ответ из разовой переписки в место, где его найдёт любой следующий человек с тем же вопросом. Встроенный модуль в Битрикс24 удобен именно тем, что живёт там же, где сотрудники и так работают — не нужно открывать отдельный сервис и заводить туда учётные записи заново.
Отдельный эффект, который недооценивают: база знаний экономит время не только новичков, но и опытных сотрудников. Даже РОП с трёхлетним стажем не помнит наизусть все нюансы редких процессов — возврат по спецзаказу, работа с проблемным поставщиком — и быстрее найти статью, чем вспоминать или спрашивать.
с чего начать — не с технологии, а со списка вопросов
Частая ошибка — начинать с создания разделов в системе, а не со сбора реальных вопросов. На моих внедрениях первый шаг всегда один: две недели собираем в чате все вопросы, которые задают сотрудники, и структурируем их уже потом, глядя на реальный список, а не на воображаемую структуру.
Практический способ собрать список — попросить каждого руководителя отдела вспомнить пять вопросов, которые ему задавали новички за последний месяц. За 20-30 минут такого разговора обычно набирается ядро будущей базы знаний — 15-20 тем, которые реально нужны, а не абстрактный список «на всякий случай».
Отдельно смотрю на регламенты, которые уже существуют где-то в текстовом виде — договоры, чек-листы, старые презентации для новичков. Их не нужно переписывать с нуля, часто достаточно адаптировать под формат статьи и актуализировать цифры.
структура разделов — три уровня, не больше
Глубокая вложенность разделов — частая причина, почему базой перестают пользоваться. Если статью нужно искать через четыре клика по подразделам, проще написать вопрос в чат — что сотрудники и делают, а база остаётся нетронутой.
Рабочая схема, которую использую по умолчанию: раздел по отделу или функции (продажи, поддержка, бухгалтерия), внутри — по типу вопроса (регламенты, инструкции по CRM, шаблоны документов), и дальше сразу статья. Три уровня максимум, дальше — плоский список статей внутри раздела с понятными названиями.
Название статьи должно звучать как вопрос сотрудника, а не как канцелярский заголовок. Не «Регламент обработки возвратов», а «Как оформить возврат от клиента — пошагово». Второй вариант находят через поиск за секунды, первый — только если знать точное название заранее.
кто пишет статьи и почему это не должен быть один человек
Частая модель, которая не работает: одному сотруднику — обычно HR или ассистенту — поручают «собрать базу знаний» целиком. Человек не владеет спецификой продаж или бухгалтерии на достаточном уровне, статьи получаются общими, а эксперты отдела их не проверяют, потому что не считают своей задачей.
Рабочая модель — каждый раздел пишет и поддерживает тот, кто в нём разбирается: РОП отвечает за раздел продаж, бухгалтер — за свой, руководитель поддержки — за свой. Один человек координирует общий формат и структуру, но не пишет контент за экспертов.
На моих проектах это снимает ещё одну проблему — актуальность. Если статью написал внешний человек по рассказам эксперта, при изменении процесса никто не вспоминает её обновить. Если статью ведёт сам эксперт как часть своей работы, обновление происходит естественно, вместе с изменением процесса.
Если параллельно выстраиваете системное обучение новых сотрудников, а не только базу знаний как справочник — у меня есть отдельная статья про обучение сотрудников работе в Битрикс24, эти два процесса хорошо дополняют друг друга.
как не превратить базу в свалку из двухсот статей
Через год активного использования типичная база знаний разрастается до сотни и больше статей, часть из которых устарела, а часть дублирует друг друга. Без регулярной ревизии база теряет доверие — сотрудник один раз находит устаревшую инструкцию, действует по ней неправильно, и после этого предпочитает спрашивать в чате, а не искать в базе.
Практика, которая работает на моих внедрениях: раз в квартал ответственный за раздел проходит по своим статьям и помечает устаревшие — либо обновляет, либо архивирует. Это 30-40 минут на раздел, но именно эта регулярность отличает живую базу знаний от той, что заброшена через полгода после запуска.
Второй инструмент — счётчик просмотров и обратная связь под статьёй, даже простая кнопка «помогло / не помогло». Статьи с нулевыми просмотрами за полгода — кандидаты на объединение с соседними или удаление, а не повод писать ещё.
Дублирующиеся статьи — отдельная проблема, которая возникает, когда несколько человек пишут независимо. Раз в квартал стоит проверять разделы на пересечения тем — если два человека написали инструкцию про один и тот же процесс с разницей в деталях, это путает больше, чем отсутствие статьи вообще.
как встроить базу знаний в реальную работу, а не держать отдельно
База знаний, которую нужно специально открывать и искать, используется значительно реже той, что подсказывает сама. На моих внедрениях статьи из базы стараюсь привязывать к конкретным точкам процесса — ссылка на инструкцию по возврату прямо в карточке сделки на нужной стадии, ссылка на регламент оформления документов в задаче нового клиента.
Второй способ встроить базу в работу — использовать её в адаптации новых сотрудников не как факультатив, а как обязательный этап: первая неделя новичка включает конкретный список статей для прочтения с коротким тестом на понимание, а не просто «почитай, если будет время».
Третий — упоминать базу знаний в ответе на вопрос в чате вместо полного устного объяснения: «смотри статью про возвраты, там же и пример» — это не отговорка, а способ приучить команду искать самостоятельно и заодно проверить, что статья реально отвечает на вопрос.
Отдельная тема, которую часто забывают включить в базу знаний, — сама CRM. На аудите вижу, что пользовательские поля в карточке сделки годами живут без пояснений, и новый сотрудник не понимает, зачем поле «источник 2» и чем оно отличается от обычного «источника». Короткая статья с расшифровкой каждого поля экономит РОПу кучу однотипных вопросов. Как вообще проектировать эти поля, чтобы их не пришлось потом объяснять — отдельно разбирал в статье про настройку полей CRM в Битрикс24.
типичные ошибки при запуске базы знаний
Первая — запуск сразу с большим объёмом контента. Компания заказывает написание 50 статей разом, сотрудники не успевают их прочитать до того, как часть информации устареет, а привычка искать в базе так и не формируется. Лучше 10-15 статей по реально частым вопросам и регулярное пополнение, чем массив «на всё» с первого дня.
Вторая — отсутствие ответственного за актуальность. База без владельца превращается в архив исторических документов уже через 3-4 месяца, даже если изначально была хорошо структурирована.
Третья — сложный формат статей. Длинные полотна текста без подзаголовков, скриншотов и пошаговых списков читаются хуже, чем короткая инструкция с картинками. Формат «пять шагов со скриншотами» на моих проектах читают в разы охотнее, чем текстовое описание процесса на две страницы.