База знаний в Битрикс24 с AI: как отвечать сотрудникам и передавать вопросы человеку

Если подтверждённого знания достаточно, AI может ответить сотруднику. Если нет, вопрос должен перейти человеку. Разбираем, что уже умеет Битрикс24 и как спроектировать эскалацию и безопасное пополнение базы знаний.

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

В Битрикс24 уже есть несколько инструментов для этой задачи. База знаний 2.0 позволяет хранить и структурировать внутренние материалы и управлять доступом.

Готовый AI-агент для поиска по базе знаний отвечает сотрудникам в отдельном чате по загруженным документам.

Агент BitrixGPT умеет искать по смыслу по доступным сотруднику базам знаний. (База знаний 2.0, AI-агенты, Агент BitrixGPT)

Но этого недостаточно, если нужен полный внутренний процесс с эскалацией, ответственными и контролируемым пополнением знаний.
Вся схема выглядит так: вопрос сотрудника -> поиск по знаниям -> ответ или передача человеку -> решение специалиста -> проверка -> обновление базы знаний

Главное здесь не чат-бот и не AI-агент сами по себе, а весь путь вопроса.

Что уже умеет Битрикс24, а что нужно проектировать

Штатными средствами Битрикс24 уже можно закрыть несколько важных частей сценария.

База знаний 2.0 поддерживает отдельные базы для разных отделов, структуру, права доступа и совместную работу со статьями.
Готовый AI-агент для поиска по базе знаний отвечает на типовые вопросы сотрудников по загруженным документам.
Если подходящей информации нет, он сообщает, что ответ не найден. (Официальная справка по Базе знаний 2.0, официальная справка по AI-агентам)

Для более сложных сценариев в новом конструкторе бизнес-процессов есть AI-агенты, RAG-база, работа с чат-ботами и ноды управления задачами. Отдельный триггер может запускать процесс, когда сотрудник пишет чат-боту. (AI-сценарии в бизнес-процессах, внутренние коммуникации, управление и распределение задач)

Из этого всё равно не следует, что весь контур внутренней поддержки уже собран как одна готовая функция. Самая важная часть начинается там, где подтверждённого ответа нет. Для полного процесса нужно отдельно определить:

• когда информации достаточно для ответа;
• что делать, если её недостаточно;
• во что превращается нерешённый вопрос;
• кому он назначается;
• как учитывать направление, очередь и срочность;
• что делать с ответом специалиста после решения;
• кто отвечает за качество нового знания.

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

База знаний 2.0 и готовые AI-агенты в актуальной документации Битрикс24 указаны для тарифов Профессиональный и Энтерпрайз. Новые возможности разворачиваются постепенно, поэтому перед проектированием нужно проверять конкретный портал и тариф. (База знаний 2.0, AI-агенты)

AI не исправит плохую базу знаний

При обсуждении AI-агента разговор быстро уходит в модели, RAG, векторный поиск и настройки самого агента. Но качество ответа начинается раньше. Сначала нужно понять, из чего вообще будет собрана база знаний. Это могут быть:

• инструкции;
• регламенты;
• внутренние документы;
• переписка;
• записанные видео;
• накопленные ответы специалистов;
• другие материалы компании.

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

AI не устраняет такие противоречия сам. Если исходные знания устарели или конфликтуют между собой, поиск не превращает их автоматически в единый правильный ответ.

Поэтому до AI-слоя нужно определить хотя бы 4 вещи:

1. какие источники считаются доверенными;
2. кто отвечает за их актуальность;
3. кому доступна конкретная информация;
4. что происходит со старой или противоречивой версией.

Права доступа здесь принципиальны. Например, Агент BitrixGPT ищет по базам знаний, доступным конкретному сотруднику, и формирует результаты с учётом его прав. (Официальная справка)

Практический вопрос здесь не “какую модель подключить?”, а “каким знаниям мы разрешаем системе доверять?”.

Если задача компании шире базы знаний и включает системное обучение работе в портале, отдельно можно посмотреть варианты обучения сотрудников Битрикс24.

Главная развилка: ответить или передать человеку

Представим обычный вопрос сотрудника.
Система нашла несколько материалов, похожих по смыслу. Этого ещё недостаточно, чтобы считать вопрос решённым.

Нужно различать два состояния:

• найден релевантный материал;
• найдено достаточно подтверждённой информации для ответа.

Если в утверждённой инструкции есть однозначное правило, по нему можно сформировать ответ.

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

Корректный результат может выглядеть так: “Подтверждённого ответа в базе знаний недостаточно. Вопрос нужно передать специалисту.” Это не сбой AI. Это нормальная ветка процесса.

Готовый AI-агент Битрикс24 для поиска по базе знаний уже умеет сообщать, что подходящий ответ не найден. Но внутренняя эскалация из такого состояния в задачу, процесс или другую рабочую сущность должна быть спроектирована отдельно. (Официальная справка по AI-агентам)

Для сравнения: в клиентских Открытых линиях у Битрикс24 есть готовый сценарий, где AI-агент при отсутствии ответа передаёт диалог оператору вместе с историей переписки. Для внутреннего контура сотрудников такую логику корректнее рассматривать как ориентир и собирать из доступных процессных инструментов, а не выдавать за готовый внутренний шаблон. (AI-агент в Открытых линиях)

У нерешённого вопроса должен появиться владелец.

Если ответа нет, вопрос должен стать управляемой заявкой

После решения “не отвечать” вопрос нужно перевести из режима поиска знаний в режим работы человека. Конкретная реализация зависит от процесса компании. Это может быть задача, элемент отдельного процесса или другой подходящий объект Битрикс24.

Название объекта вторично. Важно, чтобы у вопроса появились:

• ответственный;
• понятный статус;
• контекст исходного обращения;
• правила маршрутизации;
• срок или приоритет, если они нужны;
• история решения.

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

Битрикс24 Потоки, например, умеют распределять задачи между исполнителями, в том числе автоматически по очереди. В новом конструкторе бизнес-процессов ноды управления и распределения задач позволяют создавать задачи, назначать ответственных и реагировать на статусы или просрочки. (Потоки, ноды задач)

Поэтому маршрутизацию нужно проектировать под реальную ответственность в компании. Хорошая эскалация отвечает не только на вопрос “кому отправить?”. Нужно ещё определить:

1. Что передать специалисту вместе с вопросом?
2. Кто отвечает за результат, если первый исполнитель не может помочь?
3. Как понять, что вопрос действительно закрыт?

Без этого AI-часть может выглядеть современной, а внутренняя поддержка всё равно останется ручной и плохо управляемой.

Ответ специалиста ещё не стал знанием

Специалист получил вопрос и решил его.
Следующая очевидная идея - сразу добавить этот ответ в базу знаний, чтобы в следующий раз AI уже ответил сам. Но здесь нужен фильтр. Ответ специалиста может быть:

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

Поэтому закрытая заявка должна давать не готовое знание, а кандидат на знание.

Практическая цепочка: ответ специалиста -> проверка -> нормализация -> определение доступа -> публикация или обновление существующего материала

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

Такой фильтр защищает базу от ситуации, когда она быстро растёт по объёму, но становится менее надёжной. Это наша архитектурная рекомендация.

Замкнутый контур: исключения превращаются в проверенное знание

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

Контур выглядит так:

1. Сотрудник задаёт вопрос.
2. Система ищет ответ в доступных знаниях.
3. Если знания достаточно, сотрудник получает ответ.
4. Если недостаточно, вопрос переходит человеку.
5. Специалист решает вопрос.
6. Решение проверяют с точки зрения повторного использования.
7. Подходящее знание добавляют или обновляют.
8. Следующий похожий вопрос снова проходит через тот же контур.

Здесь важно не обещать, что с каждым вопросом AI автоматически становится “умнее”. Покрытие может расширяться, если вопросы действительно повторяются, а новые знания поддерживаются в актуальном состоянии. Это результат управляемой работы с знаниями, а не самообучения системы без участия человека.

Цель такого процесса не в том, чтобы убрать специалистов.
Более реалистичная цель - повторно использовать уже подтверждённые знания, а человеку оставлять вопросы, для которых готового надёжного ответа пока нет.

Как выглядит архитектура решения целиком

Если посмотреть на процесс сверху, у него несколько слоёв.

1. Источники знаний

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

2. Управляемая база знаний

Материалы приводятся к форме, пригодной для повторного использования. В Битрикс24 для этого есть База знаний 2.0. В конкретном проекте могут использоваться и дополнительные источники.

3. AI-поиск и формирование ответа

Сотрудник задаёт вопрос обычным языком. В готовом сценарии AI-агент может отвечать по загруженным документам. Агент BitrixGPT умеет искать по смыслу по доступным базам знаний. Для собственных бизнес-процессов можно использовать AI-агента вместе с RAG-базой, которая подключает его к векторному хранилищу материалов компании. (AI-агенты, Агент BitrixGPT, RAG-база)

Для сотрудника технический механизм вторичен. Важнее, по каким знаниям система ищет и что делает при недостатке информации.

4. Развилка “ответить или эскалировать”

Это центральное правило процесса.
Если подтверждённого знания достаточно - ответить.
Если недостаточно - перейти к человеческой ветке.

5. Управляемая заявка

Нерешённый вопрос получает владельца. Здесь проектируются:

• тип рабочей сущности;
• ответственный или группа;
• маршрутизация;
• очередь;
• срочность;
• сроки;
• контекст, который передаётся специалисту.

6. Решение специалиста

Человек разбирает исключение и даёт ответ сотруднику. Задача сотрудника может быть закрыта, но цикл знаний ещё не закончен.

7. Проверка и пополнение базы

Ответ оценивают как потенциальное новое знание. Если он подходит для повторного использования, создают или обновляют соответствующий материал.

8. Эксплуатация

После запуска база требует обычной рабочей поддержки:

• удалять устаревшее;
• устранять противоречия;
• пересматривать права доступа;
• отслеживать повторяющиеся нерешённые вопросы;
• видеть зоны, где знаний пока не хватает.

Получается не один AI-инструмент, а процесс, в котором Битрикс24 связывает знания, сотрудников, автоматизацию и ответственность.

Где достаточно стандартного Битрикс24, а где может понадобиться доработка

Такой сценарий, как и другие задачи автоматизации процессов в Битрикс24, лучше проектировать от простого к сложному.

Сначала проверить, что закрывается штатными возможностями:

• База знаний 2.0;
• готовый AI-агент для ответов по документам;
• поиск по базам знаний через Агента BitrixGPT;
• чат и чат-боты;
• задачи и Потоки;
• бизнес-процессы.

Затем определить, что можно собрать настройкой и автоматизацией:

• запуск процесса после сообщения сотрудника чат-боту;
• создание рабочей сущности после неуспешного поиска;
• передача контекста вопроса;
• назначение ответственного;
• смена статусов;
• уведомления;
• запуск проверки нового знания.

И только после этого решать, нужна ли интеграция или кастомная разработка. Она может понадобиться, если:

• знания хранятся во внешних системах;
• есть специфические правила маршрутизации;
• нужно учитывать сложные права доступа;
• требуется отдельная аналитика;
• стандартного объекта Битрикс24 недостаточно для внутреннего сервиса;
• процесс связан с другим корпоративным контуром.

Не имеет смысла начинать с кастома только потому, что в сценарии есть AI. Сначала нужно собрать минимально достаточный процесс и понять, какие реальные ограничения остаются.

Что проверить до внедрения

До настройки такого контура стоит ответить на несколько групп вопросов. Если процесс пока описан только списком пожеланий, полезно сначала зафиксировать сценарии, исключения и границы ответственности. Этот подход отдельно разобран в статье про ТЗ на внедрение Битрикс24.

Про знания

• Где находятся инструкции и ответы?
• Какие источники считаются актуальными?
• Есть ли противоречащие друг другу материалы?
• Кто владелец каждого блока знаний?
• Какие материалы имеют ограниченный доступ?
• Как обновляется или удаляется устаревшая информация?

Про ответы AI

• По каким источникам агент имеет право отвечать?
• Что считать достаточным знанием?
• Когда система должна отказаться от ответа?
• Нужно ли показывать сотруднику источник ответа?
• Какие категории вопросов всегда требуют человека?

Про эскалацию

• Во что превращается нерешённый вопрос?
• Какие данные из диалога нужно передать?
• Кто получает вопрос первым?
• Как определяется группа или специалист?
• Нужны ли очередь, приоритет и срочность?
• Что происходит при переадресации?
• Кто отвечает за окончательное закрытие?

Про пополнение базы

• Кто решает, что ответ подходит для повторного использования?
• Нужно ли создавать новую статью или обновлять существующую?
• Как обрабатывать дубли и противоречия?
• Как сохранять права доступа?
• Нужна ли дата пересмотра знания?
• Кто отвечает за дальнейшую актуальность?

Про архитектуру Битрикс24

• Что уже можно сделать штатно на конкретном портале?
• Какие AI-возможности доступны на текущем тарифе?
• Что собирается бизнес-процессами и настройками?
• Где действительно нужна интеграция?
• Есть ли задача, которую проще закрыть отдельным приложением?
• Что имеет смысл оставить человеку, а не автоматизировать?

Если на эти вопросы есть ответы, проектирование становится предметным. Можно обсуждать не “AI для базы знаний вообще”, а конкретный процесс с ролями, условиями и исключениями.

Главное

База знаний в Битрикс24 может быть не просто разделом с инструкциями. Её можно встроить в процесс внутренних вопросов, где AI помогает использовать уже накопленное знание, но не обязан отвечать любой ценой.

Основное правило: если подтверждённого знания достаточно - ответить; если нет - передать человеку; после решения - проверить, должно ли оно стать новым знанием.

Именно человеческая ветка и контроль пополнения базы отличают рабочий контур от обычного “чат-бота с документами”.

Если вам нужно собрать похожий процесс при внедрении или развитии Битрикс24, начинать стоит не с выбора AI и не с разработки. Сначала имеет смысл разобрать текущие источники знаний, типовые вопросы сотрудников и существующий путь эскалации.

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

Мы можем помочь структурировать текущие знания, спроектировать такой контур и реализовать его в Битрикс24 - от базы знаний и AI-агента до эскалации специалистам и контролируемого пополнения знаний. Начинаем с минимально достаточной архитектуры под ваш портал и рабочие правила, а затем доводим её до рабочего запуска.