Не подписка на платформу, а бот под ваш процесс: ваши воронки, ваши поля, ваши правила передачи клиента менеджеру. Собираю на amoCRM, Kommo и Bitrix24 в связке с n8n и языковыми моделями.
Бот нужен не всем и не всегда. Ниже ситуации, где он окупается быстро. Если ничего из этого не про вас, честнее сказать сразу.
Отвечает на типовые вопросы про цены, условия, сроки и наличие. Держит диалог круглосуточно и передаёт менеджеру, когда вопрос выходит за рамки.
Понимает намерение клиента, задаёт уточняющие вопросы, заполняет поля сделки и ставит приоритет. Менеджер получает не «новый лид», а готовый контекст.
Проверяет свободные даты в вашей системе, подбирает вариант, оформляет бронь и напоминает о ней. Работает с реальными остатками, а не с табличкой.
Не пишет клиенту сам, а готовит менеджеру черновик ответа с учётом истории сделки. Отправляет всё равно человек, одним нажатием.
Работает не с клиентом, а с вашими процессами: следит за сделками, ставит задачи, собирает сводки, замечает застрявшее. Несколько агентов под разные роли.
На практике чистый тип встречается редко. Бот первой линии почти всегда заодно квалифицирует, а бронирование тянет за собой напоминания и оплату.
Языковая модель не хранит ваши данные и не управляет процессом. Она формулирует ответ, а маршрут, статусы и история живут в CRM, где их видно и можно проверить.
Telegram, WhatsApp, сайт, соцсети. Сообщение попадает в CRM на нужный контакт.
Хранит клиента, сделку и историю. Здесь же видно, что именно сделал бот.
Шина: собирает контекст, ходит во внешние системы, пишет результат обратно.
Определяет намерение и формулирует ответ. Только смысл, без доступа к управлению.
Отвечает только по вашим материалам и данным из систем. На вопрос за пределами базы не выдумывает, а зовёт человека. Это настраивается жёстко, а не просьбой в промпте.
Негатив, жалоба, нестандартный запрос, сомнение модели, прямая просьба позвать менеджера. По каждому триггеру диалог уходит человеку с полным контекстом.
Тип запроса, приоритет, отметка «нужен менеджер» пишутся в поля сделки. По ним потом строится отчёт: сколько бот закрыл сам и где он ошибался.
Пустой ответ, оборванный диалог, два сообщения подряд, клиент передумал, канал отвалился. Ломается всё именно здесь, а не в счастливом сценарии.
Готовых платформ с ботами на рынке много, и часть задач они закрывают дешевле, чем я. Скажу честно, где именно.
Самый частый страх при разговоре про ботов звучит так: «а если он напишет клиенту глупость». Страх обоснованный, и решается он не обещаниями, а архитектурой.
Степень самостоятельности бота это настройка, а не данность. На одном полюсе он отвечает клиенту сам и зовёт человека по триггерам. На другом вообще ничего не отправляет, а готовит менеджеру черновик, и тот решает.
Выбор зависит от цены ошибки. Для вопроса о времени заезда автономность уместна. Для переговоров на несколько миллионов лучше черновик, который человек прочитает за десять секунд.
Бронирование, FAQ, напоминания о заезде, оплата.
Длинный цикл, консультации, прогрев, повторные продажи.
Разбор откликов на рассылки по большой базе.
Порталы в мессенджере, профтесты, промо-механики.
Маршрутизация лидов из рекламы и мессенджеров.
Запись, абонементы, напоминания, реанимация базы.
Квалификация заявок, подготовка ответа менеджеру.
Процесс важнее отрасли. Разберём на брифе.
Разбираем процесс, а не техзадание
Смотрим, как реально приходят заявки и где теряются. Часто выясняется, что половину проблемы закрывает не бот, а настройка CRM. Об этом говорю сразу.
Определяем границы и уровень самостоятельности
Что бот делает сам, что только предлагает, где обязательно зовёт человека. Это решается до кода, потому что от этого зависит вся архитектура.
Собираем MVP на реальных данных
Один основной сценарий целиком, от сообщения клиента до записи в CRM. Лучше проверить гипотезу на узком куске, чем полгода строить всё сразу.
Гоняем на пограничных случаях
Проверяем не то, что бот красиво отвечает, а то, как он ведёт себя при обрывах, странных вопросах и отвалившихся интеграциях.
Выкатываем и смотрим на живых диалогах
Первое время читаем, что бот отвечает реальным людям, и правим формулировки и правила эскалации. Без этого этапа не обходится ни один проект.
Оповещения об ошибках и поддержка
Настраиваю уведомления о сбоях, чтобы поломка не всплыла через неделю от клиента. Дальше по необходимости, в формате сопровождения.
Цена зависит от числа сценариев и от того, в какие системы бот должен ходить. Бот, который отвечает по базе знаний, и бот, который проверяет остатки в PMS и принимает оплату, отличаются в разы.
Поэтому считаю после разбора задачи, а не по прайсу. Разбор и оценка бесплатны: заполняете бриф, я смотрю и говорю вилку по срокам и деньгам. Если задача решается без меня, скажу и это.
Обычный бот идёт по заранее нарисованной схеме: кнопка, ответ, следующая кнопка. Шаг в сторону, и он теряется. ИИ-агент понимает формулировку своими словами, сам решает, какой информации не хватает, и может обратиться к внешним системам за данными. На практике почти всегда получается гибрид: сценарий отвечает за маршрут и надёжность, модель за понимание и формулировку.
Это решается уровнем самостоятельности. Бот отвечает только по вашим материалам и данным из систем, а на вопрос за пределами базы зовёт человека вместо того, чтобы придумывать. Если цена ошибки высокая, ставим режим черновика: бот готовит текст, а отправляет менеджер одним нажатием. Тогда клиенту физически не может уйти неодобренное сообщение.
Нет. Бот встраивается в то, что уже работает: amoCRM, Kommo, Bitrix24. Иногда по ходу выясняется, что воронки или поля стоит поправить, но это доработка, а не переезд. Смена CRM ради бота почти никогда не окупается.
Зависит от количества сценариев и от того, готовы ли доступы и материалы. Быстрее всего идут проекты, где есть один понятный сценарий и живой человек на стороне заказчика, который отвечает на вопросы. Дольше всего тянутся те, где ждём доступы к системам. Конкретную вилку называю после разбора задачи.
Архитектура строится так, чтобы модель можно было заменить. Логика, сценарии и интеграции живут отдельно от конкретного поставщика, поэтому переход с одной модели на другую это настройка, а не переписывание проекта. Решение остаётся вашим и не привязано к чужой подписке.
Так и рекомендую. Берём один сценарий, который приносит больше всего боли, доводим до рабочего состояния и смотрим на реальных диалогах. Дальше уже понятно, что расширять, а что оказалось не нужно. Это дешевле и честнее, чем проектировать сразу всё.
Посмотрю процесс и скажу, нужен ли здесь бот, каким он должен быть и сколько это стоит. Если задача решается проще, скажу прямо.