В прошлом году к нам пришел собственник B2B-сервиса с запросом «нужен AI для продаж». После двух интервью стало ясно, что продажи тут ни при чем: менеджеры тратили 7-10 минут на каждую входящую заявку, вручную разбирали письмо и заполняли CRM через раз. Когда задача сформулировали именно так, пилот собрали за 5 недель, и бизнес сразу понял, за что платит.
Если вы сейчас смотрите в сторону AI, начинать лучше не с выбора модели. Сначала стоит найти операцию, которая повторяется каждый день, отнимает время и уже считается в рублях. Иначе получится еще один красивый пилот, который живет на демо, а не в процессе.
Проблема обычно не в модели
Самая частая ошибка простая: компания покупает идею «нам нужен AI», но не может назвать один процесс, который должен стать быстрее или дешевле. Рабочая постановка всегда уже и прозаичнее: сократить обработку лида с 7 минут до 2 минут, снизить нагрузку на первую линию на 30%, убрать ручную подготовку КП.
Мы сами когда-то заходили в такие проекты от технологии. Делали аккуратное демо, подключали интерфейс, показывали сценарий. Потом внедрение вставало не из-за качества модели, а потому что у процесса не было владельца, метрик и нормальных данных. Это была наша ошибка, и она быстро ставит все на место.
Если CRM заполняется через раз, а регламенты лежат в почте, Notion и старых PDF, модель просто быстрее воспроизведет ваши системные ошибки. Здесь не помогает даже хороший промпт.
Первый кейс должен иметь границы: одна роль, один тип данных, один измеримый результат.
Где деньги видны быстрее
Быстрее всего окупаются повторяемые операции, где много текста и есть простая проверка человеком. Обычно мы смотрим на поддержку, входящие лиды, документы, поиск по базе знаний и суммаризацию звонков.
На старте хорошо работают такие сценарии:
- первая линия поддержки - снижение нагрузки на операторов на 20-40%
- обработка лидов - реакция быстрее в 2-3 раза
- КП и шаблонные документы - вместо 45 минут уходит 10-15 минут
- встречи и звонки - экономия 10-20 минут после каждого разговора
У клиента из логистики менеджер читал письмо, вытаскивал контакты, создавал карточку в Bitrix24 и писал первый ответ. Мы собрали ассистента на Laravel 11, PostgreSQL 16 и внешнем LLM API: он забирал данные из почты, классифицировал заявку, заполнял поля и предлагал следующий шаг. Вместо 8 минут на заявку стало 2-3 минуты с проверкой человеком, а заполненность CRM выросла на 34%.
Лучше всего работает понятный сценарий, который можно измерить через неделю. Универсальный помощник почти всегда расползается по ролям, правам доступа и исключениям.
Что выбирать на старте
Если системе нужно помогать сотруднику, я почти всегда начинаю с AI-ассистента. Он ищет ответ, готовит черновик, поднимает нужный регламент, но последнее действие оставляет человеку. Для малого и среднего бизнеса это самый спокойный вход.
AI-агент нужен позже, когда система уже должна идти в CRM, менять статус, создавать задачу или отправлять ответ. Здесь цена ошибки выше, потому что ошибка сразу превращается в действие.
| Формат | Запуск | Риск | Где уместен |
|---|---|---|---|
| AI-ассистент | 2-4 недели | низкий | поддержка, продажи, документы |
| AI-агент | 4-8 недель | средний | цепочки действий в CRM |
| API-only | 1-3 недели | низкий | точечный сценарий внутри текущей системы |
| self-hosted | 8+ недель | высокий | жесткие требования к данным |
Во многих случаях свой AI-продукт вообще не нужен. Хватает внешнего API, CRM, базы знаний и слоя автоматизации на n8n или Make.
POST /v1/responses
# вход: текст заявки + данные из CRM
# выход: квалификация лида + черновик ответа + следующий шаг
Риск надо проектировать заранее
Формула отбора простая: ошибка AI не должна быть критичной, а человек должен быстро ее проверить. Если система предлагает черновик ответа, подсказывает категорию обращения или заполняет поля в CRM, риск управляемый. Если она сама меняет цены, статусы оплат или отправляет юридически значимые документы, я бы здесь притормозил.
Нужна ли дорогая платформа сразу?
Обычно нет. Для первого пилота хватает внешнего API, вашей CRM и логов, по которым видно, где модель ошибается.
Когда можно убирать человека из цикла?
Когда у вас появляется стабильность на реальных данных, а не на тестовых вопросах. До этого автономность лучше ограничивать ролями и типами действий.
У нас был внутренний бот для сервисной компании. На тестах точность была 58%, хотя модель взяли сильную. Мы не меняли провайдера: сначала собрали регламенты в одну базу, убрали дубли, настроили права и журнал ответов. После этого получили 84% на том же наборе вопросов.
Что считать нормальным результатом
Через 30 дней у вас должен быть рабочий пилот на одном сценарии и базовые метрики. Через 90 дней уже видно, где есть ROI, а где сам процесс нужно чинить отдельно. К этому сроку бизнесу нужен уже не «умный ответ», а стабильное поведение системы.
Ниже типичная картина после первого запуска:
- было: ручная обработка заявки 7-10 минут, CRM заполняется выборочно, ответ зависит от конкретного менеджера
- стало: проверка черновика 2-3 минуты, обязательные поля заполняются автоматически, первый ответ уходит по шаблону
- эффект: время первого ответа -35%, средняя обработка -20%, типовые обращения закрываются без участия старшего сотрудника
Тот собственник, который в начале просил «AI для продаж», в итоге купил себе не магию и не стратегию. Он вернул 5-6 часов менеджерского времени в день. Обычно с этого и начинается нормальное внедрение: не с разговора про модель, а с одного узкого места, которое давно раздражало всю команду.
