История одного провала (которая повторяется везде)
Недавно разговариваю с директором по продажам одной B2B-компании. Человек явно расстроен: «Мы потратили полгода на внедрение AI-платформы. Подключили к CRM, настроили интеграции, заплатили консультантам. А система выдаёт какую-то чушь. Lead scoring показывает 90% вероятность сделки для лидов, которые даже трубку не берут. Бот на сайте отвечает про продукты, которых у нас нет. Это вообще работает хоть где-то?»
Я спросил: «А какие данные вы ей скормили?» Повисла пауза. «Ну... CRM-базу экспортировали. Там всё есть».
Залезли смотреть. В CRM — 12 тысяч контактов. У 8 тысяч не указана отрасль. У половины оставшихся — «Другое». Поле «причина отказа» заполнено в 3% случаев, и везде написано «нет бюджета» (даже когда клиент ушёл к конкуренту). История изменений стадий? Не ведётся. Когда сделка перешла из «переговоры» в «закрыто» — тайна, покрытая мраком.
Вот и вся магия искусственного интеллекта. Нет волшебства — есть математика. А математике нужны данные. Хорошие данные.
Garbage in — garbage out. Эта фраза старше, чем большинство нынешних data scientist-ов, но актуальна как никогда. И в этой статье я расскажу, как собрать датасет, с которым ИИ действительно будет работать — а не делать вид.
Что нужно ИИ в продажах: разбираемся по задачам
Универсального датасета не существует. То, что нужно для lead scoring, совершенно бесполезно для чат-бота. Давайте разберём по конкретным задачам — без воды, только то, что реально работает.
Lead Scoring: учим модель отличать золото от песка
Задача вроде бы простая: показать модели кучу лидов и сказать «вот эти стали клиентами, а эти — нет». Дальше она сама найдёт паттерны. Звучит красиво, но дьявол в деталях.
Для начала вам нужно минимум 500 исторических лидов с известным исходом. Причём не просто «закрыто» — а чётко «купил» или «отвалился». И вот тут первый подвох: если из 500 лидов купили только 20 — модель быстро выучит гениальную стратегию: всем говорить «не купит». Accuracy будет 96%, а толку ноль. Нужно хотя бы 50-100 успешных сделок.
Дальше — признаки. Откуда лид пришёл (сайт, реферал, холодный звонок), размер компании, отрасль, должность контакта. Плюс поведенческие штуки: как быстро ответили на первое письмо, сколько касаний было до сделки. Вот примерная структура того, что стоит собирать:
| Поле | Тип | Пример | Почему важно |
|---|---|---|---|
| lead_source | категория | website, referral, outbound | Источник сильно влияет на конверсию |
| company_size | число/категория | 10-50, 50-200, 200+ | Enterprise vs SMB — разные воронки |
| response_time | число (часы) | 2.5, 24, 72 | Быстрый ответ = горячий лид |
| deal_outcome | бинарный | won, lost | Это ваша целевая метка |
Чат-бот: тут важнее покрытие, чем объём
С чат-ботами интересная история. Многие думают: «Закинем туда всю документацию, пусть разбирается». А потом удивляются, почему бот на вопрос о ценах отвечает цитатой из технической спецификации трёхлетней давности.
Для рабочего бота нужны три вещи. Первое — актуальная база знаний. Не «вся документация за 5 лет», а 50-200 релевантных документов: FAQ, описание продуктов, текущие цены, политики возврата. Обновляемых регулярно.
Второе — примеры реальных диалогов. Минимум сотня переписок с клиентами, где видно, как люди формулируют вопросы (спойлер: совсем не так, как вы ожидаете). И третье — типовые возражения с правильными ответами. «Дорого», «подумаю», «а конкурент дешевле» — у вас должны быть эталонные реакции.
Главная ловушка: забыть про обновления. Цены поменялись в октябре, а бот до сих пор называет июньские. Это не баг — это отсутствие процесса.
Анализ звонков: разметка — ваше узкое место
Speech analytics — штука мощная. Автоматически слушать тысячи звонков, находить паттерны успешных переговоров, ловить ошибки. Но есть нюанс: для обучения нужны размеченные данные. А разметка звонков — это ад.
Минимум 200 записей, и не просто записей — а с оценками. Этот звонок хороший, потому что менеджер задал нужные вопросы. Этот плохой — клиент трижды просил перезвонить, а его проигнорировали. Нужен эталонный скрипт, с которым сравнивать. И качественная транскрипция — если ASR превращает «готовы ли вы к следующему шагу» в «готовы ли вы к следующему чагу», анализ теряет смысл.
Совет: начните с 50-100 звонков, размеченных вручную лучшим sales-менеджером. Это больно, долго, но необходимо.
Прогноз продаж: нужна история без разрывов
Forecasting выглядит просто: дай модели историю сделок, она предскажет будущее. На практике всё разбивается о консистентность данных.
Нужно минимум 12 месяцев истории — иначе модель не увидит сезонность. Но не просто «закрытые сделки», а полная картина: когда сделка появилась, как двигалась по стадиям, сколько времени провела на каждой. Плюс внешние факторы: маркетинговые кампании, сезонные всплески.
И вот критический момент: если вы за год дважды меняли структуру воронки — ваши данные несравнимы. Сделка, которая была на стадии «переговоры» в январе, и сделка на «переговорах» в декабре — это могут быть совершенно разные вещи. Модель этого не понимает.
Качество важнее количества (это не банальность)
«У нас 50 тысяч контактов в CRM!» — говорят мне с гордостью. Открываю базу, и через 10 минут гордость испаряется. Потому что 50 тысяч записей с мусором хуже, чем 5 тысяч чистых.
Качество данных — это не абстракция. Это конкретные измеримые штуки, которые можно проверить за час.
Полнота. Берёте ключевые поля и считаете процент пустых значений. В одной компании я видел 60% лидов без указанной отрасли. Как модель научится предсказывать, если не знает, с кем работает?
Точность. Данные соответствуют реальности? Выборочно проверьте 20 записей. Если статус сделки «закрыта успешно», а деньги так и не пришли — у вас проблема не с ИИ, а с дисциплиной заполнения CRM.
Консистентность. Мой любимый кошмар. Выгружаете список уникальных значений поля «отрасль» и видите: «IT», «ИТ», «Айти», «Информационные технологии», «it sector», «software». Для человека это одно и то же. Для модели — шесть разных категорий.
Актуальность. Когда последний раз обновлялись записи? Если половина базы не трогалась больше года — это мёртвые данные. Они не помогут предсказать завтрашние продажи.
Уникальность. Один клиент — пять карточек в CRM. Классика. Дубликаты искажают статистику и путают модель.
Хорошая новость: всё это можно проверить простым скриптом. Плохая новость: после проверки вы, скорее всего, расстроитесь.
Грабли, на которые наступают все
За годы работы с данными для AI-проектов я собрал коллекцию типичных ошибок. Некоторые кажутся очевидными — но совершаются снова и снова.
«Будем собирать всё, потом разберёмся»
Звучит разумно, да? На практике через год у вас терабайт данных и ни одного полезного признака. Потому что собирали не то. Или не так. Или не с той гранулярностью.
Правильный подход: сначала задача, потом данные. «Хотим предсказывать конверсию» → «Какие признаки влияют на конверсию?» → «Настраиваем сбор именно этих признаков». Не наоборот.
Вера в ручной ввод
Менеджеры по продажам — прекрасные люди. Но заполнять CRM-поля — не их любимое занятие. Поэтому «причина отказа» в 80% случаев будет «другое» или «нет бюджета» (второе — универсальное объяснение всего).
Автоматизируйте всё, что можно автоматизировать. Источник лида — из UTM-меток. Размер компании — из LinkedIn API. Время ответа — из логов. Чем меньше ручного ввода, тем лучше данные.
CRM без истории
В типичной CRM вы видите текущее состояние сделки. «Сейчас на стадии переговоров». А когда она туда попала? Сколько дней была на предыдущей стадии? Тайна.
Между тем, время на стадии — один из самых сильных предикторов. Сделка, которая висит на «согласовании» два месяца, скорее всего, умрёт. Включите аудит-лог изменений. Это стоит того.
Только истории успеха
Естественное желание — изучать победы. Но модели нужно знать и как выглядит поражение. Если вы показываете только успешные сделки, модель не научится отличать их от провальных.
Фиксируйте отказы с причинами. «Ушёл к конкуренту», «Заморозили проект», «Не вышли на ЛПР». Это золотая информация.
Машина времени в признаках
Коварная ошибка: использовать в модели данные, которых не было на момент предсказания. Например, предсказываем конверсию лида, а в признаках — «количество проведённых встреч». Но встречи случаются после того, как лид уже квалифицирован!
Модель покажет волшебные 99% accuracy на тесте. А в продакшене — мусор. Потому что у свежего лида ещё нет встреч. Это называется data leakage, и это боль.
«IT» ≠ «ИТ» ≠ «Айти»
Для человека это синонимы. Для модели — три разные категории. Если у вас в поле «отрасль» 200 уникальных значений вместо 15 — это не богатство данных, это бардак.
Решение: справочники с фиксированным списком значений и автоматический маппинг синонимов при импорте.
Заметки вместо данных
«Позвонил, поговорили, вроде интересно, ждём». Отличная заметка для человека. Бесполезная для модели. Что значит «интересно»? Когда «ждём»?
Комбинируйте: структурированные поля (результат звонка, следующий шаг, дата) плюс свободный текст для контекста.
Игнорирование сезонности
Модель обучили на данных января-марта. Запустили в декабре. Удивляемся, почему не работает. А в декабре другое поведение: бюджеты закрываются, люди в отпусках, решения откладываются.
Добавляйте временные признаки: месяц, квартал, день недели. И обязательно тестируйте на данных из разных периодов.
Данные без версий
Обновили датасет, переобучили модель, метрики упали. Что изменилось? Непонятно. Откатиться? Не на что.
Версионируйте данные так же, как код. Git для скриптов, DVC или аналоги для датасетов. Каждый эксперимент — с фиксированной версией.
Как на самом деле начать (пошагово)
Теория — это хорошо. Но давайте к практике. Вот как выглядит нормальный путь от «хотим ИИ» до «ИИ работает».
Сначала — задача, не технология
«Внедрить искусственный интеллект» — это не задача. Это как сказать «внедрить электричество». Задача звучит конкретно: «Предсказывать, какие из входящих лидов станут клиентами в ближайшие 30 дней». Или «Автоматически отвечать на типовые вопросы клиентов 24/7». Или «Находить звонки, где менеджер нарушил скрипт».
От формулировки задачи зависит всё остальное: какие данные собирать, какую модель строить, как измерять успех.
Определите, что предсказываем
Это называется «целевая переменная», и с ней постоянно путаница. Для lead scoring — это простой флаг «купил / не купил». Для чат-бота — пары «вопрос клиента → правильный ответ». Для speech analytics — оценка качества звонка по шкале.
Если вы не можете чётко определить целевую переменную — вы ещё не готовы к ИИ. Возвращайтесь к формулировке задачи.
Соберите список признаков
Признаки — это то, на основе чего модель делает предсказания. Откуда пришёл лид, какая у него должность, сколько времени прошло до первого ответа. Для каждого признака нужно понять: где его взять и как автоматизировать сбор.
Пример: размер компании можно брать из формы заявки (ненадёжно — люди врут), из LinkedIn API (надёжнее, но платно) или обогащать через Clearbit/Apollo (оптимально для B2B). У каждого источника свои плюсы и минусы.
Вытащите историю
Если у вас есть CRM с данными за год-два — это сокровище. Экспортируйте все закрытые сделки: и выигранные, и проигранные. Если есть история изменений стадий — вдвойне хорошо. Связанные события (звонки, письма, встречи) — втройне.
Нет истории? Значит, первый шаг — настроить сбор данных и подождать. Да, это не быстро. Но без данных ИИ не работает — хоть танцуй.
Почистите перед использованием
Сырые данные из CRM — это месиво. Дубликаты, пустые поля, разнобой в названиях. Перед тем как скормить это модели, нужна чистка: удалить дубли, нормализовать категории, решить, что делать с пропусками (заполнить средним? создать отдельный признак «данные отсутствуют»?), проверить баланс классов.
Это скучная работа. Но она определяет 80% успеха.
«А сколько данных-то нужно?»
Самый частый вопрос. И на него нет универсального ответа — но есть ориентиры, от которых можно отталкиваться.
Для lead scoring минимум — 500 лидов с известным исходом, из них хотя бы 50 успешных сделок. Это для MVP, чтобы проверить гипотезу. Для боевой системы нужно 2000+ записей и 200+ won. Главное — не общий объём, а баланс классов.
Для чат-бота важнее покрытие, чем объём. 50 хорошо структурированных документов и 50 примеров реальных диалогов — достаточно для старта. Лучше 50 документов, покрывающих 90% вопросов, чем 500 документов, где нужное не найти.
Для анализа звонков узкое место — разметка. 100 размеченных звонков для MVP, 500+ для продакшена. Разметить 500 звонков — это реально много работы. Закладывайте на это ресурсы.
Для прогноза продаж — минимум год истории, чтобы модель увидела хотя бы один цикл сезонности. Два года лучше — тогда можно проверить, повторяются ли паттерны.
Для предсказания оттока — 200 клиентов для MVP, из них хотя бы 30 ушедших. Отток обычно редкое событие (и это хорошо для бизнеса), но плохо для модели — нужно достаточно примеров обоих классов.
Важный нюанс: эти цифры для классических ML-моделей. Для LLM-решений вроде RAG-ботов важнее качество и покрытие, чем голый объём. Лучше 100 отличных документов, чем 10 000 устаревших.
Где всё это хранить (без оверинжиниринга)
Не нужно строить data lake с первого дня. Для старта достаточно простого стека, который можно развернуть за день.
Структурированные данные (лиды, сделки, события) — PostgreSQL или BigQuery. Если у вас меньше миллиона записей — PostgreSQL хватит с головой. Если больше или нужна аналитика — BigQuery.
Документы для RAG — файлы в S3 или Google Cloud Storage, векторы в Pinecone или Weaviate. Можно начать даже с локальной ChromaDB, если совсем маленький пилот.
Синхронизация из CRM — Airbyte (open source) или Fivetran (платный, но удобный). Настраиваете коннектор к Salesforce/amoCRM/HubSpot — и данные автоматически льются в хранилище.
Версионирование датасетов — DVC (Data Version Control). Работает поверх Git, позволяет откатиться к любой версии данных. Это спасёт вам жизнь, когда что-то сломается.
Общий пайплайн выглядит так: CRM → ETL-инструмент → хранилище → подготовка фичей → обучение модели → API для инференса. Звучит сложно, но каждый шаг — это конкретный инструмент с документацией. Не rocket science.
Про приватность — серьёзно
Данные о клиентах — это персональная информация. И тут не до шуток: GDPR, 152-ФЗ, штрафы — всё это реально.
Несколько вещей, которые нельзя игнорировать. Во-первых, согласие на обработку данных и право на удаление. Если клиент попросит удалить свои данные — вы должны это сделать, включая training data.
Во-вторых, маскирование при обучении. Модели не нужно знать, что Иван Петров из «Рога и копыта» оставил заявку 15 января. Ей нужно знать, что клиент из отрасли X размера Y оставил заявку в период Z. Маскируйте имена, email, телефоны до того, как данные попадут в обучение.
В-третьих, логи. Очень легко случайно писать персональные данные в логи модели. А потом эти логи читает кто угодно. Проверьте, что PII не утекает через дебаг-output.
И retention policy — данные нельзя хранить вечно. Определите сроки и настройте автоматическое удаление.
Быстрая проверка: готовы ли вы к ИИ?
Прежде чем нанимать data scientist-а или покупать AI-платформу, честно ответьте на эти вопросы:
Задача сформулирована конкретно? Не «внедрить ИИ», а «предсказывать конверсию лида с точностью 70%+».
Целевая переменная определена? Вы точно знаете, что предсказываете, и это можно измерить.
Признаки доступны? Данные, которые нужны модели, реально собираются и хранятся.
Объём достаточный? Для вашей задачи хватает исторических данных (см. ориентиры выше).
Классы сбалансированы? Или хотя бы есть понимание, как работать с дисбалансом.
Данные чистые? Дубликаты удалены, категории нормализованы, форматы консистентны.
Ключевые поля заполнены? Хотя бы на 80% — иначе модели не на чем учиться.
Нет data leakage? В признаках только та информация, которая доступна на момент предсказания.
Данные версионируются? Можете откатиться к прошлой версии датасета.
Compliance в порядке? GDPR / 152-ФЗ соблюдаются, PII защищён.
Если набрали 8 из 10 — вперёд, можно экспериментировать. Меньше 6 — сначала разберитесь с данными. Серьёзно, это сэкономит месяцы.
Что почитать дальше
Если тема зацепила, вот несколько статей, которые углубят понимание:
Качество данных в CRM — как построить единый источник правды и перестать тонуть в дубликатах.
Lead Scoring 2.0 — конкретика по построению предиктивной квалификации.
RAG в реальном бизнесе — архитектура чат-ботов на базе документов, метрики качества.
AI для анализа звонков — как выжать максимум из speech analytics.
Хотите разобраться с вашими данными?
Можем посмотреть на вашу CRM-базу свежим взглядом: найти пробелы, оценить готовность к ИИ, составить план действий. Без продаж воздуха — только конкретика.
Обсудить аудит данных