Чем кормить ИИ-ассистента, чтобы он отвечал по делу

В папке «База знаний» лежат три документа: регламент возвратов на 18 страниц, инструкция для операторов с красными комментариями и старая статья «Частые вопросы», которую никто не открывал с прошлого года.

Команда подключает ИИ-ассистента и ждёт, что он начнёт отвечать клиентам. Формально материал есть. По факту ассистенту дали не ответы, а кухню поддержки: кто кому пишет, какие статусы проверяет, где в админке нажимает кнопку.

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

Регламент помогает оператору, но путает ассистента

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

Для оператора это рабочая инструкция. Он понимает, что сказать клиенту, а что оставить внутри команды.

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

Плохой источник для ассистента:

Если заказ в статусе HOLD, проверить оплату в биллинге. При отсутствии подтверждения создать тикет в финансы. Клиенту сообщить стандартную формулировку.

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

Хороший источник:

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

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

Статья для клиента отвечает, а не описывает процесс

У хорошей статьи для ассистента есть простая форма: вопрос клиента, короткий ответ, шаги, условия и исключения. Не всё сразу, не энциклопедия, не раздел регламента.

Например, тема «возврат оплаты» для сотрудника и для клиента выглядит по-разному.

Для сотрудника важно:

• где проверить статус платежа;
• кто согласует возврат;
• какие случаи отправлять в бухгалтерию;
• что писать в CRM;
• когда ставить приоритет.

Для клиента важно другое:

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

Обе версии нужны. Но кормить ассистента стоит второй.

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

Есть ещё одна разница. Регламент часто отвечает на вопрос «что делает компания». Клиентская статья отвечает на вопрос «что делать мне».

«После обращения клиента оператор создаёт задачу на склад» — это процесс компании.

«Напишите номер заказа. Мы проверим, успели ли передать его на склад. Если заказ ещё не собран, адрес можно изменить» — это ответ клиенту.

Для ассистента второе полезнее, потому что оно уже похоже на готовую реплику.

Ассистенту нужны границы, а не красивые формулировки

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

Ассистенту это почти не помогает. Ему нужны не украшения, а границы.

Хорошая статья говорит:

• когда ответ «да»;
• когда ответ «нет»;
• какие данные нужны;
• куда не стоит обещать;
• в какой ситуации нужен человек.

Например, статья «Можно ли изменить адрес доставки» должна содержать не только «да, напишите нам». В ней важно разделить случаи:

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

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

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

Отсюда практический вывод: плохая база знаний не становится хорошей от того, что её подключили к ИИ. Она просто начинает быстрее показывать свои дыры.

Один внутренний документ лучше разбить на пять клиентских ответов

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

Для человека это удобно: всё в одном месте.

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

Лучше делать мелкие статьи:

• «Как вернуть товар, если он не подошёл»;
• «Как обменять размер»;
• «Что делать, если товар пришёл с браком»;
• «Когда вернутся деньги после отмены заказа»;
• «Можно ли вернуть товар без упаковки».

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

Зато потом каждую статью проще проверять. Если ассистент неверно ответил про обмен размера, вы правите статью про обмен размера, а не весь регламент возвратов.

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

Текст должен выдержать копирование в чат

Самая простая проверка клиентской статьи: можно ли скопировать её первый абзац в ответ клиенту почти без изменений.

Если нельзя, статья, скорее всего, написана не для клиента.

Возьмём внутреннюю формулировку:

Возврат ДС производится после получения товара на РЦ и проверки комплектации. При нарушении товарного вида решение принимает старший смены.

Для базы ассистента лучше так:

Мы вернём деньги после того, как товар приедет на склад и его проверят. Если товар был в использовании или вернулся не полностью, возврат могут не согласовать. В таком случае оператор напишет вам и объяснит причину.

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

Ещё пример.

Внутри команды:

При запросе закрывающих документов проверить карточку ЮЛ, ИНН, наличие акта в ЭДО. Если ЭДО не подключён, отправить шаблон бухгалтерии.

Для клиента:

Чтобы получить закрывающие документы, напишите ИНН компании и период, за который нужны документы. Если у вас подключён ЭДО, мы отправим документы туда. Если ЭДО нет, подскажем, как получить копию другим способом.

Второй текст не рассказывает, что оператор делает в админке. И не должен. Он снимает вопрос клиента.

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

В базе не должно быть того, что стыдно показать клиенту

Есть документы, которые вообще не стоит давать ассистенту как источник для клиентских ответов.

Например:

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

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

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

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

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

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

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