LLM для маркетинга без “магии”: как за 1 неделю собрать MQL→SQL-аналитику на базе ваших звонков и писем

LLM для маркетинга без “магии”: как за 1 неделю собрать MQL→SQL-аналитику на базе ваших звонков и писем

В 2026 у многих проседает классическая лидогенерация: меньше входящих, длиннее цикл, больше денег уходит в сохранение выручки. Поэтому маркетингу всё важнее не “ещё контент”, а связка с продажами через RevOps (общая ответственность маркетинга, sales и customer success за выручку). Самый быстрый способ — сделать LLM-пайплайн, который превращает сырые разговоры и переписку в измеримые признаки, ведущие к MQL→SQL.

Сделайте так на этой неделе.

1) Соберите “сырьё” для обучения без обучения
— Возьмите 30–60 кейсов за последние 3–6 месяцев: 15–25, которые дошли до SQL, и 15–25, которые остановились на MQL.
— Для каждого кейса выгрузите:
— текст звонка (расшифровка) или стенограмму
— переписку (email/чат) до статуса SQL/отказа
— 3–5 полей из вашей CRM: отрасль, размер, роль ЛПР, запрос/продукт, этап и причина остановки (если фиксируется).
— Важно: не “обучайте” модель на статусах. Ваша цель — признаки и гипотезы, которые потом вы проверите в аналитике.

2) Опишите схему признаков (коротко, но строго)
Схема должна быть одинаковой для всех кейсов. Пример набора признаков (выберите 10–15, не больше):
— “Боль” сформулирована конкретно (да/нет)
— Есть ли инициатор внутри компании (да/нет)
— Упоминались сроки/дэдлайны (да/нет + как сформулированы)
— Запрос про ROI/экономику (да/нет)
— Требования к процессу: пилот/PoC/интеграции (да/нет)
— Уровень зрелости: “понимаем задачу” vs “ищем решение” (3-балла)
— Есть ли признаки внутреннего согласования (комитет/IT/юристы/закупки) (да/нет)
— Тип возражений: цена, риск, сроки, отсутствие данных, “не сейчас” (категории)
— Качество лида по контексту: роль/ответственность совпадает с ICP (да/нет, если можно определить по тексту)
— “Следующий шаг” зафиксирован в переписке/созвоне (да/нет)

3) Сгенерируйте разметку LLM в “режиме контролируемого ответа”
— Подготовьте промпт-трафарет: вы просите модель вернуть JSON только по вашей схеме признаков.
— Добавьте правило: если признак не найден в тексте — ставить null, а не угадывать.
— Для каждой разметки храните ещё 2 поля:
— короткая цитата/фрагмент текста, на котором основан вывод (1–2 предложения)
— уверенность 0–1 (тоже как число, чтобы потом фильтровать шум).
— Прогоните все кейсы; параллельно сделайте ручную проверку 10 кейсов: 5 дошли до SQL и 5 нет. Цель — увидеть, где модель систематически ошибается.

4) Превратите признаки в модель принятия решений (не “скоринг навсегда”, а диагностик)
— Соберите таблицу: строки = кейсы, столбцы = ваши признаки + статус SQL (1/0).
— Посчитайте:
— долю SQL среди кейсов с признаком (например, “ROI упоминался”)
— долю отказов среди кейсов с каждым признаком
— простую логистику/feature importance (можно в Excel/Google Sheets через коэффициенты, либо в BI через базовую модель).
— Не усложняйте: на первом проходе вам важнее топ-5 признаков, которые различают SQL и остановку.

5) Сделайте 2 практических артефакта для команды
— Артефакт A (для маркетинга): “корректировки позиционирования под ROI и процесс”
— На основе топ-признаков напишите 3 тезиса, которые должны появляться в контенте и первом касании: где конкретизировать экономику, как говорить о сроках пилота, какие риски закрывать.
— Артефакт B (для sales/RevOps): “шаблон квалификации”
— Сформируйте мини-скрипт из 7–10 вопросов по вашим признакам (по сути, чтобы быстро понять: боль конкретная? экономика? внутренние согласования? следующий шаг?).
— Включите “критерии квалификации” так, чтобы команда не спорила по ощущениям.

6) Проверьте эффект через инкрементальность (как минимум на уровне процесса)
На этой же неделе выберите одно изменение:
— либо новый шаблон письма/скрипта,
— либо добавьте 2 уточняющих вопроса на стадии MQL.
Дальше измеряйте не “ощущение лучше”, а один метрик-рычаг:
— конверсия MQL→SQL по когортам (новые обработанные лиды vs прошлые)
— и доля кей

— @AIinMarketingRuPro