Как разделить типовые и сложные вопросы клиентов в базе знаний ИИ-продавца
База знаний ИИ-продавца работает лучше всего, когда в ней заранее разделены два типа информации. Типовые вопросы имеют устойчивый подтверждённый ответ: формат услуги, перечень документов, общие характеристики, порядок первого шага. Сложные вопросы зависят от ситуации, актуальных данных или профессионального решения. Их не нужно заставлять ИИ закрывать любой ценой — правильнее задать условие передачи сотруднику.
В Omnexa база знаний используется вместе со сценарием первой линии. Сценарий определяет, что ИИ спрашивает, когда создаёт заявку и когда зовёт человека, а компоновщик позволяет проверить разные ветки до запуска.
Почему нельзя просто загрузить все документы
Большой объём текста сам по себе не делает ответы надёжнее.
Если в материалах одновременно лежат:
- актуальные и старые условия;
- общие правила и исключения;
- рекламные формулировки;
- черновики;
- индивидуальные договорённости,
ИИ сложнее понять, что считать рабочим фактом.
База знаний должна быть рабочим источником, а не архивом компании.
Что считать типовым вопросом
Типовой вопрос имеет три признака:
1. Он повторяется у разных клиентов. 2. Ответ не зависит от индивидуального решения сотрудника. 3. Данные можно поддерживать актуальными.
Примеры:
- какие услуги есть;
- как проходит первый этап;
- какие данные нужны для заявки;
- какие общие документы требуются;
- как связаться с сотрудником;
- какие форматы работы доступны.
Если эти факты подтверждены и актуальны, их удобно отдавать первой линии.
Что считать сложным вопросом
Сложность определяется не длиной вопроса, а ответственностью за ответ.
К сложным относятся ситуации, где:
- нужна профессиональная оценка;
- есть индивидуальные условия;
- данные меняются в реальном времени;
- требуется согласование;
- недостаточно исходных данных;
- ошибка может создать обязательство для бизнеса.
Например, точная цена индивидуального проекта, свободный слот, юридический вывод, медицинская рекомендация или персональная скидка.
Отдельная группа: переменные факты
Есть вопросы, которые кажутся типовыми, но ответ на них быстро меняется.
Например:
- «Есть ли товар в наличии?»
- «Когда ближайшее свободное время?»
- «Какая цена сегодня?»
- «Сколько займёт выполнение?»
Если Omnexa не получает подтверждённое актуальное значение из соответствующего источника, такой ответ нельзя хранить как вечный факт.
В базе знаний лучше описать правило: что уточнить и кому передать вопрос.
Как собрать вопросы для базы
Начните с реальных диалогов.
Возьмите переписки за несколько недель и отметьте повторяющиеся темы. Затем распределите их в четыре колонки:
А. Типовой факт
Можно отвечать автоматически.
Б. Типовое правило процесса
Например, какие данные нужны до расчёта.
В. Переменный факт
Требует актуального источника или сотрудника.
Г. Индивидуальное решение
Всегда передаётся человеку.
Такой разбор часто полезнее, чем попытка сразу написать идеальный промпт.
Как оформлять типовой ответ
Для каждой темы полезно хранить не только текст ответа, но и контекст применения.
Например:
Вопрос: что нужно для начала?
Факт: перечень обязательных данных.
Условие: применяется к стандартной услуге.
Если ситуация другая: передать сотруднику.
Так снижается риск, что общий ответ будет применён к исключению.
Как описывать сложный вопрос
Для сложной темы база знаний может содержать не сам «готовый ответ», а маршрут.
Например:
1. Уточнить тип запроса. 2. Собрать два исходных параметра. 3. Сообщить, что вопрос требует специалиста. 4. Создать заявку по правилу. 5. Передать контакты и контекст сотруднику.
Это тоже полезная автоматизация: ИИ не решает задачу, но готовит её для человека.
Где хранить ограничения
Критичные запреты лучше дублировать в сценарии, а не надеяться только на содержание базы знаний.
Например:
- не придумывать цену;
- не подтверждать наличие без актуальных данных;
- не обещать срок;
- не давать профессиональный вывод;
- по просьбе клиента передавать сотруднику.
Так граница становится правилом поведения, а не скрытой особенностью документа.
Как проверить базу в компоновщике
В Omnexa тестовые диалоги позволяют задавать реальные вопросы от лица клиента.
Проверьте три группы.
Типовые вопросы
Ответ должен быть точным и коротким.
Переформулировки
Один и тот же смысл задайте разными словами.
Пограничные вопросы
Намеренно задайте вопрос, где ответа не хватает. ИИ должен признать границу и передать человеку, а не достраивать факты.
Что делать, если ИИ отвечает слишком широко
Сначала определите источник проблемы.
Возможные причины:
- база знаний содержит слишком общий текст;
- в одном документе смешаны разные ситуации;
- сценарий не задаёт ограничения;
- вопрос должен был быть передан сотруднику;
- используются устаревшие данные.
Исправляйте конкретную причину. Не добавляйте ещё больше текста без необходимости.
Как связать базу знаний с заявкой
Сложный вопрос должен приводить к понятному действию.
Если нужен сотрудник, сценарий может создать заявку, а уведомление — передать контакты и содержание или выжимку диалога. Во встроенной CRM можно назначить воронку, стадию и ответственного.
Тогда «не знаю» превращается не в тупик, а в контролируемую передачу.
Пример для сервисного бизнеса
Клиент спрашивает: «Какие документы нужны?»
Это типовой вопрос. Ответ есть в базе знаний.
Затем спрашивает: «Подойдёт ли мой случай под исключение из договора?»
Это индивидуальная ситуация. ИИ не должен интерпретировать договор. Он фиксирует вопрос и передаёт сотруднику.
Обе ветки полезны: первая экономит время, вторая защищает качество решения.
Как поддерживать структуру базы
Полезно назначить владельца информации. Его задача — не писать ответы каждый день, а следить за изменениями.
При обновлении продукта проверьте:
- какие типовые ответы изменились;
- какие ограничения появились;
- какие вопросы больше нельзя закрывать автоматически;
- какие новые повторяющиеся темы появились.
Как превратить реальные переписки в структуру базы знаний
Практический способ — раз в месяц брать выборку диалогов и отмечать вопросы маркерами: «ответ есть», «ответ устарел», «нужен человек», «новая тема». После этого повторяющиеся вопросы объединяются в группы. Для каждой группы команда решает, нужен ли готовый факт или только правило маршрутизации.
Например, десять разных формулировок вопроса о порядке оплаты могут сводиться к одной теме. Если правила оплаты стабильны, в базе знаний достаточно одного канонического блока. А десять вопросов о точной цене индивидуального проекта не превращаются в один универсальный ответ — здесь правильнее описать, какие вводные собрать и кому передать запрос.
Такой подход уменьшает объём базы, но повышает её полезность: вместо сотен похожих фраз остаются понятные факты и правила.
Как проверять границы автоматизации
Для каждой темы придумайте три теста: обычный вопрос, вопрос с недостающими данными и вопрос с индивидуальным исключением. Если ИИ одинаково уверенно отвечает во всех трёх случаях, возможно, граница задана слишком широко. Правильный сценарий должен уметь отличать факт от ситуации, где требуется подтверждение человека.
Как не перегружать базу знаний
При каждом обновлении задавайте ещё один вопрос: этот фрагмент действительно помогает ответить клиенту или выполнить следующий шаг? Внутренние справки, длинная история компании и материалы без практической роли лучше не смешивать с рабочими ответами первой линии. Чем яснее назначение каждого блока, тем проще поддерживать актуальность и тестировать изменения.
Что делать с новыми вопросами
Если в реальных чатах появляется тема, которой ещё нет в базе, не добавляйте первый попавшийся ответ. Сначала соберите несколько примеров, подтвердите факт у владельца процесса и решите, относится ли вопрос к типовым или должен оставаться маршрутом к сотруднику.
Чек-лист разделения вопросов
Проверьте каждую тему:
- ответ устойчив и подтверждён?
- зависит ли он от текущих данных?
- требуется ли профессиональная оценка?
- может ли сотрудник согласовать исключение?
- что делать, если данных нет?
- когда создавать заявку?
- кому передавать сложный случай?
- получает ли сотрудник контекст?
- протестирована ли пограничная формулировка?
Сильная база знаний Omnexa не пытается сделать ИИ экспертом во всём. Она чётко описывает то, что можно отвечать уверенно, и заранее задаёт маршрут для сложных случаев. Именно эта граница делает первую линию полезной и безопасной для бизнеса.