Сократили подготовку КП с 2 часов до 12 минут

О клиенте

Производитель и поставщик промышленного оборудования с выручкой 1.8 млрд ₽ в год. 40 менеджеров продаж работают с заводами, машиностроительными предприятиями и подрядчиками ВПК. Средний чек сделки — 2–8 млн ₽, цикл продажи — 2–4 месяца. Каталог состоит из 12 000 SKU с десятками технических характеристик у каждой позиции.

Это типичный B2B со сложным продуктом и длинным циклом продаж — таких компаний в России несколько сотен, и проблемы у них одинаковые.

Проблема

Симптомы: что видел менеджер каждый день

Заявка приходила в свободной форме — например, «нужны фланцы и клапаны для пара 40 атм, температура до 250 °C, объём 20 единиц, срок — две недели». Дальше начиналась рутина:

• 30+ минут на поиск подходящих позиций. Каталог жил в виде 14 PDF-файлов и таблиц 1С. Искали через Ctrl+F и пролистывание.
• 2 часа на сборку коммерческого предложения. Шаблон в Word, ручное копирование цен, технических характеристик и условий оплаты. Половина шаблонов уже устарела — но все ими пользовались, потому что новые никто не успевал актуализировать.
• Полная потеря контекста при смене менеджера. История общения оставалась в личной почте, в Telegram и в голове. Новый менеджер начинал с клиентом с нуля — даже если тот покупал у компании пять лет.

В деньгах: сколько это стоило

Из 40 рабочих часов в неделю менеджер тратил 14 часов на рутину — это 35% времени отдела на работу, которая не приносит выручки. На фонд оплаты труда 12 млн ₽/мес это ≈4.2 млн ₽ операционных потерь ежемесячно.

К прямым потерям прибавлялись упущенные сделки: пока менеджер собирал КП два часа, клиент успевал получить ответ от более быстрого конкурента. По оценке руководителя отдела продаж — теряли каждую шестую сделку, попадавшую в воронку.

Почему готовые решения не подошли

Перед тем как заказать кастомную разработку, клиент попробовал три более простых пути.

ChatGPT в браузере. Менеджеры им не пользовались. Надо логиниться, копировать данные из каталога, ответ нельзя положить в карточку клиента. Через две недели после внедрения отказались — нагрузка на менеджера выросла, а не упала.

Готовые расширения для amoCRM с ИИ. Отвечают общими фразами без знания конкретного каталога. Бесполезны там, где важен точный SKU и совместимость характеристик.

YandexGPT API и GigaChat напрямую. Упёрлись в безопасность. Часть документации содержит технические данные оборудования для оборонных предприятий — отправлять их во внешний API запрещено по NDA с заказчиками клиента.

К моменту обращения к нам у клиента было чёткое понимание: нужна локальная LLM на собственной инфраструктуре, плотно интегрированная в текущие инструменты менеджеров — Telegram и amoCRM.

Подход

Discovery: первые две недели

Поговорили с шестью менеджерами разной выслуги, с РОПом, с двумя клиентами и с IT-директором. Записали реальные диалоги: как заявка превращается в КП. Выяснили три ключевых вещи:

1. Менеджер тратит больше всего времени не на сам поиск, а на проверку технической совместимости (фланец под клапан, давление под температуру).
2. Половина шаблонов КП устарела — никто из менеджеров не знал, что есть актуальные.
3. amoCRM была заброшена: 60% карточек заполнялось формально, потому что «всё равно никто не читает».

Это сильно изменило фокус — оказалось, что нужен не «чат-бот», а встроенный помощник по всему циклу сделки.

Ключевые архитектурные решения

Локальная LLM, не внешний API. Документация клиента содержит спецификации для оборонных предприятий — отправлять её в OpenAI/Yandex недопустимо по NDA. Развернули Saiga-Mistral 7B, fine-tuned на корпусе клиента, на собственном GPU-сервере (одна A100 40GB). С гибридным фолбэком: общие запросы (этикет, общие термины) маршрутизируются на GigaChat, чтобы не нагружать локальную модель и сэкономить на ресурсах.

RAG поверх Qdrant, а не fine-tuning основной модели. Каталог обновляется еженедельно — если бы мы fine-tune модели, пришлось бы переобучать каждый раз. RAG — простая переиндексация ночью. Векторизуем PDF, таблицы 1С и историю переписок (BAAI/bge-m3 эмбеддинги, 1024-размерный вектор).

Telegram + расширение amoCRM, не отдельное приложение. Менеджеры уже живут в Telegram. Мобильное приложение поставило бы стену между ними и инструментом. Бот в Telegram + iframe-расширение в карточке amoCRM — две точки входа, единый бэкенд.

Решение в деталях

Поиск по каталогу

12 000 SKU разбили на семантические чанки: каждая позиция = одна запись в Qdrant с эмбеддингом названия + ключевых характеристик + области применения. На каждый запрос ассистент:

1. Делает векторный поиск top-50 кандидатов.
2. Применяет фильтры по жёстким параметрам (давление, температура, диаметр) — экстрагированным из запроса с помощью function calling.
3. Прогоняет результат через re-ranker (BAAI/bge-reranker-v2) для улучшения релевантности.
4. Возвращает top-5 со ссылками на источник в PDF-каталоге и страницей в 1С.

Ключевая фича: ассистент всегда показывает источник цитаты — это снимает у менеджера тревогу «а вдруг модель выдумала».

Генерация коммерческих предложений

КП собирается за 30 секунд по описанию задачи клиента. Архитектура:

• Менеджер пишет в Telegram: «КП для ОАО „Прогресс“ на 20 фланцев, клапаны, поставка через ИП „Иванов“, 14 дней».
• Ассистент извлекает структуру: получатель, позиции, контрагент, срок.
• Подставляет актуальные цены из 1С (через REST), технические характеристики из RAG, условия оплаты из админ-панели.
• Генерирует DOCX по шаблону с помощью python-docx. Шаблоны актуализирует РОП в админке — менеджеры всегда работают с последней версией.
• Файл приходит менеджеру в Telegram и автоматически прикрепляется к карточке amoCRM.

Суммаризация переписок и follow-up

Каждый день в 8:00 ассистент прогоняет:

• Письма из почты (подключили IMAP).
• Сообщения из Telegram-чатов с клиентами (через user-аккаунт менеджеров).
• Записи звонков из IP-телефонии (Mango Office, через webhook).

На каждый активный аккаунт делает дайджест: что обсуждали, что обещали, какой следующий шаг. Дайджест приходит менеджеру в Telegram до начала рабочего дня. Если по карточке нет действий 24 часа после обещанного follow-up — ассистент сам пишет менеджеру: «Иванов ждал КП до сегодня — что делаем?»

Интеграция с amoCRM

Не «ещё одна вкладка», а встраивание в существующий процесс:

• Webhook от amoCRM на изменение этапа → ассистент проверяет, собран ли нужный артефакт (КП, договор, отгрузочные).
• При появлении нового лида — ассистент сам запрашивает у менеджера: «По заявке от Х нужно ли подготовить предварительное КП?»
• В карточку автоматически пишется: суммаризация переписок, ссылки на сгенерированные КП, дата следующего follow-up.

Это решило проблему «60% карточек заполнено формально» — данные стали наполняться сами собой.

Админ-панель и наблюдаемость

Отдельный кабинет для РОПа, где видно:

• Сколько запросов сделал каждый менеджер.
• Какие SKU чаще всего ищут (помогает планировать остатки на складе).
• Какие запросы ассистент не смог обработать (для дообучения).
• Время отклика, ошибки, нагрузка на GPU.

Метрики наружу — Grafana, логи — структурированные через structlog, ошибки — Sentry.

Самое сложное

Совместимость технических характеристик

Проблема. RAG возвращал релевантные позиции, но не учитывал техническую совместимость — например, фланец на 50 атм + клапан на 25 атм = плохо. Менеджеры теряли доверие после 2–3 неверных рекомендаций.

Что попробовали. Сначала добавили правила совместимости в системный промпт. Не сработало: модель забывала их при длинных запросах.

Что сделали. Валидационный слой после генерации — чистый Python-код с правилами совместимости, выгруженными из техпаспортов. Если модель предлагает несовместимую пару, ассистент сам пишет: «Внимание: клапан рассчитан на 25 атм, но в запросе 40 — нужен другой клапан. Вот альтернативы». После этого изменения количество жалоб от менеджеров упало до нуля.

Длинная техническая документация в RAG

Проблема. PDF-каталоги по 200–400 страниц — содержат таблицы, схемы, сноски. Стандартный chunking (по 512 токенов) ломал контекст: половина характеристик отрывалась от названия позиции.

Что сделали. Написали парсер на базе pdfplumber + unstructured.io, который выделяет таблицы как единый чанк, а текстовые описания склеивает с заголовками раздела. Каждый чанк в Qdrant получает метаданные: страница, тип (таблица/текст/схема), родительский раздел. Это улучшило recall на тестовом наборе из 200 типовых запросов с 71% до 94%.

Работа в условиях NDA с заказчиками ВПК

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

Что сделали. Двухконтурная архитектура: для запросов с публичными данными — внешний контур (GigaChat, кеширование в Yandex Cloud). Для запросов с грифованными данными — отдельный контур на on-premise GPU-сервере без выхода в интернет, доступ только через VPN. Маршрутизация запросов — по тегам в Qdrant и категории клиента в amoCRM. Заняло на discovery около недели — отдельно от основной разработки.

Результаты

Цифры через 90 дней после полного запуска

−92% время поиска информации. С 30 минут до 2 минут на одну позицию. На отдел из 40 человек это 280 часов в неделю — то есть 7 человек, освобождённых под коммуникации с клиентами вместо рутины.

−84% время на КП. С 2 часов до 12 минут. Менеджер успевает отправить КП в день обращения — раньше это занимало 1–2 рабочих дня.

+14 п.п. конверсия лид → сделка. Не из-за ИИ напрямую, а потому что менеджеры стали быстрее реагировать. Клиент не успевал уйти к более быстрому конкуренту.

+38% заполненность amoCRM. С 60% до 98% — потому что данные пишутся автоматически, а не «когда руки дойдут».

3 месяца окупаемость. При бюджете проекта 4.5 млн ₽ и экономии ФОТ на отделе ≈1.6 млн ₽/мес.

«Мы пробовали ChatGPT, расширения, прикручивали GPT-4. Ничего не работало, потому что менеджеры не хотели менять процесс. Здесь сработало — потому что ассистент вписан в Telegram и amoCRM, а не существует отдельно. Через две недели после запуска три менеджера сами пришли с предложениями, как ещё его улучшить. Это первый раз, когда инструмент стал «своим», а не навязанным сверху».

— РОП, заказчик

Что дальше

Сейчас работаем над v2:

• Голосовые команды для менеджеров в полевых выездах (через Whisper + локальный TTS).
• Расширение на отдел сервиса — диагностика проблем оборудования по описанию клиента, подбор запчастей.
• Прогноз вероятности сделки на основе истории переписок и характеристик клиента — ML-модель поверх данных за 3 года.

Поддержка и развитие — ежемесячный retainer 280 тыс ₽.

Стек

• Backend: Python 3.12, FastAPI, Celery + Redis, PostgreSQL, structlog
• AI: Saiga-Mistral 7B (локально), GigaChat (фолбэк), BAAI/bge-m3 (эмбеддинги), BAAI/bge-reranker-v2 (re-ranking), Qdrant (вектор-стор)
• Интеграции: amoCRM REST + webhooks, Telegram Bot API, IMAP, Mango Office, 1С через HTTP-сервисы
• Frontend: React 18 + TypeScript для админ-панели и iframe-расширения amoCRM
• Инфра: on-premise (Ubuntu 22.04), Docker Compose, NVIDIA A100 40GB, Grafana + Sentry

Когда такой подход подходит вашей компании

Подойдёт, если:

• B2B со сложным продуктом и каталогом 1 000+ позиций.
• Менеджеры тратят >30% времени на рутину (поиск, КП, заполнение CRM).
• Готовые ИИ-расширения «не зашли» — нужны более глубокие интеграции.
• Есть требования к compliance: данные не должны покидать периметр.

Не подойдёт, если:

• Каталог меньше 200 позиций — проще нанять второго менеджера.
• Бизнес массовый B2C с простыми сделками — там работают готовые SaaS.
• Ожидание «магии без изменения процессов» — без поддержки РОПа внедрение проваливается.