AI для отдела продаж B2B: лидген, квалификация, outbound на self-hosted LLM

AI для отдела продаж B2B — это связка из четырёх задач: лидген из открытых источников, квалификация по ICP, генерация персонализированного outbound и отслеживание ответов. На self-hosted LLM эта связка работает без отправки клиентской базы в OpenAI или Anthropic — критично для B2B с NDA и сегментов, где список лидов сам по себе коммерческая тайна.

В этой статье — что именно автоматизируется на каждом этапе воронки, какой стек собираем на типовых внедрениях, и три-четыре кейса «первая итерация работала не так, как ожидали». Опыт команды botAGI на пилотах с RU SMB и онлайн-образованием — без клиентских имён и фабрикованных цифр.

Что делает AI в B2B-продажах

Воронка B2B продаж раскладывается на четыре этапа, на каждом из которых AI заменяет часть рутинного человеческого труда. Это не «AI вместо продавцов» — это «AI убирает 70% подготовительной работы, чтобы продавец занимался разговорами и сделками, а не парсингом сайтов».

Этап 1: лидген. Сбор и обогащение списка потенциальных клиентов из открытых источников — сайты, отраслевые каталоги, ОКВЭДы, ФНС, новости компаний, открытые тендеры. AI здесь нужен не столько для парсинга (это делают краулеры), сколько для нормализации и обогащения: «вот сайт компании X — определи отрасль, размер по выручке, есть ли уже AI/digital-инициативы».

Этап 2: квалификация. Сравнение каждого лида с ICP (Ideal Customer Profile) компании. Тут AI силён на embedding-сравнении описания компании с эталонным описанием «нашего идеального клиента» и на текстовой классификации сигналов вроде «недавно подняли раунд», «открыли вакансию data-инженера», «запустили новый продукт».

Этап 3: персонализация outbound. Генерация first-touch письма или сообщения с учётом контекста конкретной компании: последняя новость, открытая позиция, специфика отрасли. Этот этап — главное отличие AI-SDR от классического mail-merge: вместо {{first_name}}, мы помогаем компаниям в {{industry}} появляется письмо, в котором есть осмысленная связка между болью компании и продуктом.

Этап 4: follow-up и трекинг. Отслеживание ответов, понимание «это позитивный ответ» vs «вежливый отказ» vs «не сейчас», автоматический планинг следующего шага и обновление CRM. Здесь AI не отвечает за клиента, а помогает SDR-у не упустить контекст по 200 параллельным цепочкам.

Чем это отличается от классической CRM-автоматизации (Bitrix24-сценариев или amoCRM-роботов)? Те работают по шаблонам и условиям («если поле X = Y, отправь письмо Z»). AI-слой добавляет понимание контекста — то есть способность писать осмысленный текст, классифицировать сложные сигналы и сопоставлять разнородные источники. Подробнее границу между шаблонной автоматизацией и агентами разбираем в материале про AI-агента vs чат-бот и в типах AI-агентов для бизнеса.

Этап 1: лидген из открытых источников

Технический контур, который мы собираем на типовых внедрениях:

Краулер. Playwright или Crawlee — для сайтов компаний, отраслевых каталогов, новостных лент. Headless-браузер обходит JS-рендеринг, который ломает простой requests + BeautifulSoup.
Структурные источники. Открытые API ФНС (egrul.nalog.ru), ОКВЭД-классификатор, открытые тендеры (zakupki.gov.ru), Контур.Фокус как платный быстрый канал. Структурные данные дешевле парсить и сложнее ошибиться.
Нормализация через LLM. Сайт компании в виде сырого HTML или текста идёт в Qwen 3 32B или Llama 3.3 70B с инструкцией «извлеки: чем занимается, размер по выручке (если упоминается), технологический стек, контактные данные, последние новости». См. также сравнение DeepSeek vs Qwen vs Llama для русского — Qwen 3 32B чаще всего попадает в баланс «качество русского + скорость инференса».
Дедупликация. PostgreSQL с pgvector или Qdrant: каждая компания получает embedding своего описания, и при добавлении новой проверяется cosine similarity с существующими. Если выше 0.92 — это та же компания, объединяем записи. См. сравнение Weaviate vs Qdrant vs Milvus vs pgvector.

Производительность — ориентировочные цифры на типовом железе. Один сервер с RTX 4090 (24 GB VRAM) на Qwen 3 32B в Q4-квантизации через vLLM в наших пилотах обрабатывал порядка нескольких тысяч карточек компаний в сутки в режиме batch-инференса. Точные числа зависят от средней длины входа, количества параллельных воркеров краулера и того, что именно достаём из карточки. Считайте это иллюстративной точкой отсчёта, не бенчмарком.

Выбор embedder — отдельная тема. Для русского рекомендуем bge-m3 как разумный дефолт, подробности в материале про embedding-модели для русского языка.

Что НЕ делать на этапе лидгена:

Не парсить LinkedIn напрямую — слетит на rate-limit или нарушении ToS за 2–3 недели; используйте легальные посредники или открытые источники.
Не обогащать через OpenAI / Anthropic API — это та же утечка клиентской базы, ради которой и затевался self-hosted.
Не пытаться сразу строить «полную модель компании» — стартуйте с 5–6 ключевых полей и достраивайте по мере появления конкретных запросов.

Этап 2: квалификация по ICP

ICP (Ideal Customer Profile) — это формализованное описание «нашего идеального клиента»: отрасль, размер, география, технологический стек, поведенческие сигналы. Квалификация — это сопоставление каждого нового лида с этим описанием и присвоение скора.

Гибридная схема, которую мы используем:

Жёсткие фильтры на структурированных полях: отрасль (по ОКВЭД), выручка (есть/нет в открытых источниках), регион. Если компания не проходит — она MQL=0, дальше не идёт.
Embedding-сравнение описания компании с эталонным описанием ICP (написанным вручную маркетологом в 2–3 абзацах). Cosine similarity > 0.78 — типовое пороговое значение, которое настраивается по precision/recall на исторических данных. Если у вас 500 закрытых сделок — гоняйте эти 500 описаний компаний против эталона ICP, смотрите распределение similarity и подбирайте порог.
LLM-классификация поведенческих сигналов. Промпт: «вот описание компании и три последние новости — оцени по шкале 1–5 признаки: недавно росли (раунд/выручка), активны в найме, есть ли публичные digital-инициативы». Это даёт sales-team понимание «горячести» в дополнение к статичным критериям.

Получаем три выхода: MQL (отсев), SQL-warm (подходит, но без срочных сигналов), SQL-hot (подходит + сильные сигналы). Дальше — разные cadence outbound для warm и hot.

Что НЕ работает в квалификации: пытаться формализовать ICP в 20+ критериях и ждать, что AI «всё посчитает». Чем больше критериев и сложнее их веса, тем менее интерпретируемо итоговое решение, и тем труднее объяснять команде продаж, почему конкретный лид попал в hot. На практике 5–7 факторов с понятной логикой работают надёжнее, чем «AI-чёрный ящик».

Этап 3: персонализация outbound

Здесь AI-слой даёт наибольший прирост по сравнению с классическим mail-merge. Цель — first-touch письмо или Telegram-сообщение, которое читается как «человек посмотрел на нашу компанию и написал по делу», а не как «массовая рассылка».

Контекст, который подаём в промпт:

2–3 предложения о компании-лиде из лидген-стадии.
Последняя релевантная новость (если есть в обогащении).
Открытая вакансия или признак найма (если есть).
Профиль контактного лица (роль, что в его зоне ответственности).
3–5 предложений «нашего value proposition» — то, что мы продаём.

На выходе — короткое письмо в 5–8 строках с конкретной связкой «вот ваш контекст → вот наша возможная польза → вот следующий шаг».

Anti-pattern, который мы поймали на первой версии: использование GPT-4o или Claude Opus для генерации outbound. Качество письма — отличное, но интонация «AI-detectable» — слишком гладкая, слишком симметричная, с характерными оборотами «I hope this finds you well» / «надеюсь, у вас всё хорошо». Уже на второй неделе пилота получали жалобы от клиентов «у вас рассылка от AI, неинтересно». Перешли на Qwen 3 32B с few-shot примерами из топ-10 успешных писем команды продаж — стало читаться более живо. Дополнительно — обязательный human-edit-pass перед отправкой первых 50–100 писем по новому шаблону, чтобы выловить остаточные «роботизированные» формулировки.

Промпт-инжиниринг тут отдельная дисциплина, см. материал про prompt engineering для русского. Ключевая практика — few-shot с 3–5 реальными письмами, которые ваши лучшие SDR-ы пишут вручную. Без few-shot модель даёт «средне-стандартный» B2B-английский / русский, который выглядит как робот.

Если у компании уже есть MCP-интеграция с amoCRM / Bitrix24 / 1С, сгенерированный outbound пишется напрямую в карточку сделки как черновик задачи на SDR, а не отправляется автоматически — это критично для контроля качества.

Что не сработало в первой версии

Раздел про реальные грабли. Четыре конкретных случая с типовых пилотов — без клиентских имён и точных бенчмарков.

Первая итерация outbound генерила высокий процент spam-флагов в Outlook → переделали с GPT-tone на human-edit-pass. Первый прогон 200 писем дал неприлично высокий процент попадания в Junk у получателей с Microsoft 365. Причины — две: характерные «AI-формулировки» (слишком гладкие переходы) и одинаковая структура писем (вступление + 3 буллита + CTA — это паттерн, который антиспам-фильтры быстро учатся ловить). Решили двумя шагами: добавили вариативность структуры (4 разных шаблона вместо одного) + обязательный human-edit-pass на первые 100 писем каждой новой кампании.

Попытка автоматизировать follow-up на «горячих» сделках → отвалились deal-ы, где нужна была живая беседа. На втором месяце пилота включили AI-генерацию follow-up на лиды со статусом «в работе». В нескольких сделках, где требовался личный звонок с CTO заказчика, AI-follow-up сместил тон в холодное русло, и заказчики перестали отвечать. Перестроили: разделили pipeline на «тёплый» (AI делает 80% работы, SDR проверяет) и «горячий» (AI готовит контекст и черновики, но финальную коммуникацию ведёт человек). Похожий разрез между «AI-pipeline» и «human-pipeline» обсуждали в общем разборе топ-7 ошибок внедрения AI.

Парсер LinkedIn слетел через 3 недели на rate-limit → перешли на открытые источники. Прямой парсинг страниц компаний с LinkedIn без официального API даёт результат на 2–3 недели, потом начинаются 429 и капчи. Переключились на комбинацию открытые ОКВЭД / ФНС + Контур.Фокус (легальный API) + парсинг публичных сайтов компаний. Покрытие на 10–15% ниже, но стабильность и compliance — стабильные.

Расшифровка звонков на старте давала плохое качество на жаргоне отдела продаж → дообучили post-processing промпт. Whisper и GigaAM на разговорной речи дают приемлемое WER, но термины вроде «амоха», «битру», внутренние названия продуктов после транскрипции записывались криво. Решение — не fine-tune акустической модели, а post-processing промпт через LLM «нормализуй эти термины по списку», подаваемый поверх raw-транскрипта. См. также подробный материал про AI-расшифровку звонков и автоматический перенос в CRM.

Где это даёт ROI и когда не стоит начинать

AI-стек для B2B-продаж имеет смысл, если у отдела ≥ 3 SDR / BDR, ≥ 200 outbound-касаний в неделю и есть структурированный ICP. На меньших объёмах стоимость разработки и поддержки стека не окупается — ручной outbound 2–3 продавцов дешевле и эффективнее.

Compliance — отдельный аргумент в пользу self-hosted: база лидов и переписка с потенциальными клиентами — это и коммерческая тайна, и (для контактных лиц) ПДн в смысле 152-ФЗ и корпоративного AI. Отправка этой базы в OpenAI или Anthropic — формально утечка, и для B2B с NDA-чувствительными клиентами это закрытый разговор.

Цикл «развернуть стек → выйти в прод» на типовых пилотах — 4–8 недель: первые 2 недели на лидген-pipeline и базовую квалификацию, ещё 2 недели на outbound-промпты с few-shot и human-edit-pass, дальше — итерации на основе фактических ответов рынка. Если интересует, как это разворачивается на собственной инфраструктуре — общий контекст в материале про корпоративный AI-помощник и в корпоративном чат-боте: SaaS vs self-hosted, оба разбирают организационную сторону проекта.

Для fine-tuning под голос конкретного отдела продаж — на больших командах с устоявшимся стилем — рекомендуем Saiga / Vikhr или кастомный fine-tune под русский, но это шаг для зрелых внедрений, не для первого пилота.

Хотите собрать AI-стек для отдела продаж под NDA и без передачи базы в облако? Команда botAGI разворачивает такие связки за 6–10 недель на типовом B2B-пилоте. Напишите в Telegram — обсудим объёмы, ICP и архитектуру под вашу нагрузку.