Порог уверенности: сколько автоматизации достаточно

На демо всё выглядит слишком гладко. Вы задаёте ассистенту вопрос из инструкции, он отвечает аккуратно, с нужной ссылкой и без лишней воды. Через минуту кто-то из команды спрашивает: «А если он не уверен?»

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

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

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

Низкий порог даёт больше ответов, но берёт кредит доверием

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

Цена появляется позже. Бот может ответить там, где в базе знаний есть похожая статья, но не хватает важного условия. Клиент спрашивает про возврат по годовому тарифу со скидкой, а ассистент находит общий текст про возвраты и пишет слишком широкое правило.

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

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

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

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

Высокий порог защищает от глупостей, но может съесть пользу

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

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

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

У высокого порога есть своя цена:

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

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

Порог стоит выбирать не по смелости, а по цене ошибки

Хороший вопрос не «какой порог правильный», а «какие ошибки мы готовы исправлять вручную». Для разных тем ответ будет разным.

Возьмём три типа обращений.

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

Второй тип — вопросы с условиями. «Можно ли вернуть деньги», «почему списалась оплата», «какой тариф мне нужен». Тут нужен более строгий режим. Ответ зависит от статуса клиента, даты, договора, скидки или старого условия. Если ассистент не видит этих деталей, лучше пусть подготовит черновик или позовёт человека.

Третий тип — конфликтные и нестандартные обращения. «Вы обещали другое», «мы потеряли доступ», «удалите все данные», «нас заблокировали». Здесь автоматический ответ должен быть особенно осторожным. Иногда лучший автоматический ответ — честно сказать, что нужен человек.

Важно не путать уверенность модели с уверенностью бизнеса. Ассистент может быть технически уверен, что нашёл похожий фрагмент. Но если в статье нет исключения для старого тарифа, бизнес-уверенности всё равно нет.

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

Менять порог нужно по двум спискам, а не по общему впечатлению

После запуска команда обычно смотрит на один набор примеров: где бот ошибся. Это правильно, но недостаточно. Если разбирать только ошибки, порог почти всегда хочется поднять.

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

Разбор должен идти в обе стороны.

В список «поднять порог» попадают диалоги, где ассистент:

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

В список «снизить порог» попадают диалоги, где ассистент:

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

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

Есть ещё один момент: порог меняется вместе с базой знаний. Добавили статью про возвраты со скидкой — можно пересмотреть часть вопросов про возврат. Убрали старый тариф — надо проверить, не ссылается ли ассистент на устаревшие материалы. Запустили новый канал обращений — первые дни лучше смотреть диалоги чаще.

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

Автоматический ответ должен уметь остановиться

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

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

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

Порог — это не только про качество ответов. Это про границы ответственности. Где можно дать инструкцию сразу, где нужен черновик для оператора, а где лучше не имитировать уверенность.

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

В DeskAI у автоответа есть порог уверенности: если он ниже заданного значения, ассистент не отвечает, пишет, что зовёт человека, и передаёт разговор команде. Когда оператор вошёл в разговор, бот молчит до конца обращения. Ответы строятся по базе знаний рабочей области, а источники видны в ответе.