В большинстве B2B-компаний входящий поток — письма, формы, запросы из мессенджеров — обрабатывается вручную. Менеджер читает письмо, определяет тип запроса, ищет нужный шаблон коммерческого предложения, заполняет CRM-карточку. При росте объёма этот процесс масштабируется линейно: больше заявок — больше людей. ИИ меняет эту зависимость, но только при условии, что данные и интеграции подготовлены заранее.
Типичные симптомы проблемы:
- Заявки теряются или попадают не к тому менеджеру.
- Коммерческие предложения готовятся по-разному у разных сотрудников.
- CRM заполняется с задержкой или не заполняется вовсе.
- Нет единого журнала входящих обращений с историей действий.
Прежде чем выбирать подход к автоматизации, важно зафиксировать: что именно автоматизируется, какие данные уже есть и что нужно создать.
Границы ИИ: что он делает, а что остаётся за человеком
ИИ в процессе обработки заявок — это не замена менеджера. Это слой, который берёт на себя структурированные, повторяемые действия: классификацию, извлечение данных, черновики ответов, маршрутизацию. Принятие решений по нестандартным запросам, переговоры и финальное согласование коммерческого предложения остаются за человеком.
Что ИИ делает хорошо
- Классифицирует входящее письмо: тип запроса, срочность, тематика.
- Извлекает структурированные данные: название компании, контакт, продукт, сумма.
- Формирует черновик ответа или коммерческого предложения по шаблону.
- Создаёт или обновляет CRM-карточку автоматически.
- Маршрутизирует заявку на нужного менеджера по заданным правилам.
Что ИИ делает плохо без дополнительной подготовки
- Работает с неструктурированными, противоречивыми данными в CRM.
- Обрабатывает запросы на языках или в форматах, которых не было в обучающей выборке.
- Принимает решения, требующие коммерческого суждения или знания контекста клиента.
- Гарантирует корректность юридически значимых формулировок в КП.
Понимание этих границ — первый шаг к реалистичному техническому заданию на пилот.
Два подхода к реализации: сравнение архитектур
На практике компании выбирают между двумя основными вариантами построения ИИ-сервиса для обработки заявок.
| Параметр | Встроенный ИИ в CRM | Внешний ИИ-микросервис с интеграцией |
|---|---|---|
| Скорость запуска | Быстрее при наличии готового коннектора | Требует разработки интеграционного слоя |
| Гибкость логики | Ограничена возможностями платформы | Полный контроль над сценариями и моделями |
| Контроль данных | Данные передаются платформе | Данные остаются в контуре компании |
| Стоимость масштабирования | Зависит от тарифной модели платформы | Линейно зависит от объёма и инфраструктуры |
| Критерии приёмки | Сложнее проверить внутреннюю логику | Прозрачная трассировка каждого шага |
Для B2B-компаний с нестандартными процессами продаж, сложными шаблонами КП или требованиями к хранению данных внутри периметра — микросервисная архитектура с явными API-контрактами даёт больше контроля и предсказуемости на пилоте.
Что нужно подготовить до старта пилота
Пилот ИИ-сервиса для обработки заявок не начинается с кода. Он начинается с аудита данных и фиксации сценариев. Ниже — чеклист подготовки, который мы используем при проектировании таких решений.
Данные
- История входящих писем и заявок за последние 3–6 месяцев (минимум 200–500 примеров на каждый тип).
- Разметка: тип запроса, результат обработки, кто и как ответил.
- Шаблоны коммерческих предложений с переменными полями и правилами их заполнения.
- Справочники: продукты, прайс, менеджеры и правила маршрутизации.
Интеграции
- API CRM: создание и обновление сделок, контактов, компаний.
- Входящий канал: почта (IMAP/SMTP или webhook), формы на сайте, мессенджеры.
- Исходящий канал: отправка КП, уведомления менеджеру.
- Журнал событий: каждое действие ИИ должно логироваться с меткой времени и статусом.
Критерии приёмки пилота
- Точность классификации типа заявки — измеряется на тестовой выборке.
- Полнота извлечения полей — доля корректно заполненных CRM-карточек.
- Качество черновиков КП — оценивается менеджерами по шкале доработки.
- Время обработки заявки от получения до передачи менеджеру.
- Доля заявок, требующих ручной корректировки после ИИ.
Эти метрики фиксируются в техническом задании до начала разработки. Без них невозможно объективно оценить результат пилота.
Пошаговый план реализации ИИ-сервиса
Шаг 1. Аудит процесса и данных
Карта текущего процесса: откуда приходят заявки, кто и что делает с каждым типом. Оценка объёма и качества исторических данных. Выявление пробелов: каких данных не хватает для обучения или настройки модели.
Шаг 2. Проектирование сценариев и API-контрактов
Фиксация сценариев в виде явных правил: «если письмо содержит X, классифицировать как Y, создать карточку в CRM, отправить черновик КП шаблона Z». Проектирование API-контрактов между ИИ-сервисом и CRM. Определение fallback-логики: что происходит, если ИИ не уверен в классификации.
Шаг 3. Разработка и интеграция
Реализация ИИ-микросервиса: классификатор, экстрактор данных, генератор черновиков. Подключение к входящим каналам и CRM через API. Настройка журнала событий и алертов на аномалии.
Шаг 4. Тестирование на реальных данных
Прогон на исторической выборке с разметкой — оценка точности по зафиксированным метрикам. A/B-тест на живом потоке: часть заявок обрабатывает ИИ, часть — менеджеры, результаты сравниваются. Сбор обратной связи от менеджеров по качеству черновиков.
Шаг 5. Приёмка и решение о масштабировании
Сравнение достигнутых метрик с критериями приёмки. Фиксация открытых вопросов: какие типы заявок ИИ обрабатывает плохо и почему. Решение: расширять покрытие, дорабатывать модель или ограничить область применения.
Экономика пилота: как считать без обещаний
Оценку эффекта лучше строить через явную формулу, а не через проценты экономии. Пример условного расчёта (демонстрационный, не гарантированный):
Объём: 500 заявок/месяц
Среднее время обработки вручную: 15 минут
Итого: 125 часов/месяц
После пилота ИИ берёт на себя первичную обработку:
Время менеджера на проверку черновика: 3 минуты
Итого: 25 часов/месяц
Высвобождение: ~100 часов/месяц
Стоимость часа менеджера: подставьте свою цифруРеальные цифры зависят от объёма, сложности заявок и качества исходных данных. Расчёт имеет смысл делать после аудита, а не до него. Подробнее о том, как выбирать процессы для первого внедрения и оценивать экономику, — в статье ИИ для бизнеса: выбор процессов для первого внедрения и расчёт экономики.
Типичные риски и как их снизить
Риск: плохое качество данных
Исторические письма не размечены, шаблоны КП не унифицированы, CRM заполнена непоследовательно. Снижение: аудит данных до старта разработки, минимальный стандарт качества как условие входа в пилот.
Риск: неопределённые критерии приёмки
Без зафиксированных метрик невозможно объективно оценить результат. Снижение: критерии приёмки — обязательная часть технического задания, согласованная до начала разработки.
Риск: интеграционные сюрпризы
API CRM может не поддерживать нужные операции, или данные в CRM хранятся в нестандартном формате. Снижение: технический анализ API и структуры данных CRM на этапе проектирования. О том, как устроен пилот на реальных данных и где возникают типичные сложности, подробнее — в материале MVP ИИ-продукта: проверка спроса, границы функций и пилот на реальных данных.
Риск: сопротивление команды
Менеджеры воспринимают ИИ как угрозу, а не инструмент. Снижение: явная коммуникация о том, что ИИ готовит черновики, а финальное решение — за человеком. Включение менеджеров в оценку качества черновиков на этапе тестирования.
Масштабирование после пилота
Успешный пилот — это не автоматический переход к полной автоматизации. Это набор зафиксированных метрик, понятный список ограничений и решение о следующем шаге. Возможные направления после пилота:
- Расширение покрытия: подключение новых типов заявок или каналов.
- Улучшение модели: дообучение на накопленных данных с разметкой менеджеров.
- Углубление интеграции: автоматическое обновление CRM без участия менеджера для стандартных случаев.
- Подключение аналитики: мониторинг качества работы ИИ в продакшне с алертами на деградацию.
Каждый из этих шагов — отдельный проект с собственным техническим заданием и критериями приёмки.
Какой подход выбрать: чеклист для принятия решения
Перед тем как формулировать запрос на разработку, ответьте на следующие вопросы:
- Есть ли история входящих заявок объёмом от 200 примеров на тип?
- Зафиксированы ли шаблоны коммерческих предложений с явными переменными?
- Есть ли API у вашей CRM для создания и обновления карточек?
- Определены ли критерии, по которым вы будете принимать результат пилота?
- Готова ли команда тратить время на оценку черновиков ИИ в первые 4–6 недель?
Если на три и более вопроса ответ «нет» — начинать с разработки преждевременно. Сначала нужен аудит данных и процесса.
Как PORTcore реализует такие решения
Мы проектируем и разрабатываем ИИ-агентов и микросервисы для обработки входящих обращений, классификации заявок и подготовки черновиков коммерческих предложений. Работа строится поэтапно: аудит данных и процесса, проектирование API-контрактов, разработка и интеграция, тестирование на реальных данных, приёмка по зафиксированным метрикам.
Для задач классификации и маршрутизации входящих заявок подходит услуга AI-модерация входящих обращений. Если задача шире — подготовка черновиков КП, подсказки менеджеру и работа внутри CRM — это область разработки AI-агентов с интеграцией в ваши бизнес-процессы.
Если вы сейчас оцениваете, с чего начать, и хотите понять объём пилота под ваш процесс — обсудите задачу с командой PORTcore. Мы разберём ваш процесс, данные и интеграции, зафиксируем критерии приёмки и предложим конкретный план первого шага.
Требования к данным: что проверить до подписания ТЗ
Качество данных определяет потолок точности модели сильнее, чем выбор архитектуры. Перед стартом разработки проведите инвентаризацию по четырём осям:
- Объём. Для классификатора с тремя-пятью типами заявок нужно не менее 150–200 размеченных примеров на каждый класс. Если исторических данных меньше — сначала разметка, потом разработка.
- Полнота полей. Проверьте, насколько последовательно заполнены карточки в CRM: если поле «отрасль» заполнено в 30% сделок, экстрактор не сможет надёжно его извлекать и подставлять в КП.
- Унификация шаблонов. Если менеджеры используют разные версии КП без явных переменных-плейсхолдеров, генератор черновиков будет производить несогласованный вывод. Стандартизация шаблонов — предпроектная задача, не задача разработчика ИИ.
- Актуальность. Данные старше двух лет могут отражать устаревшую продуктовую линейку или ценовую политику. Используйте только те примеры, которые соответствуют текущему процессу.
Результат инвентаризации фиксируется в виде паспорта данных: источник, объём, период, доля заполненности ключевых полей, наличие разметки. Этот документ становится частью технического задания и определяет, нужен ли этап предобработки данных до разработки модели.
Интеграционные требования: что уточнить у вендора CRM
Интеграция ИИ-сервиса с CRM — не просто «подключить API». До начала разработки нужно получить ответы на конкретные технические вопросы:
- Поддерживает ли API создание сделки с кастомными полями за один запрос, или нужны последовательные вызовы?
- Есть ли webhook на входящее письмо, или потребуется polling по расписанию?
- Какой формат хранения вложений — ссылка на файл или base64 в теле ответа?
- Есть ли rate limit на API и каков он (запросов в минуту/в сутки)?
- Поддерживается ли идемпотентность при создании карточек — защита от дублей при повторном вызове?
Ответы на эти вопросы влияют на архитектуру очереди сообщений, логику retry-механизма и общую надёжность сервиса. Уточняйте их на этапе проектирования, а не после начала разработки.
Расширенные критерии приёмки: что добавить к базовому чеклисту
Базовые метрики точности и полноты — необходимый минимум. Но для принятия решения о масштабировании их недостаточно. Добавьте в критерии приёмки следующие проверки:
- Поведение на граничных случаях. Как ИИ обрабатывает письмо на двух языках? Заявку без контактных данных? Письмо с вложением нестандартного формата? Эти сценарии должны быть протестированы явно, а не обнаружены в продакшне.
- Стабильность под нагрузкой. Если в пятницу вечером приходит 50 заявок одновременно, сервис должен обработать их без потерь. Нагрузочный тест — часть приёмки, а не бонус.
- Корректность fallback. Проверьте, что при низкой уверенности классификатора заявка действительно уходит на ручную обработку, а не теряется и не создаётся дубль в CRM.
- Читаемость журнала событий. Менеджер должен за 30 секунд понять по логу, что ИИ сделал с конкретной заявкой и почему. Если журнал нечитаем — это дефект, а не особенность.
- Время восстановления после сбоя. Если CRM недоступна 10 минут, заявки должны накапливаться в очереди и обрабатываться после восстановления без потерь.
Роль человека в контуре: где граница не должна сдвигаться
Автоматизация обработки заявок не означает исключение человека из процесса. Есть сценарии, где участие менеджера обязательно — и эта граница должна быть зафиксирована в ТЗ, а не определяться по факту.
Когда ИИ не принимает решение самостоятельно
- Заявка на сумму выше порогового значения — менеджер получает черновик и подтверждает отправку вручную.
- Новый тип клиента, которого нет в обучающей выборке, — заявка маршрутизируется на ручную обработку с пометкой «неизвестный тип».
- Конфликт данных: клиент уже есть в CRM с другими реквизитами — ИИ создаёт задачу на проверку, не перезаписывает.
- Заявка содержит юридически значимые условия или нестандартные требования по SLA — только человек.
Что фиксируется в регламенте
Граница «ИИ делает — человек проверяет» должна быть описана в виде явного регламента: список типов заявок с уровнем автономии (полная автоматизация / черновик на утверждение / только маршрутизация). Этот регламент согласовывается с командой продаж до старта разработки и обновляется по итогам пилота.
Эксплуатационные затраты: что учесть после запуска
Стоимость пилота — это не вся стоимость владения решением. После запуска возникают регулярные затраты, которые нужно учитывать при оценке экономики:
- Инференс модели. Каждый вызов языковой модели для классификации или генерации черновика стоит денег. При объёме 500 заявок в месяц это предсказуемая статья; при росте до 5000 — пересчитывайте заранее.
- Разметка новых данных. По мере появления новых типов заявок или изменения продуктовой линейки модель нужно дообучать. Это требует времени менеджеров на разметку — обычно 2–4 часа в квартал при стабильном процессе.
- Мониторинг качества. Точность классификатора деградирует, если входящий поток меняется. Нужен регулярный контроль метрик — еженедельный дашборд или алерт на падение точности ниже порога.
- Обновление шаблонов КП. Если продуктовая линейка или ценовая политика меняется, шаблоны нужно актуализировать. Это операционная задача на стороне бизнеса, не разработчика.
- Поддержка интеграции. Обновления API CRM могут сломать интеграцию. Закладывайте бюджет на поддержку или договаривайтесь о SLA с командой разработки.
Совокупная стоимость владения считается как сумма затрат на инференс, разметку, мониторинг и поддержку интеграции — и сравнивается с высвобождённым временем менеджеров. Если эта формула не сходится при текущем объёме заявок, пилот имеет смысл отложить до роста потока.
Антипаттерны внедрения: что чаще всего идёт не так
Большинство неудачных пилотов повторяют одни и те же ошибки. Зная их заранее, можно избежать потери времени и бюджета.
- Начать с генерации КП, а не с классификации. Генерация текста — более сложная задача с субъективной оценкой качества. Классификация заявок даёт измеримый результат быстрее и создаёт фундамент для следующего шага.
- Автоматизировать исключения, а не правило. Если 80% заявок — стандартные запросы на один продукт, начинайте с них. Не пытайтесь сразу покрыть сложные случаи.
- Не зафиксировать baseline. Без замера текущего времени обработки и доли ошибок невозможно доказать эффект пилота. Измерьте baseline до запуска ИИ.
- Передать ИИ весь процесс без этапа «черновик на проверку». Даже при высокой точности первые недели работы в продакшне должны проходить в режиме human-in-the-loop. Это снижает риск и накапливает данные для дообучения.
- Не назначить ответственного за качество данных. Если никто не отвечает за актуальность шаблонов КП и полноту карточек в CRM, качество работы ИИ будет деградировать независимо от качества модели.
Связанные материалы
Подходящие офферы
Если статья попала в вашу задачу, вот два оффера, с которых можно перейти к внедрению без лишнего discovery.
Lead scoring в CRM
Настраиваем scoring-модель для входящих заявок, чтобы команда продаж работала с лучшими лидами в первую очередь.
Аудит аналитики и событий
Проверяем, можно ли доверять текущей аналитике и где именно теряются ключевые сигналы для маркетинга и продаж.
