Внедрение нейросети для обработки заявок: типовой сценарий

Внедрение нейросети для обработки заявок обычно начинается не с выбора модели, а с банального вопроса: сколько заявок в день теряется из-за того, что менеджер не успел ответить за первые 15 минут. За полтора года я собрал десяток похожих проектов - от Telegram-бота на aiogram, который сортирует заявки салона красоты, до RAG-бота с базой знаний для интернет-магазина на WooCommerce. Сценарий почти всегда один и тот же, меняются только детали: откуда приходят заявки, какая CRM на другом конце и сколько процентов диалога нужно закрывать без участия человека.

Зачем передавать заявки нейросети, а не сразу менеджеру

Большая часть входящих обращений - это повторяющиеся вопросы: цена, сроки, статус заказа, есть ли в наличии. По моим проектам такие обращения занимают 40-60% от общего потока, и именно на них теряется время менеджера, которое лучше потратить на сложные сделки. Вторая причина - время ответа. Клиент, который написал в 23:00, редко ждёт до утра: если конкурент ответил быстрее, заявка уходит туда. Нейросеть не заменяет менеджера полностью, но снимает рутину и сортирует входящий поток так, что человеку остаются только те заявки, где реально нужно принимать решение.

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

Из чего состоит типовой сценарий внедрения

Независимо от ниши, я прохожу одни и те же этапы:

• Сбор истории переписок и типовых сценариев - без этого промпт или база для RAG получаются оторванными от реальности
• Выбор модели и способа работы с контекстом: системный промпт, RAG на своих документах или дообучение (на практике почти всегда хватает первых двух)
• Классификация намерения - определяем, к какому типу относится заявка: вопрос, жалоба, заказ, статус доставки
• Маршрутизация - простые случаи закрывает нейросеть, сложные уходят в CRM с пометкой для менеджера
• Тестовый период с ручной проверкой ответов, обычно 1-2 недели на первых 200-300 диалогах
• Мониторинг и донастройка промпта по реальным логам

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

Какую нейросеть выбрать для обработки обращений

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

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

Как заявки попадают в систему: каналы и интеграции

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

Для форм на Tilda я обычно не пишу интеграцию с нуля - беру готовый вебхук-скрипт из библиотеки готовых скриптов и дорабатываю под конкретную CRM и формат данных. Экономит день-два на старте проекта.

Отдельно стоит сказать про вопросы, связанные с оплатой и доставкой - они требуют доступа к внешним сервисам, а не только к тексту. Если клиент спрашивает про статус заказа, нейросеть должна дёрнуть API СДЭК или платёжного шлюза (у меня почти на каждом втором проекте с оплатой это T‑Bank), а не придумывать ответ по шаблону. Такие интеграции я выделяю в отдельный блок работ, потому что там уже не текстовая генерация, а обычная разработка с обращением к внешнему API.

Что делает нейросеть, а что остаётся человеку

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

Пример из практики: заявки в Telegram с маршрутизацией через n8n

Один из недавних проектов - интернет-магазин с ботом на aiogram, который принимает вопросы по товарам и заказам. Логика такая: сообщение попадает в бота, бот передаёт текст в n8n через вебхук, там сценарий определяет тип запроса через Claude API и решает, что делать дальше - ответить из базы знаний (RAG по каталогу товаров) или создать карточку в amoCRM с пометкой для менеджера.

@dp.message()
async def handle_message(message: types.Message):
    payload = {
        "user_id": message.from_user.id,
        "text": message.text,
        "username": message.from_user.username,
    }
    async with aiohttp.ClientSession() as session:
        async with session.post(N8N_WEBHOOK_URL, json=payload) as resp:
            result = await resp.json()
    await message.answer(result["reply"])

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

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

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

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

Техподдержку после запуска - донастройку промпта по логам, добавление новых сценариев - веду отдельно, от 15 000 ₽ в месяц, в зависимости от объёма правок.

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

Сколько заявок в день нужно, чтобы внедрение окупилось?

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

Можно обойтись обычными триггерами в CRM без нейросети?

Для жёстко структурированных сценариев (например, «если заявка с формы, назначить менеджера А») триггеров хватает. Нейросеть нужна там, где вопрос сформулирован свободным текстом и нужно понять смысл, а не просто сработать по условию.

Обязательно ли обучать модель на своих данных?

Дообучение почти никогда не требуется. В 90% проектов хватает RAG - модель получает доступ к документам компании через векторный поиск и отвечает на их основе, без переобучения весов. Это быстрее, дешевле и проще обновлять при изменении цен или ассортимента.

Что происходит с заявками, которые нейросеть не смогла классифицировать?

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