Как создать чат-бота для сайта в 2026 году: три пути от конструктора до кода

Чат-бота для сайта можно поставить тремя разными способами, и они не взаимозаменяемы: то, что в конструкторе занимает вечер, в коде растягивается на пару месяцев, а то, что код делает точно под задачу, конструктор не умеет в принципе. Дальше не рейтинг сервисов и не расчет их тарифов: этот разбор в статье про конструкторы чат-ботов. Здесь сам процесс сборки бота для сайта тремя путями: готовый конструктор, ИИ-платформа с базой знаний и код с нуля, и как выбрать между ними под свою задачу.

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

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

Содержание

• С чего начать: задача, вопросы, канал
• Путь 1: готовый конструктор
• Путь 2: готовая ИИ-платформа с базой знаний
• Путь 3: свой код и API
• Сколько стоит и сколько времени
• Как выбрать свой путь
• Частые ошибки при самостоятельной сборке
• Частые вопросы

С чего начать: задача, вопросы, канал

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

Что проверить:

• Сценарий или свободные вопросы. Если задача записать на консультацию, провести квиз или собрать заявку по фиксированной анкете, подойдет жесткий сценарий с ограниченным числом веток. Если клиенты спрашивают вразнобой про наличие, сроки, характеристики конкретного товара, сценарий начнет проседать уже на второй-третьей ветке диалога.
• Сколько вопросов бот должен закрывать. Выпишите реальные 15–20 вопросов, которые чаще всего задают в переписке или по телефону за последний месяц. Если из них 4–5 повторяются почти дословно, годится сценарий. Если формулировки каждый раз разные, а тема одна и та же, нужен бот, который ищет ответ по смыслу, а не по совпадению фразы с заранее прописанным вариантом.
• Канал. Статья про бота на сайте: он подключается как виджет, строка кода на странице, без токенов и регистрации у стороннего мессенджера. У бота в Telegram механика другая: там сначала регистрируют бота у @BotFather, который выдает токен доступа, а дальше общение идет через Bot API, отдельный упрощенный HTTPS-интерфейс поверх основного Telegram API. Если бот нужен именно в Telegram, а не на сайте, процесс с токеном и лимитами разобран в статье про создание бота в Telegram.

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

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

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

Путь 1: готовый конструктор

No-code конструктор — это редактор сценария: вопрос, варианты ответа кнопками, условие, следующий шаг. Кода не требуется, интерфейс представляет собой блок-схему, которую собирают мышкой, перетаскивая карточки шагов и соединяя их стрелками условий.

Собрать простого бота в конструкторе можно за вечер. По оценке сервиса BotHelp, готовый шаблон настраивается за 2–3 часа, а самостоятельное освоение интерфейса с нуля занимает 5–15 часов; полный цикл запуска укладывается в один рабочий день, максимум в 2–3 при параллельных задачах. Для приветственного бота без сложной логики счет вообще идет на минуты: простые сценарные боты для мессенджеров запускают за 10–30 минут по гайдам вендоров облачных платформ, и это нижняя граница, а не рекламное преувеличение.

Клиент: А если я заберу заказ сам, скидка будет? Бот: Не понял вопрос. Выберите один из вариантов: Доставка / Оплата / Контакты

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

Где ломается: у кнопочного бота физически нет механизма разбора вопроса, которого нет в дереве сценария. Он либо возвращает клиента в меню, либо молчит, и оба варианта читаются посетителем сайта одинаково: бот не работает. По кейсу компании Just AI на банковском NLU-боте, уже более продвинутом, чем чисто кнопочный, но все еще не языковая модель, расширение сценариев и добавление новых интентов упиралось в потолок: почти каждый второй диалог все равно уходил на живого оператора, сколько веток ни добавляй. Переход на LLM-агента поднял долю автоматизации с 37% до 64,2%. Это кейс одного вендора о своем клиенте, а не независимое исследование, но порядок цифр показателен: проблема не в том, что сценарий плохо настроен, а в самой архитектуре подхода. Чем шире каталог и чем разнообразнее формулировки вопросов, тем раньше конструктор упирается в этот потолок.

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

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

Типичные задачи, где конструктор справляется хорошо: запись на консультацию или услугу, квиз подбора товара по параметрам, сбор заявки по фиксированной анкете, ответы на 5–7 самых частых вопросов из FAQ. Общий признак: конечное и предсказуемое число вариантов развития разговора, которое можно нарисовать на одном листе бумаги.

Тарифы у большинства конструкторов растут не по сложности сценария, а по объему: числу подписчиков или сообщений в сутки. По официальным страницам вендоров на 11 августа 2026 года у Aimylogic это от 1089 ₽/мес на тарифе Startup до 16 390 ₽/мес на Premium, у BotHelp тарифы Creator и Pro начинаются от 1599 ₽/мес, а верхний тариф Scale, от 29 990 ₽/мес. У Chatforma входной платный тариф стоит 2000 ₽/мес за одного бота при пробном периоде в 15 дней. Разброс большой, но для сайта с несколькими сценариями и умеренным потоком обращений почти всегда достаточно входного тарифа, а не самого дорогого плана в линейке.

Подробный разбор конкретных сервисов, Salebot, BotHelp, Chatforma, Aimylogic, лимиты бесплатных тарифов и на что смотреть при выборе, в статье про конструкторы чат-ботов. Здесь важнее другое: конструктор хорошо решает задачу с фиксированным числом веток и плохо решает задачу «ответь на любой вопрос про наш каталог». Для записи на стрижку, квиза подбора товара или сбора заявки на замер это ровно тот инструмент, который нужен, и переплачивать за более сложный путь здесь бессмысленно.

Путь 2: готовая ИИ-платформа с базой знаний

Ключевое отличие от конструктора не в интерфейсе, а в механике ответа. Конструктор идет по заранее прописанному дереву. ИИ-платформа ищет ответ в загруженных материалах сайта, прайсе, карточках товаров, условиях доставки, и формулирует его заново под конкретный вопрос, а не выбирает готовую фразу из списка. Схему, при которой бот сначала находит нужный фрагмент базы и только потом отвечает, называют RAG, как она устроена изнутри на уровне эмбеддингов и векторного поиска, мы разбирали в статье что такое ИИ чат-бот. Здесь не повторяем теорию, только практический путь подключения.

Путь подключения обычно одинаковый у всех вендоров этого типа:

• Регистрация в сервисе. Занимает несколько минут, отдельного согласования не требует.
• Загрузка базы знаний. Страницы сайта, прайс, документы с условиями: то, по чему бот будет искать ответы.
• Настройка под бренд. Цвет, положение окна на экране, приветственное сообщение, тон ответов.
• Одна строка кода на сайт. Виджет вставляется в шаблон страницы так же, как обычный скрипт аналитики; про конкретные способы вставки под WordPress и Bitrix в статье про установку виджета чата.

Клиент: А если я заберу заказ сам, скидка будет? Бот: Да, при самовывозе скидка 5%, это указано в разделе «Доставка и оплата». Оформить самовывоз сейчас?

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

Порог входа здесь такой же низкий, как у конструктора: программирование не требуется ни на одном из четырех шагов. Разница в том, куда уходит время после установки. У конструктора время тратится на построение и постоянную донастройку веток. У ИИ-платформы, на сбор и актуализацию базы знаний: если прайс на сайте обновился, а файл в базе знаний остался старым, бот начнет уверенно называть неактуальную цену, оставаясь при этом технически исправным.

Что проверить при сборке базы знаний: нет ли на сайте двух версий одного документа (старый PDF-прайс рядом с новой страницей цен); попадают ли в базу технические разделы сайта, не относящиеся к вопросам клиентов (юридические тексты, страницы вакансий); отражены ли в загруженных материалах реальные условия, а не рекламные формулировки («доставка быстро» без цифры в днях сбивает бота с толку так же, как и живого оператора).

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

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

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

Мини-вывод: ИИ-платформа экономит не время на установку, оно и у конструктора небольшое, а время на постоянную донастройку сценария, которую иначе пришлось бы делать вручную при каждом новом типе вопроса от клиентов.

Путь 3: свой код и API

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

Что нужно, чтобы собрать бота на своем коде:

• Фронтенд-виджет на сайте, который отправляет сообщение пользователя и показывает ответ: тот же визуальный слой, что и у готового виджета, только написанный самостоятельно.
• Бэкенд, принимающий сообщение и обращающийся к API языковой модели с системным промптом, инструкцией, что за роль у бота и как отвечать на вопросы посетителей.
• Обработка базы знаний: документы сайта разбиваются на фрагменты, для каждого считается эмбеддинг, числовое представление смысла текста, и все это сохраняется в векторной базе данных.
• Поиск по смыслу перед ответом: на вопрос клиента ищутся несколько ближайших по смыслу фрагментов базы (обычно 3–4), они добавляются в промпт, и только после этого модель формулирует ответ. Это и есть RAG на практике: без него модель отвечает по общим знаниям, а не по материалам конкретного сайта.

По документации Vercel AI SDK, кукбука для сборки таких ботов, типовой пайплайн выглядит так: текст разбивается на чанки, для каждого чанка вызывается модель эмбеддингов (в примере из документации, размерность вектора 1536), готовые векторы хранятся в таблице рядом с исходным текстом фрагмента, а поиск идет по косинусному сходству между вектором вопроса и векторами базы. Инструкция модели формулируется жестко: отвечать только на основании найденных фрагментов, а не додумывать факты из общих знаний, иначе модель при нехватке контекста начнет генерировать правдоподобный, но неверный ответ.

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

Размер чанка, на которые режется база знаний, влияет на качество ответов сильнее, чем кажется на первый взгляд. Слишком крупный фрагмент, вся страница целиком, тянет в контекст лишний текст и размывает релевантность поиска; слишком мелкий, одно предложение, теряет связь с соседними условиями (например, отрывает цену от условия, при котором она действует). На практике для карточек товаров и коротких разделов сайта неплохо работает деление по смысловым блокам, абзац или пункт списка, а не по фиксированному числу символов.

Где ломается: доступ к API. У Anthropic России нет в официальном списке поддерживаемых регионов для Claude API, а OpenAI API для российских карт и IP-адресов заблокирован технически, независимо от физического местоположения разработчика. Прямого легального способа платить обоим вендорам из России нет: рынок пользуется сторонними агрегаторами, которые перепродают доступ, но это посредническая схема в обход геоограничений вендора, а не официальный канал, и такой доступ можно потерять в любой момент без предупреждения.

Рабочая альтернатива без этих сложностей: российские API. У GigaChat от Сбера есть режим совместимости с SDK OpenAI, то есть можно использовать привычный клиент с измененным адресом сервера, а для физлиц действует бесплатный лимит токенов, хотя точный размер лимита на разных страницах документации указан по-разному, поэтому актуальную цифру стоит смотреть на сайте сервиса перед стартом, а не полагаться на цифру из обзорной статьи. Аналогичный вариант, YandexGPT API от Yandex Cloud, тоже существует и обслуживает российские аккаунты без ограничений доступа, но актуальные цены на момент подготовки статьи проверить не удалось: страница тарифов закрыта капчей от автоматических запросов.

Минимальный вызов GigaChat выглядит так:

from gigachat import GigaChat

giga = GigaChat(
    base_url="https://api.giga.chat/v1",
    credentials="ключ_авторизации",
)
response = giga.chat("Сколько стоит доставка в Тулу?")
print(response.choices[0].message.content)

Это минимальный запрос без базы знаний. На практике перед вызовом giga.chat() в промпт добавляют системную роль бота и найденные фрагменты базы знаний, а не отправляют вопрос клиента напрямую без контекста: без этого шага модель ответит по общим знаниям про доставку вообще, а не по реальным условиям конкретного магазина.

Если команда все же работает через посредника с доступом к OpenAI, синтаксис вызова у актуального Responses API отличается от привычного chat completions, системный промпт передается отдельным параметром instructions:

from openai import OpenAI

client = OpenAI()
response = client.responses.create(
    model="gpt-5.6",
    instructions="Ты консультант интернет-магазина. Отвечай только по базе знаний.",
    input="Сколько стоит доставка?",
)
print(response.output_text)

Что проверить в архитектуре до запуска:

• Хранение ключа API. Ключ языковой модели не должен попадать в код фронтенда, который открыт в браузере клиента: запрос к модели идет с бэкенда, а не напрямую из виджета.
• Лимиты и мониторинг расходов. В отличие от подписки на конструктор или ИИ-платформу с фиксированной ценой, оплата по API идет за токены, и без лимита на бэкенде один затянувшийся диалог или атака ботом-парсером способны неожиданно раздуть счет за месяц.
• Хостинг бэкенда. Векторная база и код обработки запросов требуют своего сервера или облачной функции, а не просто статического хостинга, на котором обычно лежит сам сайт.
• Обновление базы знаний. У готовой платформы переиндексация страниц происходит по кнопке в интерфейсе; в своем коде для этого нужен отдельный скрипт или процесс, который кто-то должен запускать регулярно.

Сколько это стоит, если делать не самому, а заказывать. По собственному опросу компании Just AI среди 24 студий-разработчиков с одинаковым техзаданием: медиана цены 227 000 ₽, среднее по всем предложениям 294 184 ₽, а сроки растянулись от 5 до 68 рабочих дней, с ожидаемым диапазоном 25–30 дней. Независимо, по данным блога BotHelp, кастомная разработка с нуля обходится от 250 000 ₽ и занимает 1,5–4 месяца, это близко к цифрам Just AI по порядку величины, хотя оба источника сами игроки рынка конструкторов и могут быть заинтересованы показать разработку с нуля дорогой альтернативой на своем фоне.

Мини-вывод: путь оправдан только там, где нужна нестандартная интеграция, с внутренней CRM, 1С, специфичной логикой, которую ни один готовый сервис не поддерживает, и в компании уже есть кому это поддерживать после запуска: обновлять зависимости, следить за квотами API, чинить парсинг документов при смене формата. Для типовой задачи «отвечать клиентам по каталогу» этот путь почти всегда избыточен по деньгам и срокам.

Отдельно стоит учесть, что языковые модели время от времени обновляются самими вендорами, и ответ, который бот давал вчера, после смены версии модели может измениться по формулировке или качеству, даже если промпт и база знаний не трогали. У готовой ИИ-платформы вендор берет на себя проверку новых версий перед их включением в продукт; при своем коде эту проверку приходится делать самостоятельно, иначе обновление модели на стороне вендора способно неожиданно изменить поведение бота на боевом сайте.

Сколько стоит и сколько времени

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

Тарифы конструкторов сняты с официальных страниц вендоров 11 августа 2026 года, цифры по разработке из открытых данных Just AI и BotHelp.

У конструктора и ИИ-платформы цена входа сопоставима, разброс от нуля на бесплатных тарифах до нескольких тысяч рублей в месяц на старших планах при росте числа подписчиков. Разница между этими двумя путями не в деньгах на старте, а в том, что вы получаете за эти деньги: набор кнопок с ветками или поиск ответа по смыслу.

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

Разбивка внутри пути «свой код» показывает, что «заказать у эксперта» и «нанять студию» не одно и то же по деньгам.

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

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

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

Как выбрать свой путь

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

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

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

Если нужна нестандартная интеграция с внутренними системами, CRM, 1С, специфичная бизнес-логика, и в штате уже есть кому это поддерживать, оправдан свой код. Без своей команды разработки этот путь почти всегда обходится дороже и дольше, чем кажется на старте: цифра в коммерческом предложении студии редко включает поддержку после запуска.

Признак, что пора переходить с одного пути на другой, а не оставаться на прежнем из инерции: доля вопросов, которые бот не может закрыть сам. Для конструктора это доля диалогов, ушедших на живого оператора при том, что вопрос был типовым; если она растет месяц к месяцу, дерево сценария перестало покрывать реальный поток вопросов, и пора переходить на поиск по базе знаний. Для ИИ-платформы аналогичный сигнал, повторяющиеся запросы на функциональность, которой у платформы нет в принципе (глубокая интеграция с внутренней системой), а не просто нехватка контента в базе, которую можно исправить, просто дозагрузив материалы.

Пути не исключают друг друга. Рабочая практика: начать с готовой ИИ-платформы, чтобы быстро закрыть основной поток вопросов, а кодом дорастить только нестандартные случаи, которые платформа не покрывает, например прямую передачу заказа из диалога в 1С. Так тратится меньше денег на старте, а решение о более дорогом пути принимается уже с реальными данными о том, сколько диалогов бот обрабатывает и какие вопросы в них повторяются чаще всего.

Для интернет-магазина на Insales, Bitrix, Tilda или WooCommerce типичная точка входа, конструктор для одного простого сценария (например, подбор размера по таблице) и параллельно ИИ-платформа для остальных вопросов по каталогу, а не выбор одного пути на все случаи сразу. Для сайта услуг с понятным и стабильным набором вопросов чаще достаточно одного конструктора без ИИ-платформы вообще. Свой код в обоих случаях оправдан не на старте, а тогда, когда накопленная статистика диалогов явно указывает на конкретную нестандартную задачу, которую готовые сервисы не решают.

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

Частые ошибки при самостоятельной сборке

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

Типичная поломка: CORS и политика безопасности сайта. Браузер блокирует запросы виджета с чужого домена, если сервер сайта не разрешил это явно, ошибка выглядит как ссылка на Content Security Policy в консоли разработчика, а не как поломка самого виджета. У Tidio, например, в официальной документации прямо перечислены домены и директивы, которые нужно внести в CSP сайта, чтобы виджет заработал корректно, у большинства других сервисов аналогичная настройка есть, но называется иначе и лежит не всегда на видном месте личного кабинета. Внешне поломка выглядит одинаково у любого сервиса: кнопка чата видна на странице, но при клике окно диалога не открывается или открывается пустым, а в консоли браузера (F12 → Console) видна красная строка про заблокированный запрос.

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

Вторая типичная поломка: кеш CMS. Плагины кеширования вроде WP Rocket объединяют и кешируют скрипты страницы, и виджет, который отлично работал в момент установки, может перестать обновляться или отображаться после следующего изменения кода на сайте. В официальной документации WP Rocket есть отдельная функция, исключение конкретного скрипта из оптимизации, и это первое, что стоит проверить, если виджет пропал без видимой причины после обновления темы или плагинов. Похожая история бывает и с CDN перед сайтом: если статические файлы раздаются через отдельный кеширующий слой, обновленный код виджета может не долетать до реальных посетителей еще несколько часов после того, как в личном кабинете сервиса все выглядит правильно.

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

Четвертая: нет маршрута передачи оператору. Бот, который зацикливается на «не понял вопрос» вместо того, чтобы признать это и передать диалог человеку, теряет клиента быстрее, чем кажется: по опросам Zendesk, большинство пользователей регулярно разочарованы чат-ботами, половине требуется слишком много попыток, прежде чем бот признает, что не справляется, а почти половине неприятно заново объяснять вопрос живому оператору с нуля. Хороший бот передает диалог вместе с историей переписки, а не голым уведомлением «клиент ждет, ответьте ему». По официальной документации Intercom, их ИИ-агент передает диалог человеку в трех типовых случаях: прямая просьба клиента о человеке, признаки сильного раздражения в тексте и зацикливание на одном и том же вопросе без прогресса, это разумный ориентир для настройки эскалации в любом сервисе, не только в Intercom.

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

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

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

Частые вопросы

Можно ли сделать чат-бота для сайта бесплатно?

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

Сколько времени уходит на запуск бота?

Конструктор: от 15–30 минут для простого приветственного бота до вечера для сценария с несколькими ветками. ИИ-платформа: 1–2 дня, основное время уходит на сбор и проверку базы знаний, а не на настройку самого виджета. Свой код: от полутора месяцев при заказной разработке, дольше при штатной команде без выделенного времени именно на этот проект.

Нужно ли уметь программировать?

Для путей 1 и 2 нет, оба собираются в интерфейсе без единой строчки кода. Для пути 3 да, или придется нанимать разработчика: без бэкенда, который вызывает API модели и обрабатывает базу знаний, бот не заработает вообще.

Чем ИИ-бот отличается от бота-конструктора?

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

Сколько стоит разработка чат-бота с нуля?

По независимым данным двух источников, Just AI и BotHelp, заказная разработка с нуля стоит от 227 000–294 000 ₽ и занимает от полутора месяцев. Это не единственный вариант получить кастомную логику: эксперт-фрилансер на конструкторе решает более простые задачи кастомизации за 20 000–60 000 ₽ и несколько дней, без полноценной разработки с нуля.

Что делает бот, если не находит ответ в своей базе знаний?

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

Какой путь выбрать для интернет-магазина?

Зависит от размера каталога. Для нескольких десятков позиций с типовыми вопросами про доставку и оплату обычно хватает конструктора с 5–7 сценариями. Для каталога из сотен и тысяч позиций, где вопросы касаются конкретных товаров, характеристик и наличия, вручную прописать сценарий на каждую позицию нереально, и здесь оправдана ИИ-платформа с базой знаний, собранной из карточек товаров и прайса. Свой код для рядового интернет-магазина имеет смысл только при глубокой интеграции с 1С или собственной CRM, которую ни один готовый сервис не поддерживает из коробки.

Можно ли собрать чат-бота в конструкторе, а потом перейти на ИИ-платформу?

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

Если коротко: выбор пути определяет задача, а не бюджет. Фиксированный сценарий, конструктор. Разнообразные вопросы по каталогу, ИИ-платформа с базой знаний. Нестандартная интеграция с внутренними системами при своей команде разработки, код. Комбинация путей по мере роста нагрузки, от быстрого MVP к более сложному решению, рабочая практика, а не компромисс.

Если хотите проверить путь с ИИ-платформой на своем сайте: Otvion ставится одной строкой кода, есть бесплатный тариф без карты, регистрация на otvion.ru/app/register.