ИИ-агент для обработки заявок и подготовки КП: кейс B2B-дистрибьютора

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

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

Сразу оговорюсь, кто это пишет. Я не разработчик по профессии — я директор по маркетингу и веду коммерческий блок целиком: реклама, воронка, отчётность собственнику. Такие штуки собираю под свои и клиентские задачи, поэтому дальше будет много про деньги и учёт и мало про технологии.

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

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

Что было до внедрения: как готовили коммерческие предложения руками

У любого B2B-дистрибьютора со сложной номенклатурой это выглядит одинаково:

• Прайсы приходят PDF и Excel от разных производителей, в разных валютах, с разными датами действия. Актуальный лежит рядом с прошлогодним, и какой из них свежий — знает только тот, кто его скачивал.
• Часть заявок приходит на позиции, которых в прайсах нет вообще: другой бренд, снятая с производства модель, запрос «подберите аналог».
• Цена считается через Excel-калькулятор с курсом, логистикой и наценкой. В файле, который мне передали, в двух строках прайса стояли #VALUE! — формулы были сломаны и никто этого не замечал.
• Одна и та же заявка прилетает нескольким менеджерам сразу. Клиент рассылает её как внутренний тендер разным дилерам, и весь офис параллельно ищет одни и те же насосы.

Последний пункт в постановку задачи не входил. Он всплыл позже.

Как работает ИИ-агент: контур обработки заявки из шести шагов

Заявка приходит двумя путями: письмом на корпоративный ящик или сообщением менеджера в Telegram. Ни CRM, ни учётная система в контур не заходят — агент живёт поверх почты и мессенджера и отдаёт результат человеку. Дальше — один и тот же контур. Главное здесь не шаги, а кто делает каждый из них: модель, детерминированный код или человек.

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

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

Что у агента в памяти: база знаний по прайсам и каталогам

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

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

Этапы внедрения: что вскрылось по дороге

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

• Этап 1 · аудит материалов Разбор того, что уже есть: прайсы, каталоги, калькулятор цен, примеры реальных заявок. Здесь же вылез истёкший сертификат в комплекте документов. Всё это до первой строки кода.
• Этап 2 · вертикальный срез Не «весь функционал на 30%», а один сквозной путь целиком: заявка → поиск → расчёт → черновик КП. Синтетические заявки, чтобы не гонять чужие персональные данные до согласования. Первый прогон показал главное — реальный поток заявок идёт по брендам, которых в переданных прайсах нет вообще.
• Этап 5 · боевое тестирование Сначала двое: собственник и коммерческий директор. Массово менеджерам не отдавали сознательно — «засыпят вопросами», а формат ещё менялся. Потом по одному добавились остальные. Дефекты, из-за которых пришлось переделывать логику, нашлись все здесь — на живых заявках.

Находка, которой не было в задаче: дедупликация

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

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

Важно, что это предупреждение, а не блокировка. Решает человек: бывает, что вести обе заявки правильно.

На созвоне эту функцию не пришлось объяснять: коммерческий директор сам открыл её на своём примере — увидел флаг дубликата, узнал заявку, которую уже отработал, и на этом обсуждение закончилось. Функция, которой не было в изначальном ТЗ, оказалась первой, которую заметили и оценили.

Поэтому я и начинаю не с агента, а с того, где у вас дублируется и горит время. Пять рабочих дней, карта задач с оценкой в часах и рублях — 45 000 ₽, и эта сумма вычитается из стоимости внедрения, если решите продолжить. Как устроена диагностика →

Ошибки внедрения: что видел пользователь и что было на самом деле

Самая полезная часть кейса. Всё ниже — реальные дефекты. Сначала сводка, дальше разбор.

Ни одна из четырёх строк не про то, что модель чего-то не поняла. Это семантика данных, разметка чужого сайта, учётная логика и особенности Word. Так и распределяется работа в реальном внедрении: на ИИ приходится сильно меньше, чем ждёшь вначале.

1. Цены были завышены на 78%

К прайсу применялись коэффициенты импорта — логистика и наценка, — хотя этот прайс уже был отпускным. Коэффициенты нужны только тогда, когда цена получена от поставщика как закупочная. Менеджер видел насос за 628 тысяч там, где правильная цена была 353 тысячи.

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

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

Разница в одном КП — 275 тысяч рублей. Это и есть цена ошибки в цене: не «неточность», а сумма, которую менеджер отправляет клиенту как обязательство. Поэтому цену считает код, а не модель.

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

2. Характеристики соседнего товара в бланке

В одном из КП напечаталось «напор 2 м» для насоса, у которого напор около 17 метров. Три причины наложились друг на друга, но главная такая: на сайте подбора производителя карточка описывает серию, а не конкретный артикул. «Максимальный расход» и «максимальный напор» — это границы всего модельного ряда, а не параметры позиции.

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

Что сделал: диапазоны серии больше не попадают в характеристики позиции, они лежат отдельно как справка. В бланк идёт только подтверждённое: наименование из прайса, база знаний, расшифровка маркировки. Кэш пришлось очистить целиком — в нём уже осели отравленные значения.

3. Номера предложений тратились на консультации

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

Теперь номер выдаётся, только когда известен клиент — организация или контактное лицо. Иначе консультация идёт без номера, и в чек-листе стоит напоминание. Испорченные номера не удалил, а пометил отменёнными: в учёте дырки лучше объяснять, чем прятать.

4. Расшифровка маркировки, где система намеренно молчит

У насосов буквенный код исполнения: материал уплотнения, тип фланца, вариант проточной части. Заказчик хотел, чтобы агент расшифровывал его в КП.

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

Поэтому расшифровка позиционная и берётся только из каталогов производителя. Система отказывается отвечать в трёх случаях. Код слитный, и позиции не разделить. Сошлись не все группы кода. У серии в каталоге вообще нет раздела обозначений. Буквенный код есть примерно у одиннадцати тысяч позиций основного бренда. Полностью разбирается около тысячи, ещё по нескольким тысячам выдаётся справка по группам кода для ручной сверки. Остальное система честно не берётся разбирать.

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

5. Документ, который клиент открывает у себя

КП живёт не у нас, а в чужом Word и чужом принтере. Эти грабли выглядят мелочью до первого письма от менеджера.

• Word игнорирует CSS-ширины картинок. Редактируемая версия КП открывалась на десять страниц с логотипом во весь лист. Word и конвертеры берут натуральный размер файла — помогает только HTML-атрибут width. Ещё Word не понимает ни grid, ни flex, поэтому вёрстку пришлось переложить на таблицы. Стало две страницы.
• Генератор PDF плохо кладёт CSS Grid. Круглые значки растягивались в овалы, подписи разъезжались. В печатных стилях эти места переведены на flex, в вебе grid остался.

Ни одна из этих правок не улучшает подбор насоса. Но именно по ним менеджер судит, можно ли отдавать документ клиенту.

Результаты внедрения в цифрах

• 18 089 позиций в базе знаний из 205 документов-источников, из них более 17 тысяч с ценой. На старте по основному бренду было ноль попаданий — прайс нашёлся не в присланных файлах, а на сайте самого заказчика, в CSV рядом со страницей.
• 184 каталога производителя скачаны и переведены в машиночитаемый вид локально, без затрат на модель.
• 57 автотестов в четырёх файлах.
• 4 человека на стороне заказчика: собственник, коммерческий директор и двое менеджеров.
• Два канала входа — почта и Telegram — поверх одного ядра. Веб-интерфейс обсуждали и отложили: дорого не сверстать страницу, а безопасно состыковать её с сервером и агентом.

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

Чего я не напишу, потому что это не измерено: на сколько сократилось время обработки заявки. Замера до внедрения никто не делал, а сравнивать ощущения с ощущениями — это не цифра. Если бы я начинал проект заново, первым делом попросил бы неделю хронометража.

Что бы я сделал иначе в следующем внедрении

1. Сначала семантика данных, потом код. История с 78% — это не баг реализации, а непроверенное допущение о том, что означает число в чужом файле. Полдня разговора с заказчиком в начале сэкономили бы неделю в конце.
2. Замер «до» — до первой строки кода. Неделя хронометража стоит ничего, а без неё вы не докажете эффект, даже когда он есть. Я этого не сделал и теперь не могу назвать ни одной цифры про экономию времени.
3. Боевые пользователи раньше. Ни один серьёзный дефект не нашёл тест. Все нашли люди, которым нужно было отправить документ клиенту. Синтетика ловит ошибки кода, а не ошибки понимания предметной области.
4. Отдельно проговорить, что система будет молчать. Отказ отвечать выглядит как недоработка, если о нём не договориться заранее. Если проговорить — становится главной причиной доверия.

Почему 95% пилотов не доходят до продакшна

Цифру знают все: по исследованию MIT NANDA «The GenAI Divide» (2025, 300 публично раскрытых внедрений, 52 интервью, опрос 153 руководителей) около 95% пилотов на генеративном ИИ не дают измеримого эффекта на прибыль. Пересказывают её обычно грубее — «ИИ не окупается», — и делают вывод про технологию. Вывод неверный.

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

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

Кому имеет смысл внедрять ИИ-агента для обработки заявок

Похоже на вашу задачу, если:

• Номенклатура сложная, прайсов несколько, лежат в PDF и Excel от разных поставщиков.
• Одно коммерческое предложение готовится долго, и это делают руками несколько человек.
• Ошибка в цене или характеристике стоит дорого — она уходит клиенту как обещание.
• Есть подозрение, что часть работы дублируется между сотрудниками.
• Заявки идут в почту и мессенджеры, а не через форму на сайте, — поэтому автоматизация отдела продаж на уровне CRM их не ловит.

А не похоже — если процесс не описан и никто не может сказать, как считается цена, то автоматизировать пока нечего. Сначала разбор процесса, потом инструменты. Внедрения, которые я видел в обратном порядке, кончались красивым демо и брошенным сервисом.

Что нужно с вашей стороны

Прайсы и каталоги в том виде, в каком они есть — PDF, Excel, что угодно. Один человек, который знает, как у вас считается цена, на несколько разговоров: история с 78% выросла ровно из непроверенного допущения на этом месте. И двое-трое, кто будет гонять через агента реальные заявки — все содержательные дефекты нашли именно они, тесты такое не ловят. Остальное на мне.

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

Может ли ИИ-агент сам называть цену клиенту?

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

Нужна ли интеграция с CRM или 1С?

В этом проекте не понадобилась. Агент живёт поверх корпоративной почты и Telegram, а результат отдаёт менеджеру. Личного кабинета не делали: дорого не сверстать страницу, а безопасно состыковать её с сервером и агентом.

Что делать, если прайсы лежат в PDF и Excel от разных поставщиков?

Это норма для дистрибьютора и не блокер. Прайсы переводятся в машиночитаемый вид, у каждой позиции хранится источник: документ, страница, дата и версия. Сложность не в конвертации, а в семантике чисел: закупочная это цена или отпускная — определяет всю дальнейшую арифметику. Непроверенное допущение здесь стоило завышения на 78%.

---

Поэтому похожие задачи я и беру именно в таком порядке: сначала разбираю процессы и отдаю карту задач с оценкой в часах и рублях, потом пилот на одном процессе. Цены и порядок работы — на странице внедрение ИИ-агентов и автоматизация продаж. Написать можно в Telegram @Masternobi — достаточно пары строк про процесс, который отнимает больше всего времени.

Если нужно не сделать, а научить команду — есть корпоративный интенсив. Ещё про продукты и маркетинг — в канале @kopirajchu.