bitrixАвтозаполнение карточек CRM через ИИ: кейс логистической компании
Задача
Автозаполнение карточек CRM с помощью ИИ потребовалось логистической компании — оператору сборных грузов на направлениях Россия — Средняя Азия с автопарком 45 фур и сетью из 7 складов консолидации. Компания обрабатывает около 600 заявок на перевозку в месяц, и 80% из них приходит не через форму на сайте, а свободным текстом: письма на общий ящик, сообщения в WhatsApp и Telegram, вложения с заявками в Word и PDF. До проекта каждую такую заявку менеджер разбирал вручную: читал письмо, находил маршрут, тип груза, вес и объём, желаемую ставку, контакты грузоотправителя, а затем переносил всё это в сделку Битрикс24. На одну заявку уходило 12–18 минут чистого ввода, при штате из 9 менеджеров это съедало около трети рабочего дня. Из-за рутины люди откладывали ввод «на потом»: в пиковые дни до вечера в CRM попадала только половина заявок, а ответ клиенту с расчётом ставки отправлялся через 3–5 часов после обращения. По внутреннему замеру, 15–20% потенциальных заказов уходило к конкурентам именно из-за медленного первого ответа. Были и ошибки ввода. Тоннаж путали с объёмом, город загрузки — с городом выгрузки, ставку в юанях записывали как рублёвую. Каждая такая ошибка всплывала на этапе расчёта или, хуже, при выставлении счёта: за полгода компания списала около 400 тысяч рублей убытков из-за неверно внесённых параметров груза. Контролировать ручной ввод было невозможно — проверять пришлось бы каждую карточку. Руководство ставило задачу: убрать ручное переписывание заявок, чтобы менеджер получал готовую сделку с уже заполненными полями и занимался только проверкой и расчётом ставки. При этом было важно не менять привычные каналы общения с клиентами — никаких обязательных форм и личных кабинетов, которые клиенты-грузоотправители всё равно бы игнорировали. Также требовалось журналировать, что именно распознал ИИ, и оставлять менеджеру возможность скорректировать любое поле до запуска бизнес-процесса. Срок пилота — два месяца, бюджет ограничен, обучение команды не дольше одного дня.
Решение
Мы построили сервис на базе облачного Битрикс24 и LLM-модели, развёрнутой в российском облаке для соответствия требованиям по персональным данным. Архитектура — событийная: любой входящий запрос из почты, WhatsApp или Telegram превращается в структурированную сделку без участия человека. Первый слой — сбор обращений. Корпоративный ящик подключён к Битрикс24 через стандартную почтовую интеграцию CRM, WhatsApp и Telegram — через открытые линии и коннектор. На создание лида повешено событие REST API (OnCrmLeadAdd), которое отправляет текст обращения и вложения в наш микросервис на Python (FastAPI). Вложения (заявки в PDF и Word, скриншоты переписок) извлекаются из письма, документы проходят OCR, после чего весь текст объединяется в один контекст. Второй слой — извлечение данных LLM. Мы составили строгий промпт с описанием структуры грузоперевозки и потребовали от модели ответ в JSON по схеме: город загрузки и выгрузки, тип груза, вес в тоннах, объём в кубометрах, дата готовности груза, желаемая ставка с валютой, тип кузова, контакты. Схема валидируется через Pydantic: если модель вернула вес текстом или перепутала поля, запрос повторяется с уточнением. Критичный шаг — нормализация: города приводятся к справочнику компании (около 300 населённых пунктов с филиалами и хабами), валюта — к ISO-коду, типы грузов — к внутреннему классификатору из 14 позиций. Для этого модели передаётся сам справочник, а результат сверяется точным совпадением. Третий слой — запись в Битрикс24. Через REST API создаётся сделка в воронке «Новые заявки» с заполненными пользовательскими полями, прикрепляется исходное письмо, ставится ответственный по round-robin между менеджерами смены. Если по адресу e-mail найден существующий клиент, сделка привязывается к его компании и контакту. В комментарий сделки сервис пишет, какие поля распознаны с высокой уверенностью, а какие требуют проверки — для этого мы добавили в промпт оценку confidence по каждому полю. Сделки с низкой уверенностью помечаются красной стадией «Проверить вручную». Четвёртый слой — работа менеджера. Роботы Битрикс24 ставят задачу «Проверить заявку» со сроком 15 минут. Менеджер открывает готовую карточку, сверяет ключевые поля с исходным письмом по боковой панели и запускает бизнес-процесс расчёта ставки одним кликом. Дальше срабатывает стандартный бизнес-процесс: запрос ставки у перевозчиков, расчёт маржи, генерация КП из шаблона и отправка клиенту. Отдельно мы реализовали контур обратной связи: все правки менеджера логируются, и раз в две недели мы дообучали промпт на реальных ошибках — за первые полтора месяца точность распознавания маршрута выросла с 87% до 96%. Пилот занял 3 недели на 2 каналах, затем подключили остальные источники и провели двухчасовое обучение команды.
Архитектура
Источниками данных выступают три канала: корпоративная почта (подключена штатным почтовым трекером Битрикс24), WhatsApp Business API и Telegram — через коннекторы открытых линий. Каждое входящее обращение создаёт лид, событие OnCrmLeadAdd через исходящий вебхук передаёт идентификатор в интеграционный слой. Интеграционный слой — микросервис на FastAPI, развёрнутый в двух репликах за балансировщиком в российском облаке. Задачи обработки ставятся в очередь RabbitMQ: воркер забирает текст лида через REST API, скачивает вложения, прогоняет документы через OCR, формирует контекст и вызывает LLM с жёсткой JSON-схемой ответа. Ответ валидируется Pydantic-моделью; при ошибке схемы или таймауте выполняется до трёх повторных попыток с экспоненциальной задержкой. Необработанные за 10 минут задачи попадают в dead-letter queue, и дежурный получает алерт в Telegram. Далее сервис через REST API создаёт сделку с пользовательскими полями, привязывает компанию и контакт по e-mail, прикрепляет исходные файлы и запускает роботов постановки задачи менеджеру. Все вызовы REST API идут через очередь с учётом лимита 2 запроса в секунду, что исключает блокировки со стороны облака. Отказоустойчивость: при недоступности LLM обращения копятся в очереди и обрабатываются после восстановления, деградация сервиса не приводит к потере лидов — они в любом случае создаются в CRM стандартными средствами. Логи распознавания и правок менеджеров пишутся в PostgreSQL. Мониторинг — Prometheus + Grafana: длина очереди, доля ошибок валидации, средняя уверенность модели, время цикла «письмо → сделка». Метрики выводятся на дашборд руководителя отдела продаж.
Стек
Битрикс24 (облако), LLM в российском облаке (YandexGPT API), Python 3.11, FastAPI, Pydantic, Tesseract OCR, RabbitMQ, PostgreSQL 15, REST API Битрикс24, открытые линии, Grafana + Prometheus
Результат
Проект окупился за первые три месяца работы. Главный эффект — время обработки заявки сократилось в 5 раз: с 15 минут ручного ввода до 3 минут проверки готовой карточки. Первый ответ клиенту с расчётом ставки теперь уходит в среднем через 40 минут вместо 3–5 часов, а в тихие часы — в течение 15 минут. Скорость напрямую конвертировалась в деньги. Доля заявок, дошедших до расчёта ставки, выросла с 78% до 97% — перестали теряться вечерние и ночные обращения, которые раньше ждали утра. Конверсия из заявки в оплаченную перевозку поднялась с 24% до 31%: по оценке коммерческого директора, именно быстрый первый ответ стал решающим фактором примерно в половине выигранных сделок. В деньгах это дало плюс 2,1 млн рублей выручки в месяц при той же рекламной нагрузке. Освободившееся время менеджеров — около 4 часов в день на человека — перераспределили на работу с крупными клиентами и повторные продажи. Компания не стала расширять штат, хотя за полгода поток заявок вырос на 35%: те же 9 менеджеров справляются с объёмом, на который раньше понадобилось бы минимум 12 человек. Экономия на фонде оплаты труда — порядка 3,5 млн рублей в год. Качество данных изменилось радикально: ошибки в параметрах груза, раньше стоившие около 70 тысяч рублей в месяц списаний, сошли почти на нет — за последний квартал зафиксировано два инцидента на 1800 заявок, оба на этапе ручной правки. Появилась и прозрачность: руководитель впервые увидел реальную воронку по источникам и направлениям, потому что в CRM теперь попадает 100% обращений, а не те, что менеджеры успели внести. На основе этих данных компания закрыла два убыточных направления и усилила ставку на маршруте с маржой выше средней.
«Раньше к обеду менеджеры только разгребали почту, а реальные продажи начинались после трёх. Теперь заявка сама превращается в сделку, человек только проверяет и считает ставку — мы отвечаем клиентам быстрее всех на рынке сборных грузов. За полгода взяли на треть больше заказов без единого нового сотрудника.»
Расскажите о задаче — предложим архитектурное решение
Бесплатный предварительный аудит за 3 рабочих дня: анализ задачи, вариант архитектуры, оценка сроков и бюджета. NDA при необходимости.
- Общение — с техническим архитектором, не с менеджером
- Фиксированная цена после технического аудита
- Гарантия на разработку по договору