База знаний компании: как сделать так, чтобы ей пользовались

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

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

Зачем нужна база знаний компании

Аргумент «знания надо сохранять» ничего не решает, потому что не называет цену. Цену видно в трёх сценариях.

Один и тот же вопрос по кругу

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

Онбординг, скорость которого зависит от чужой занятости

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

Автобусный фактор

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

Чем база знаний не является

Половина неудачных запусков — это попытка заставить один инструмент делать работу другого. У каждого канала есть свой вопрос, на который он отвечает хорошо, и граница, за которой он перестаёт работать.

Отдельно про «вики ради вики». Инструмент, купленный до того, как выяснили, на какие вопросы отвечать, превращается в свалку страниц с названиями вроде «Регламент №4 (актуальный) финал2». Выбор платформы — не первое решение и даже не третье. Первое — список из пяти вопросов.

Что класть внутрь, а что нет

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

Что стоит хранить

• Процедуры — как оформить, согласовать, запросить, закрыть. Всё, что делается редко и потому каждый раз заново выясняется.
• Решения с причинами — что выбрали, какие были альтернативы, почему отказались. Именно эта часть исчезает первой и стоит дороже всего.
• Устройство систем и договорённостей — что с чем связано, какие обязательства перед подрядчиком, где границы ответственности.
• Карта владения — кто за что отвечает по имени, а не по отделу. Самая посещаемая страница почти в любой компании.
• Маршрут новичка — что прочитать и в каком порядке в первую неделю.
• Ответы на повторяющиеся вопросы клиентов — заодно перестают расходиться формулировки у разных менеджеров.

Что хранить не нужно

• То, что меняется еженедельно — статусы, расписания, текущие приоритеты. Их место в трекере и календаре; в базе они гарантированно протухнут.
• Копии внешних источников — вместо пересказа чужой документации ссылка и одна строка «зачем нам это».
• Секреты и персональные данные — пароли, ключи, документы сотрудников. Для них есть менеджер секретов и кадровая система.
• Стенограммы целиком. Дословная запись встречи — исходник, а не знание. В базу переезжает вывод, а не три страницы, где к нему шли.
• Черновики и «пока пусть полежит» — они снижают доверие ко всей базе сильнее, чем помогают.

Структура: как организовать, чтобы находилось

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

Поиск важнее дерева

Люди не ходят по каталогу — они ищут словами, которыми думают. Из этого следуют три практических правила, и они важнее любой иерархии.

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

Первый абзац — это ответ. Человек должен получить нужное, не читая страницу до конца. Обоснования, исключения и предыстория — ниже. Страница, которая подводит к ответу тремя абзацами введения, читается один раз.

Синонимы пишутся прямо в тексте. Если одну вещь в компании называют тремя словами, все три должны встретиться на странице — иначе поиск найдёт её только тем, кто уже знает правильное слово.

Почему структура по отделам разваливается

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

Что работает вместо: плоская структура по процессам и вопросам, максимум два уровня вложенности, теги вместо папок и одна страница-указатель, с которой видно всё. Раздел заводится, когда в нём набралось не меньше пяти страниц — до этого момента он создаёт видимость порядка, а не порядок.

# [Вопрос ровно так, как его задают вслух]

Коротко: [2–3 предложения. По ним можно действовать, не читая дальше]

## Как сделать
1. [Шаг с конкретным местом: кнопка, форма, имя человека]
2. ...

## Почему так
[Причина решения и от чего отказались. Этот раздел и есть главная ценность]

## Если не сработало
[Два-три самых частых затыка и что с ними делать]

---
Владелец: [имя]  ·  Проверено: [дата]  ·  Пересмотреть: [дата + 6 месяцев]

Процесс: кто пишет и кто обновляет

База знаний умирает не от нехватки статей, а от недоверия к их актуальности. Механика простая: человек один раз натыкается на прошлогодний прайс — и дальше проверяет в чате всё, что найдёт. С этого момента база формально существует, но работу больше не делает.

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

У каждой страницы есть владелец с именем. Не отдел и не «команда»: у страницы, принадлежащей всем, не обновляет никто.

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

Устаревшее помечается, а не удаляется молча. Строка «устарело с марта, актуальное — здесь» полезнее пустоты: она отвечает тому, кто пришёл по старой ссылке. Молча удалять стоит только дубли.

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

С чего начать за неделю

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

Чего не делать в первую неделю: выбирать платформу три недели, переносить старый общий диск целиком (перенесётся мусор, и в нём утонут пять полезных страниц) и назначать ответственного за базу знаний, у которого нет времени отвечать на вопросы.

Встречи как источник знания

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

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

Второе следствие касается AI-инструментов, которыми компания уже пользуется. Модель без вашего контекста отвечает общими словами и не помнит предыдущий разговор. Наполненная база знаний и есть тот контекст, который превращает универсального ассистента в знающего вашу компанию: работа по наполнению окупается дважды — для людей и для моделей.

Где здесь Whisperer

Whisperer — AI-рабочее пространство, где встречи, знания, документы, задачи, календарь и AI-модели живут в одной системе: клиенты macOS и Windows плюс веб-кабинет. К описанной задаче он относится там, где знание рождается на созвоне и должно куда-то попасть.

Живой созвон. Стенограмма ведётся в реальном времени, во время разговора. Берутся два независимых потока — микрофон и системный звук, — поэтому реплики размечены по спикерам, а собеседнику не нужно никого пускать в комнату. Есть перевод речи на лету и AI-подсказки по ходу разговора. Важное ограничение, о котором честнее сказать сразу: загрузки готовой записи в продукте нет — работает только живой созвон, mp3 из прошлой встречи обработать нечем.

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

База знаний. Заметки в Markdown с тегами, wiki-ссылками вида [[название заметки]] и графом связей — по нему видно, какие заметки центральные. Поиск не только текстовый, но и смысловой, а найденные фрагменты Whisperer сам подмешивает в контекст, когда вы о чём-то спрашиваете на встрече. Здесь тоже нужна честная оговорка: это личное хранилище знаний участника, а не корпоративная вики с правами доступа и согласованиями. Общую базу знаний компании оно не заменяет — оно закрывает соседнюю задачу: чтобы AI отвечал вам с учётом ваших продуктов, клиентов и терминологии.

Внешние клиенты. Через MCP-сервер Claude Desktop и Cursor читают отмеченные вами встречи и ищут по стенограммам — без ручного копирования. По умолчанию не открыта ни одна встреча: доступ выдаётся точечно и вами. Агент Leo работает с задачами и накопленным контекстом внутри самого Whisperer.

Старт бесплатный — 60 минут, которых хватит, чтобы проверить сценарий на одной реальной встрече: провести созвон, посмотреть, что осталось в карте встречи, и решить, что из этого достойно отдельной страницы.

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