Автозаполнение сделки в Bitrix24 после звонка: BANT-анализ на Python с МТС Exolve и YandexGPT

Привет, Хабр!

Менеджеры продаж не всегда вовремя и полно заносят данные о сделках в CRM после звонка. Часть информации может забыться, а часть может быть записана сокращенно.

Прослушивать звонки вручную и восстанавливать детали слишком трудоёмко, а ресурсов на это часто не хватает. Поэтому в этом материале соберём MVP-сервис на Python, который получает событие о завершённом звонке из МТС Exolve, забирает текст разговора, выделяет из него ключевые поля через YandexGPT и записывает результат в Bitrix24. На выходе получится рабочий пайплайн: вебхук, транскрибация, извлечение полей квалификации и обновление существующей сделки в CRM.

За основу возьмём BANT — базовый фреймворк квалификации лида: Budget, Authority, Need, Timing, то есть бюджет, лицо, принимающее решение, потребность и сроки. И расширим его, добавив оценку интереса клиента, фиксацию конкурентов и возражений. Такого набора достаточно, чтобы квалифицировать лид, приоритизировать сделку и сохранить контекст следующего контакта, но не превращать карточку в анкету на десятки полей.

Стек: Python 3.10+, Flask, SQLite, Call Transcribation API МТС Exolve, YandexGPT API, Bitrix24 REST API.

Архитектура решения

Разделим MVP на пять компонентов. Такой расклад даёт понятный поток данных и не смешивает вебхук, работу с внешними API и запись в CRM в одном файле.

• app.py принимает вебхук о завершении звонка, валидирует запрос, запускает фоновую обработку и отдаёт быстрый ответ.

• database.py хранит состояние пайплайна и защищает систему от дублей по call_id.

• exolve_api.py забирает транскрибацию из МТС Exolve и приводит её к формату диалога.

• yandex_llm.py формирует строгий запрос к модели и парсит ответ в JSON.

• bitrix24_crm.py ищет сделку и обновляет пользовательские поля Bitrix24.

Границы ответственности простые: HTTP-слой только принимает событие, база хранит состояние обработки, а интеграции с МТС Exolve, YandexGPT и Bitrix24 изолированы по модулям.

Шаг 1. Принимаем вебхук и быстро отвечаем

Самая чувствительная часть такого сценария — не задерживать ответ на входящее событие. Поэтому мы быстро валидируем payload и сразу уводим тяжёлую работу в фон.

app.py

@app.route('/webhook/exolve', methods=['POST']) def handle_exolve_webhook(): if request.args.get('token') != app.config['WEBHOOK_SECRET']: return "Forbidden", 403 data = request.json or {} if data.get('event_type') != 'call.completed': return jsonify({"status": "ignored"}), 200 payload = data.get('payload', {}) call_id = payload.get('call_id') direction = payload.get('direction') client_phone = payload.get('from') if direction == 'inbound' else payload.get('to') audio_url = payload.get('recording_url') if not call_id or not client_phone or not audio_url: return "Bad Request", 400 if create_call_record(call_id, client_phone, audio_url): thread = threading.Thread( target=process_call_async, args=(call_id, client_phone, audio_url), ) thread.start() return jsonify({"status": "accepted"}), 202 return jsonify({"status": "already_processed"}), 200

На вход обработчик получает JSON от МТС Exolve, на выходе — короткий HTTP-ответ и фоновую задачу. Критичных мест три: проверить секрет до любой тяжёлой логики, не запускать пайплайн на промежуточных событиях и не создавать второй поток для обработанного call_id.

Важно вернуть именно 202 Accepted, а не ждать полного завершения пайплайна. HTTP-слой подтверждает, что мы приняли событие и взяли его в обработку, а не то, что успели получить транскрибацию, прогнать LLM и обновить CRM. Для MVP хватит threading, но в проде этот слой лучше заменить очередью задач: при нескольких воркерах и перезапусках процесса такой фоновой поток не даёт надёжных ретраев и контроля состояния.

Полный app.py: ▼

Шаг 2. Сохраняем состояние и защищаемся от дублей

У MVP три внешние точки отказа: МТС Exolve, YandexGPT и Bitrix24. Если запись в CRM упадёт по сети, нужно понять, на каком шаге оборвался пайплайн. Поэтому храним не только call_id, но и статус обработки.

Для такого сценария полезно сразу договориться о цепочке состояний: PENDING -> STT_OK -> LLM_OK -> CRM_OK или ERROR. Этого хватает, чтобы глазами понять, где завис звонок, и не лезть сразу в логи. call_id играет две роли: ключ идемпотентности и correlation id, по которому потом можно связать запись в базе, сообщения в логах и ответ внешнего API.

database.py

def init_db(): conn = get_db_connection() conn.execute( ''' CREATE TABLE IF NOT EXISTS calls ( call_id TEXT PRIMARY KEY, client_phone TEXT, audio_url TEXT, status TEXT DEFAULT 'PENDING', transcript TEXT, bant_result TEXT, created_at INTEGER ) ''' ) conn.commit() conn.close() def create_call_record(call_id, client_phone, audio_url): conn = get_db_connection() try: conn.execute( 'INSERT INTO calls (call_id, client_phone, audio_url, created_at) VALUES (?, ?, ?, ?)', (call_id, client_phone, audio_url, int(time.time())), ) conn.commit() return True except sqlite3.IntegrityError: return False finally: conn.close()

Этот слой принимает данные из вебхука и возвращает бинарный результат: запись создали или запись с таким call_id существует. Именно первичный ключ даёт идемпотентность. Для MVP SQLite удобна тем, что её можно поднять без миграций, но в проде такой журнал лучше перенести в Postgres.

Полный database.py: ▼

Шаг 3. Получаем транскрибацию и собираем диалог

После вебхука нам нужен не аудиофайл сам по себе, а текст, который можно отдать модели. В этом сценарии используем Call Transcribation API МТС Exolve и не отправляем запись в отдельный сервис распознавания речи.

exolve_api.py

def get_call_transcription(call_id: str, config) -> str | None: url = f"https://api.exolve.ru/voice/v1/calls/{call_id}/transcription" headers = {"Authorization": f"Bearer {config.EXOLVE_API_KEY}"} for attempt in range(5): try: response = requests.get(url, headers=headers, timeout=10) if response.status_code in (404, 422): time.sleep(10) continue response.raise_for_status() messages = response.json().get("messages", []) if not messages: time.sleep(5) continue lines = [] for msg in messages: role = msg.get("role", "") text = msg.get("text", "").strip() if text: speaker = "Менеджер" if role == "OUTBOUND" else "Клиент" lines.append(f"{speaker}: {text}") return "\n".join(lines) except requests.RequestException: time.sleep(5) return None

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

Полный exolve_api.py: ▼

Шаг 4. Извлекаем BANT+ в строгий JSON

Если попросить модель “проанализировать звонок”, она начнёт писать свободным текстом. Для CRM это бесполезно. Поэтому задаём модели жёсткий формат и сразу ограничиваем, что она может вернуть: need, need_description, budget_estimated, decision_maker, timeline, intent_score, competitors, objections.

yandex_llm.py

SYSTEM_PROMPT = """ Извлеки из транскрипта BANT+. Если данных нет, верни null, "unknown" или []. Верни только валидный JSON: { "need": true, "need_description": "Описание боли клиента", "budget_estimated": "150000-200000", "decision_maker": "unknown", "timeline": "30d", "intent_score": "med", "competitors": [], "objections": [] } """ def extract_bant_data(transcript: str, config) -> dict | None: if not transcript: return None payload = { "modelUri": config.MODEL_URI, "completionOptions": { "stream": False, "temperature": 0.1, "maxTokens": "1500", }, "messages": [ {"role": "system", "text": SYSTEM_PROMPT}, {"role": "user", "text": f"Транскрипция:\n{transcript[:15000]}"}, ], } for attempt in range(3): try: response = requests.post( config.YANDEX_GPT_URL, headers={ "Authorization": f"Api-Key {config.YANDEX_API_KEY}", "x-folder-id": config.YANDEX_FOLDER_ID, "Content-Type": "application/json", }, json=payload, timeout=20, ) response.raise_for_status() response_json = response.json() raw_text = response_json.get("result", {}).get("alternatives", [{}])[0].get("message", {}).get("text", "") if not raw_text: continue clean_text = raw_text.strip().removeprefix("```json").removesuffix("```").strip() return json.loads(clean_text) except (json.JSONDecodeError, requests.RequestException): if attempt == 2: return None

Эта функция получает текст разговора и возвращает готовую структуру для CRM. В этом фрагменте важны три вещи: temperature=0.1, жёсткая JSON-схема и очистка Markdown-артефактов. В таком режиме модель отвечает стабильнее, усечение транскрипта защищает от переполнения контекста, а результат можно сразу маппить в поля CRM.

Полный yandex_llm.py: ▼

Шаг 5. Записываем результат в Bitrix24

После работы модели нам не нужен свободный текст. Нужен предсказуемый маппинг полей в CRM. Сделаем это через пользовательские поля сделки. Минимальный набор полей такой: описание потребности, бюджет, ЛПР, сроки, интерес, конкуренты и возражения.

bitrix24_crm.py

def normalize_phone(phone: str) -> str: digits = re.sub(r'\D', '', phone or '') if digits.startswith('8') and len(digits) == 11: digits = '7' + digits[1:] return digits def update_crm_deal(client_phone: str, bant_ dict, config) -> bool: clean_phone = normalize_phone(client_phone) search_url = f"{config.BITRIX24_WEBHOOK_URL}crm.deal.list.json" search_resp = requests.post( search_url, json={"filter": {"=CONTACT.PHONE": clean_phone}}, timeout=10, ) search_resp.raise_for_status() deals = search_resp.json().get("result", []) if not deals: return False payload = { "ID": deals[0]["ID"], "FIELDS": { "UF_CRM_BANT_NEED": bant_data.get("need_description") or "", "UF_CRM_BANT_BUDGET": bant_data.get("budget_estimated") or "", "UF_CRM_BANT_DM": bant_data.get("decision_maker") or "unknown", "UF_CRM_BANT_TIMELINE": bant_data.get("timeline") or "", "UF_CRM_INTENT": bant_data.get("intent_score", "low").upper(), "UF_CRM_COMPETITORS": ", ".join(bant_data.get("competitors", [])), "UF_CRM_OBJECTIONS": ", ".join(bant_data.get("objections", [])), }, } update_url = f"{config.BITRIX24_WEBHOOK_URL}crm.deal.update.json" response = requests.post(update_url, json=payload, timeout=10) response.raise_for_status() return "error" not in response.json()

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

В текущем решении новая сделка не создаётся: сервис обновляет существующую, найденную по номеру телефона клиента.

Маппинг полей в этом примере прямой:

Полный bitrix24_crm.py: ▼

Запуск и проверка

После сборки всех частей остаётся проверить, что событие доходит до приложения и проходит через весь пайплайн. Для локального теста достаточно поднять Flask и отправить тестовый вебхук на маршрут /webhook/exolve.

python app.py

Если приложение запущено локально, можно пробросить туннель через ngrok и отправить тестовый payload. В ответе ожидаем 202, а в журнале или в SQLite — новую запись со статусом PENDING, которая затем перейдёт в STT_OK, LLM_OK и CRM_OK.

Проверка выглядит так:

• маршрут /webhook/exolve отвечает 202 Accepted на валидный call.completed;

• в SQLite появляется запись с нужным call_id;

• статус звонка проходит цепочку PENDING -> STT_OK -> LLM_OK -> CRM_OK;

• в Bitrix24 обновляются пользовательские поля сделки, найденной по телефону;

• в HTML-журнале видно и итоговый статус, и извлечённые поля BANT+.

Полный test_webhook.py: ▼

Для быстрой проверки результата без захода в SQLite в проекте есть HTML-шаблон с последними записями.

Полный templates/index.html: ▼

Что можно усилить дальше

У MVP есть несколько точек для следующего шага.

• Фоновую обработку через threading лучше заменить очередью задач, чтобы контролировать ретраи и не терять задачи при перезапусках

• SQLite стоит заменить на Postgres, если пайплайн будет работать под нагрузкой и с параллельной обработкой

• Поиск сделки по CONTACT.PHONE стоит заменить на связку контакт -> активная сделка, если в CRM у контакта может быть несколько сделок

• Проверку через json.loads стоит дополнить схемной валидацией, чтобы контролировать не только формат, но и допустимые значения полей

• Локальные ретраи внутри модулей стоит вынести в общую механику переобработки, чтобы звонки не зависали в ERROR

• Логи стоит расширить: сохранять call_id, шаг пайплайна, HTTP-статус и причину ошибки

• Для хранения транскриптов стоит заранее определить политику по персональным данным и срокам хранения

В итоге

Мы собрали MVP-сервис, который получает событие о завершённом звонке, забирает транскрибацию из МТС Exolve, извлекает BANT+ через YandexGPT и записывает результат в Bitrix24. Такой сценарий снижает потери на двух этапах: когда менеджер не собрал часть квалификации в разговоре и когда детали теряются при ручном заполнении CRM. Следующий логичный шаг — вынести фоновую обработку в очередь задач, добавить схемную валидацию ответа модели и усилить логику поиска сущностей в CRM, не меняя общий контракт пайплайна.

Код на гитхабе.