ИИ-бот поддержки на сайте должен отвечать по вашей базе, а не по сценарию конструктора

Нужна ли разработка чат-бота для сайта с нуля? Начните с проверки готового сервиса на вопросах вашей поддержки.

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

Carrot quest советует переносить в базу сведения из сохранённых ответов операторов и обновлять их вместе с продуктом. Это уже работа с материалами компании.

Сценарный бот подходит для фиксированного маршрута, например выбора отдела. ИИ-бот нужен там, где клиент формулирует вопрос своими словами.

Бот должен найти правило в утверждённой базе и передать его модели вместе с вопросом. Поддержка принимает ответ вместе с найденным основанием.

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

Цена и статус заказа меняются: копия прайса не заменяет запрос в действующую систему. Свою CRM необязательно строить вместе с ботом.

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

Как понять, что бот не сочиняет? Проверять ответ вместе с материалом, на который он опирается. Уверенный тон ничего не доказывает.

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

Это история редакционной проверки, не бота поддержки. Для бота мы предлагаем тот же принцип: проверяющий видит вопрос, ответ и разрешённые материалы.

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

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

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

Можно ли сразу поручить боту всё? Объяснить порядок возврата и оформить возврат денег — разные полномочия. На пилоте их разделяют.

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

Общий FAQ не должен открывать чужой заказ. Ответ о личном статусе доступен только после проверки пользователя и его права видеть этот заказ.

Агент для кода и бот поддержки выполняют разные работы. Персональные данные и агенты — тема разработки; доступ бота к обращениям обсуждают отдельно.

Как не вернуться к ручным ответам после запуска? Сохранять вопросы, на которых бот ошибся, и исправлять их источник. Фраза в одном диалоге не меняет правило.

Мы ведём машину агентов через записанные описания. На странице машины в срезе 7 октября 2026 показаны 387 тысяч строк описаний против 391 тысячи строк кода.

Это объём всего проекта, не показатель точности бота. Числа показывают, что описание работы у нас сопоставимо по объёму с её исполнением.

В курсе «Агентная разработка» рецепт собирает инструкцию из документов. Урок «Мозг писателя роликов» показывает этот порядок в работе.

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

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

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

Свой бот нужен, если платформа не получает ваш источник, не соблюдает нужные права или не передаёт вопрос нужной команде. Это выясняют на проверке.

Если готовое решение отвечает по вашей базе и проходит приёмку, его достаточно. Свой код сам по себе не улучшает ответ.

Разработку начинают с одного типа обращений. Для учебного возврата это правила, уточнения и передача оператору; остальные задачи добавляют после проверки.

Срок такого пилота зависит от готовности материалов и связей с вашими системами. Как считать срок разработки с очередью, разобрано отдельно.

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

Второй шаг — подписка на агентную разработку. На /services тариф «Один проект» стоит 250 000 ₽ в месяц; это поток разработки, не готовый бот по фиксированной цене.

Код идёт в вашу ветку в вашем репозитории. Инженер ведёт машину агентов; следующая задача ждёт, пока закончена текущая.

В заказе отдельно фиксируйте расходы на ответы бота и сопровождение. Тариф разработки сам по себе не задаёт стоимость каждого диалога.

1. Проверьте готовый сервис на своих вопросах. База знаний есть и у платформ.

2. Назначьте владельца каждому правилу. Старую версию снимайте при обновлении.

3. Принимайте ответ вместе с основанием. В проверке нужны и правильные отказы.

4. Возвращайте ошибку в базу и набор вопросов. Передачу оператору проверяйте до запуска.