Обсудить задачу

Kommo + OpenAI: автоквалификация лидов в воронке

Интеграция Kommo с OpenAI закрывает один конкретный разрыв: каждый новый лид автоматически получает скоринг, теги и краткое резюме в карточке сделки до того, как менеджер до него дотянется. Технически это webhook Kommo на создание лида, вызов OpenAI с промптом квалификации и запись результата обратно в поля сделки через Kommo API. На объёме от 300 лидов в месяц это убирает ручную сортировку и отдаёт менеджеру уже отранжированную очередь.

В проектах Exceltic.dev мы регулярно видим одну и ту же картину: воронка наполняется быстрее, чем команда успевает читать заявки. Менеджер открывает карточку, перечитывает переписку, прикидывает бюджет и сегмент, ставит тег вручную - и так по каждому лиду. На 20 заявках в день это терпимо, на 80 это становится узким горлышком, через которое горячие лиды протекают вместе с мусором.

Ручная квалификация - это не про дисциплину, а про арифметику. Когда поток лидов превышает пропускную способность человека, любая методология BANT или ICP-скоринга превращается в формальность. Менеджер либо проставляет теги наугад, либо откладывает квалификацию на потом, и к моменту первого касания лид уже остыл.

Почему ручная квалификация не масштабируется

Квалификация вручную упирается в три ограничения, и ни одно из них не лечится наймом ещё одного менеджера.

Время на лид постоянно. Чтобы прочитать заявку, открыть переписку и принять решение по BANT, менеджеру нужно 3-5 минут. Это не сжимается. При 80 лидах в день только на квалификацию уходит до 6 часов - то есть рабочий день человека, который мог бы звонить.

Критерии плывут. Один менеджер считает компанию на 15 сотрудников целевой, другой - нет. Скоринг становится субъективным, и аналитика по источникам перестаёт быть достоверной: вы не знаете, проблема в трафике или в том, кто его размечал.

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

LLM снимает все три ограничения сразу: время на лид измеряется секундами, критерии зафиксированы в промпте и одинаковы для всех заявок, а пиковая нагрузка обрабатывается параллельно без потери скорости. Если вы ещё выбираете CRM под такой сценарий, начните с обзора Kommo CRM - там разобрана архитектура воронок и полей, на которую опирается эта интеграция.

Что реализуется

Схема целиком умещается в три шага: Kommo уведомляет о новом лиде, OpenAI его оценивает, результат пишется обратно в карточку. Дальше - технические детали каждого звена.

Webhook Kommo на новый лид

Kommo отправляет webhook на ваш endpoint при событии создания лида или его перехода на нужный этап воронки. В payload приходят ID сделки, значения полей и связанные сущности. Подписка на события настраивается в разделе разработчика; формат и список событий описаны в документации Kommo по webhooks.

Важный нюанс: webhook на создание лида часто приходит, когда карточка ещё пустая - переписка и поля подтянутся через секунды. Поэтому на практике мы вешаем триггер не на «создан», а на переход на этап «Новая заявка» или на появление первого сообщения, чтобы у модели был контекст для оценки.

Вызов OpenAI с промптом квалификации

Запрос идёт в Chat Completions API. В промпт передаётся текст заявки, переписка и описание целевого профиля (ICP, признаки BANT). Ответ нужно получать строго структурированным, иначе разбор JSON будет хрупким.

Здесь работает Structured Outputs - режим, в котором модель гарантированно возвращает JSON по заданной схеме. В отличие от старого JSON mode, при strict: true модель не пропустит обязательное поле и не выдумает значение enum за пределами схемы. Это подтверждено документацией OpenAI по structured outputs. Схема для квалификации обычно выглядит так:

{
  "name": "lead_qualification",
  "strict": true,
  "schema": {
    "type": "object",
    "additionalProperties": false,
    "required": ["score", "segment", "summary", "next_action"],
    "properties": {
      "score": { "type": "integer", "description": "0-100, готовность к продаже" },
      "segment": { "type": "string", "enum": ["hot", "warm", "cold", "spam"] },
      "summary": { "type": "string", "description": "резюме заявки в 1-2 предложения" },
      "next_action": { "type": "string" }
    }
  }
}

При strict-режиме additionalProperties обязан быть false, а все поля - перечислены в required; опциональные поля помечаются типом-объединением с null.

Выбор модели. Для квалификации почти всегда хватает gpt-4o-mini: задача - классификация и извлечение, а не рассуждение. По данным OpenAI, gpt-4o-mini стоит 0,15 доллара за 1M входных токенов и 0,60 доллара за 1M выходных (прайс OpenAI). Один лид - это примерно 800-1500 входных токенов (промпт плюс переписка) и 100-200 выходных. На старшую модель есть смысл переходить только если квалификация требует сложной логики по нескольким источникам данных.

Запись скоринга обратно в Kommo

Результат пишется в поля сделки методом обновления через Kommo API (PATCH /api/v4/leads/{id}): числовое поле под скоринг, поле списка под сегмент, текстовое - под резюме. Параллельно можно проставить теги и, при необходимости, сменить ответственного или этап. Справочник методов - в документации Kommo для разработчиков.

Идемпотентность. Один и тот же webhook Kommo может прийти дважды. Без защиты лид оценивается повторно, токены тратятся дважды, поля перезаписываются. Решение - ключ идемпотентности по ID лида плюс хэш контента: если лид с таким хэшем уже обработан, запрос к OpenAI не уходит.

Latency. Полный цикл webhook -> OpenAI -> запись в Kommo занимает обычно 2-5 секунд, из которых основное время - ответ модели. Для квалификации это незаметно: менеджер всё равно открывает карточку позже. Обработку стоит делать асинхронно через очередь, чтобы не держать webhook-соединение открытым.

Ошибки и ретраи. OpenAI API может вернуть rate limit (429) или временную ошибку (5xx). Нужен ретрай с экспоненциальной задержкой - обычно 3 попытки. Если все провалились, лид помечается тегом «требует ручной квалификации», чтобы он не потерялся между автоматикой и человеком. Молчаливый сбой здесь - худший сценарий: лид выглядит обработанным, но скоринга нет.

Как это работает пошагово

  1. В Kommo создаётся лид и попадает на этап «Новая заявка».
  2. Kommo отправляет webhook на ваш сервис с ID и полями сделки.
  3. Сервис проверяет ключ идемпотентности - не обрабатывался ли лид раньше.
  4. Из Kommo подтягивается переписка и значения полей для контекста.
  5. Формируется запрос в OpenAI: системный промпт с ICP и BANT плюс данные лида, схема Structured Outputs.
  6. Модель возвращает JSON со скорингом, сегментом, резюме и рекомендованным действием.
  7. Сервис методом PATCH пишет результат в поля сделки и проставляет теги.
  8. При ошибке - ретрай, при исчерпании попыток - тег ручной квалификации.

Дальше работает нативная механика Kommo: автоматизация по тегу/полю распределяет лиды, ставит задачи и запускает нужный этап. Если воронка ещё не настроена под такой сценарий, разберите её структуру по гайду как настроить воронку в Kommo CRM - скоринг полезен ровно настолько, насколько воронка умеет на него реагировать.

Реальный кейс с цифрами

B2B-компания, услуги для среднего бизнеса, поток около 1400 лидов в месяц из контекста, вебинаров и формы на сайте. До интеграции квалификацией занимались два менеджера, тратя суммарно порядка 5 часов в день.

После внедрения:

  • Время на квалификацию лида: с 3-5 минут до 3-4 секунд автоматического цикла.
  • Совпадение с экспертной оценкой: на контрольной выборке из 200 лидов авторазметка совпала с решением старшего менеджера в 89% случаев по сегменту hot/warm/cold; основная часть расхождений - на пограничных warm-лидах, где и люди спорят между собой.
  • Стоимость: при 1400 лидах в месяц и gpt-4o-mini расход на API - порядка 1,5-2 долларов в месяц. Не опечатка: на этой модели и таком объёме токенов это копейки.
  • Эффект на команду: освободившиеся 5 часов в день ушли в звонки по hot-лидам. Время первого касания по горячим заявкам упало с нескольких часов в пик до минут, потому что они автоматически поднимались в начало очереди.

Отдельно отметим: ценность не в «замене менеджера», а в том, что человек перестал тратить лучшие часы на сортировку и начал тратить их на продажу.

Для кого подходит

Интеграция оправдана, если выполняется хотя бы одно условие:

  • Поток от 300-400 лидов в месяц, и квалификация съедает заметную долю времени команды.
  • Есть выраженные пики после кампаний, когда очередь на квалификацию ломает SLA по первому ответу.
  • Критерии квалификации формализуемы - вы можете описать словами, что такое целевой лид.

В ручном режиме можно остаться, если лидов мало (до 10-15 в день) или каждый лид настолько уникален, что его всё равно разбирает эксперт - тогда автоматика добавит сложности без выигрыша.

Термин: BANT - классическая модель квалификации по четырём признакам: Budget (бюджет), Authority (полномочия принимать решение), Need (потребность), Timeline (сроки). В промпте OpenAI эти признаки задаются как критерии оценки лида.

Термин: Structured Outputs - режим OpenAI API, в котором ответ модели гарантированно соответствует заданной JSON-схеме. При strict: true модель не пропустит обязательное поле и не выйдет за пределы перечисленных значений, что делает разбор ответа надёжным для записи в CRM.

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

Часто задаваемые вопросы

Сколько это стоит в месяц по API? На gpt-4o-mini при объёме около 1000-1500 лидов в месяц расход на OpenAI API составляет единицы долларов: входной токен стоит 0,15 доллара за 1M, выходной - 0,60 доллара за 1M, а один лид укладывается в 1-2 тысячи токенов. Основные затраты проекта - не токены, а разработка и поддержка интеграции.

Насколько точна автоквалификация? На практике совпадение с решением опытного менеджера по базовой сегментации держится в районе 85-90%, если промпт хорошо описывает ICP. Расхождения концентрируются на пограничных лидах. Поэтому скоринг стоит использовать для приоритизации очереди, а не как окончательный приговор - финальное решение остаётся за человеком.

Что с приватностью данных клиентов? Данные лида уходят в OpenAI API. По условиям OpenAI, запросы через API не используются для обучения моделей по умолчанию. Тем не менее в промпт стоит передавать только то, что нужно для квалификации, и не отправлять лишние персональные данные. Если требования к данным жёсткие, рассматривают варианты с зоной обработки данных или enterprise-условиями - это уточняется до старта проекта.

Не сломается ли всё при дублях webhook? Нет, если заложена идемпотентность. Ключ по ID лида и хэшу контента отсекает повторную обработку, поэтому дубль доставки не приводит ни к двойному скорингу, ни к лишним тратам.

Можно ли менять критерии квалификации без переписывания кода? Да. Критерии живут в промпте и схеме Structured Outputs, а не в логике сервиса. Изменить определение целевого лида или добавить новый сегмент - это правка текста промпта, а не релиз новой версии интеграции.

Bottom line

Kommo и OpenAI закрывают узкое место, которое не лечится наймом: квалификацию лидов на потоке. Webhook, вызов модели с Structured Outputs и запись скоринга обратно в карточку дают команде уже отранжированную очередь за секунды и за несколько долларов в месяц. На объёме от 300-400 лидов это окупается высвобожденным временем менеджеров и упавшим временем первого касания по горячим заявкам.

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

Ещё статьи

Все →