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

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

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

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

Когда бот нужен, а когда нет

Честный разбор до начала работ экономит бюджет, поэтому начинаю с него.

Бот оправдан, если:

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

Бот не нужен, если:

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

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

Что я делаю

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

Сценарный и гибридный бот. Там, где ответ должен звучать дословно — цены, юридические формулировки, регламентированные сферы, — работает сценарий. Свободные вопросы обрабатывает модель. На практике почти все работающие боты устроены именно так.

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

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

Доработка существующего бота. Если бот есть, но отвечает мимо — разбор по цепочке «материалы → поиск → отбор → формулировка» и исправление того звена, которое действительно сломано.

Что входит в разработку

Разбор обращений и проверка применимости

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

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

Подготовка базы знаний

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

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

Требования к материалам — «Подготовка базы знаний для ИИ».

Логика ответов

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

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

Каналы

Виджет на сайте, Telegram, VK, MAX, WhatsApp, почта, внутренние системы. Логика и база знаний при этом общие, а канал — способ доставки.

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

Интеграции

Подключение к CRM, учётным и складским системам, расписанию — чтобы бот отвечал про конкретный заказ и наличие, а не только про общие условия. В интернет-магазинах именно эти сценарии дают основную часть эффекта.

Передача оператору

Не дополнение, а условие запуска. Бот, из которого нельзя выйти к человеку, при первом же непокрытом вопросе оставляет клиента в тупике — и впечатление портится о компании, а не о боте.

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

Тестирование и запуск

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

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

От чего зависит стоимость

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

Структура сметы — «Стоимость разработки чат-бота».

Чего я не делаю

• Не называю долю закрытых обращений до разбора ваших материалов. Достижимое качество — свойство ваших документов и однородности вопросов, а не мастерства исполнителя. Заявленные «90% обращений» почти всегда означают, что из расчёта убрали диалоги, ушедшие к оператору.
• Не запускаю бота без выхода на оператора. Ни один бот не покрывает всё, и часть клиентов принципиально хочет говорить с человеком.
• Не делаю бота там, где нет материалов. Сначала база знаний, потом бот. Иначе вы получите систему, которая уверенно выдумывает.
• Не считаю снижение доли передач оператору достижением. Её можно улучшить, затруднив выход к человеку, — это ухудшение, а не улучшение.
• Не выдаю настройку поиска за «обучение модели на ваших данных». Это разные вещи с разной стоимостью и разным поведением при обновлении документов.
• Не берусь, если расчёт не сходится. При малом потоке обращений бот не окупится, и об этом честнее сказать до проекта.

Форматы работы

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

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

Разработка под ключ. Полный цикл от разбора обращений до эксплуатации, с этапной оплатой и точкой выхода после пилота.

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

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