директор и машина · операционное управление · запись № 001 · 4 июня 2026 · Давид Герштейн

Дом без дверей: как сделать базу знаний, которой реально пользуются

Руководитель попросил выгрузить список клиентов одного региона из воронки. Получил три числа: 80, 22, 17. Три человека, три фильтра, три версии правды. Никто не соврал — каждый смотрел в свой кусок системы. Это и есть цена отсутствия единого источника данных: не хакерская атака и не саботаж, а обычный рабочий день, где база знаний компании существует в головах, а не в системе. На выяснение, какое из трёх чисел верное, ушла встреча с тремя участниками — по грубой прикидке это час-полтора рабочего времени трёх сотрудников, то есть 3–4 часа × 1000 ₽ ≈ 3–4 тыс. ₽ за один эпизод (оценка). А таких эпизодов в месяц — не один.

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

Три ответа на один вопрос — не баг, а диагноз

История с 80/22/17 показательна тем, что проблема не в CRM и не в квалификации людей. Проблема в децентрализованном хранении данных: у каждого свой фильтр, своя выгрузка, своё понимание, что считать «активным клиентом». База знаний компании — это в первую очередь не документ с инструкциями, а согласованный источник правды: где лежит актуальная цифра, кто её обновляет, как её проверить.

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

Красивый дом без дверей

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

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

Тот же принцип разделения контента и упаковки работает и в производстве документов: в одной компании производственный цикл разбит на два блока — «производство» (сбор материала, интервью, структура) и «упаковка» (редактура, вёрстка, финальный вид). За оба блока отвечает один проект-менеджер, но исполнители разные. С базой знаний то же самое: тот, кто пишет контент, и тот, кто делает его доступным, — разные компетенции. Если это не разделить осознанно, получится дом без дверей.

Почему сотрудники всё равно спрашивают в чате

Финансовый сотрудник жаловался, что коллеги постоянно перебивают его просьбами об оплатах и срочных операциях. Он не успевал с основной работой и начал сомневаться в собственной компетентности. Руководитель разобрался — и корень оказался не в характере коллег и не в квалификации финансиста. Корень — в отсутствии структуры: не было выделенного времени в расписании, когда платежи обрабатываются, и все знали бы, что до 10 и после 11 дёргать бесполезно.

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

«Я бы хотел погруженно работать, ну, взял задачу, в неё погрузился и час ей занимался. А в большинстве случаев, если мне 15 минут удалось что-то поделать, это прям невероятная удача».

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

Механика: как база знаний компании собирается по шагам

Рабочая версия строится не сверху вниз (сначала портал, потом контент), а снизу вверх — из повторяющихся действий, которые уже происходят. В одной компании ввели простое правило: каждое выполняемое сотрудником действие либо документируется как инструкция, либо записывается на диктофон для последующей расшифровки. Схема такая:

1. Три попытки. Сотрудник берётся за задачу: первый раз — не вышло, второй — снова мимо, но уже по-другому, третий — получилось. Вот на этом моменте включается фиксация.
2. Чем фиксируется. Сотрудник не пишет текст — надиктовывает на диктофон или в голосовое сообщение, что он сделал, шаг за шагом.
3. Куда попадает. Запись автоматически транскрибируется и упаковывается моделью в структурированную инструкцию (шаги, формат, условия применения).
4. Кто и когда смотрит. Черновик инструкции уходит на проверку владельцу процесса (не автору, а ответственному за раздел базы), тот подтверждает или правит формулировки — без ручного набора текста с нуля.
5. Что дальше. После публикации к вопросу больше не возвращаются — при повторном возникновении такой же ситуации сотрудник получает ссылку на инструкцию, а не устный ответ.

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

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

ИИ-связка: от голосового до инструкции

Конвейер простой и его можно повторить на любом стеке, где есть Telegram-бот и вебхук: голосовое сообщение → транскрибация → структурирование моделью → черновик в таблице → проверка человеком → публикация.

Шаг транскрибации — это распознавание речи (модель уровня Whisper или встроенный STT платформы), он не требует рассуждений, только точность звука в текст. Шаг упаковки в инструкцию — это уже работа с текстом: выделить шаги, убрать оговорки, не потерять смысл. Здесь достаточно дешёвой модели уровня GPT-4o-mini или Claude Sonnet: команда уже проверяла на своём проекте — дорогая модель (Opus) и дешёвая (Sonnet) дали идентичный результат на одном и том же промпте структурирования текста. Переплата за токены на такой задаче — чистые потери.

Промпт для шага «упаковка» (вебхук из Telegram-бота или Make/n8n-сценария, вход — JSON с транскриптом):

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

Преврати расшифровку в пошаговую инструкцию для базы знаний.

Правила:
1. Убери слова-паразиты, повторы, оговорки не по делу.
2. Раздели процесс на пронумерованные шаги, один шаг — одно действие.
3. Названия систем, кнопок, полей сохраняй точно, не перефразируй.
4. Если шаг описан нечётко (пропущено действие, неясна
   последовательность) — не выдумывай, отметь как [проверить у автора].
5. Добавь блок "Когда применять" — 1-2 предложения о ситуации,
   в которой инструкция актуальна.

Верни строго JSON:
{
  "title": "короткое название инструкции",
  "owner": "employee_id из входных данных",
  "steps": ["шаг 1", "шаг 2"],
  "unclear": ["пункты, требующие уточнения, если есть"],
  "when_to_use": "условие применения"
}

Входные данные:
{
  "employee_id": "manager_14",
  "task": "оформление договора с ускоренным тарифом",
  "transcript": "текст расшифровки голосового сообщения"
}

Пример ответа модели:

{
  "title": "Оформление договора с ускоренным тарифом",
  "owner": "manager_14",
  "steps": [
    "Открыть карточку клиента в CRM",
    "Выбрать шаблон 'Ускоренный тариф' в разделе Договоры",
    "Заполнить поля: сумма, срок, дата первого платежа",
    "Отправить договор на подпись через встроенный сервис",
    "Поставить статус 'Договор отправлен' в карточке клиента"
  ],
  "unclear": ["Кто подтверждает тариф — руководитель или сам менеджер"],
  "when_to_use": "Клиент запрашивает сокращённые сроки оформления"
}

Инженерная обвязка: Telegram-бот принимает голосовое сообщение → вебхук в n8n (или Make) передаёт файл в API транскрибации → текст уходит в модель по промпту выше → результат складывается черновиком в Google Sheets (колонки: employee_id, title, steps, unclear, status) → ответственному за раздел базы приходит уведомление в Telegram с ссылкой на черновик. Если транскрибация вернула пустой текст или файл повреждён — бот отвечает сотруднику «не расслышал, запишите ещё раз», а ошибка логируется в отдельный технический чат, чтобы не потерять сигнал молча. Перезапуск ручной: по task_id можно повторно дёрнуть вебхук без пересборки всей цепочки.

Так выглядит сам черновик в таблице, прежде чем владелец раздела его подтвердит:

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

Тебе передан реестр статей базы знаний в формате JSON-массива:
каждая запись содержит title, last_updated (дата), views_30d (число
просмотров за 30 дней), owner, excerpt (первые 200 символов текста).

Проанализируй и верни:
1. stale — статьи, которые не обновлялись больше 6 месяцев,
   но продолжают активно просматриваться (views_30d > 20).
2. duplicates — пары статей, чьи excerpt пересекаются по смыслу
   более чем на 60% (возможное дублирование темы).
3. unused — статьи с views_30d = 0 за последние 30 дней.

Не выдумывай данные, которых нет во входном массиве.
Верни JSON: {"stale": [...], "duplicates": [[...]], "unused": [...]}

{
  "stale": ["Оформление возврата по договору"],
  "duplicates": [["Заявка на аванс", "Как провести предоплату"]],
  "unused": ["Регламент работы с архивом 2023"]
}

Модель здесь та же дешёвая: задача — сравнение текстов и дат, не творческая генерация. Запускать такой аудит достаточно раз в месяц вручную по кнопке или по расписанию в том же n8n.

Что видно на цифрах: где теряется время без базы знаний

На диаграмме ниже — те же потери в пересчёте на минуты в день по каждому сценарию:

Экономика: что это стоит и что даёт

Разберём вклад именно механики «диктофон → расшифровка → инструкция», не смешивая с другими инициативами вроде мониторинга звонков или дашбордов — у них своя отдельная экономика.

Стоимость внедрения. Формула словами: (часы инженера на настройку) × (ставка часа инженера) = разовые вложения. Настройка вебхука Telegram-бота, сценария транскрибации и промпта упаковки в n8n или Make — разовая работа инженера, оценочно 8–15 часов на первую рабочую версию (тестирование, обработка ошибок, шаблон в Google Sheets). По стандартной для рынка часовой ставке инженера это укладывается в диапазон «одна-две дневные ставки специалиста», то есть разовые вложения сопоставимы с одним-двумя рабочими днями инженера (оценка).

Стоимость эксплуатации. Формула словами: (число инструкций в месяц) × (стоимость транскрибации и вызова модели на одну инструкцию) = счёт за месяц. Транскрибация голосовых и работа дешёвой модели на структурирование текста — низкий по объёму трафик токенов. При потоке 10–20 инструкций в месяц счёт за месяц остаётся на порядок ниже стоимости одного часа работы сотрудника (оценка) — на порядок дешевле часа одного сотрудника.

Прямой эффект. Формула словами: (сэкономленные минуты на одну инструкцию) × (число новых инструкций в месяц) ÷ 60 × (ставка часа сотрудника) = прямая экономия в месяц. Возьмём небольшой отдел и консервативную оценку: письменная инструкция руками отнимала у автора порядка 30–40 минут (оценка — по аналогии с другими ручными задачами фиксации данных в отделах, например ежедневный отчёт вручную занимал около 30 минут в день), а через диктофон и автоматическую упаковку — 5–7 минут надиктовки плюс проверка черновика владельцем раздела. Экономия на одну инструкцию — около 30 минут (оценка, консервативно). При 10 новых инструкциях в месяц: 30 мин × 10 ÷ 60 = 5 часов в месяц (оценка) — меньше одного рабочего дня одного сотрудника. Немного — это только прямая экономия на написании текста.

На диаграмме — сравнение времени на одну инструкцию до и после ИИ-упаковки:

Экономия времени на одну инструкцию — с ~40 минут ручного написания текста до ~7 минут надиктовки на диктофон и проверки черновика владельцем раздела (оценка).

Косвенный эффект больше прямого. Он не в скорости написания, а в снятых прерываниях. Формула словами для своего случая: (число сотрудников) × (минуты в день на устные вопросы коллегам) × 20 рабочих дней ÷ 60 = потери на прерывания в часах в месяц; доля, которую снимает рабочая база знаний (сотрудник находит ответ сам, не отвлекая коллегу), — это и есть ожидаемый эффект. Если у небольшого отдела уходит хотя бы 15 минут в день на «спросить коллегу вместо поиска в базе» на человека — а по цитате из этой же компании 15 минут непрерывной работы уже воспринимаются как удача, — суммарно на отдел набегает пара часов в день, ×20 рабочих дней = порядка 40 часов в месяц (оценка) — почти целая рабочая неделя одного сотрудника. Если рабочая база знаний закрывает хотя бы половину таких вопросов напрямую (сотрудник находит ответ сам, не отвлекая коллегу), консервативная оценка снятого риска — около 20 часов в месяц, то есть половина обычной рабочей недели. Это оценка вклада именно базы знаний, без учёта параллельных инициатив вроде регламента приёма платежей или дашбордов для руководителей.

С чего начать в понедельник

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

Три числа — 80, 22, 17 — из истории в начале статьи чинятся не новым порталом. Чинятся правилом: один источник, один владелец, один способ проверки. Похожая логика применима и к контролю качества работы людей — переопределённые оценки в этой компании сначала показывают пробел и рекомендацию, а не штраф, и это тоже форма базы знаний, только персональной. Подробнее — в материале про контроль качества звонков без ОКК. А там, где база знаний должна пополняться из сканов и фото документов, а не из голосовых, полезно посмотреть, как точность распознавания документов выросла с 59% до 85%. Всё остальное — красивая обёртка, которая рано или поздно останется домом без дверей.

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

С чего начать базу знаний для сотрудников, если её никогда не было?

Не с портала. Зафиксируйте три-пять самых частых вопросов, которые сотрудники задают вручную коллегам или руководителю, — это и есть первые статьи базы.

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

Обычно потому, что в неё сложно попасть: нет точки входа, поиск не работает, контент собирали отдельно от того, как люди реально ищут ответ.

Как документировать процессы, если писать некогда?

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

#автоматизация #ии и нейросети #инструменты