директор и машина · продажи · запись № 049 · 26 августа 2026 · Давид Герштейн

Лиды, которые отказали семь лет назад: дневник реанимации базы

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные.

В марте у нас случайно всплыла база отказников семилетней давности. Причины отказа стояли в CRM с тех времён: «не готов платить», «не готов разговаривать», «заявка не оставлена». Часть этих людей взяла трубку сейчас — и купила. Не потому что мы гении, а потому что семь лет назад с ними работали менеджеры низкой квалификации, которые не дожали живого клиента. Так родилась идея автоматизации реанимации клиентской базы: не звонить всей истории руками, а сначала прогнать её через ИИ-классификатор.

Дальше мы посчитали, во что это обходится, если так и оставить базу лежать. У нас 15 менеджеров, оборот около 12 млн ₽ в месяц, средний чек — 150 тысяч. Если хотя бы 10% сделок в pipeline зависает без движения дольше нормативного срока — это условно 1,2 млн ₽ в месяц (12 млн × 10%), которые просто стоят и портят статистику. Не теряются безвозвратно, а замораживаются: никто не звонит, никто не закрывает, никто не убирает из воронки. Один такой замороженный контакт нашёлся уже в первую неделю работы — и стал личным уроком для нашего РОПа Саши. Подробности — ниже.

Неделя 0: что решили

Идея простая до банальности: не звонить всей базе руками, а сначала прогнать историю диалогов через модель, чтобы понять — с кем вообще имеет смысл разговаривать и как. Решили тестировать не на активных клиентах (там цена ошибки высокая — можно спугнуть человека, который платит прямо сейчас), а на «паузниках»: тех, кто стоит без движения месяцами и годами. Логика — минимизировать риск на тех, кому терять уже нечего, и только потом масштабировать на живую воронку.

Задача бота на входе: прочитать историю переписки и звонков, определить причину паузы, выбрать тон обращения — и контролируемо, не массово, а пакетами, пинговать. Не «у нас акция, возвращайтесь», а обращение, которое отталкивается от того, почему человек ушёл в тот раз.

Неделя 1: сегментация и находка Саши

Первым делом полезли смотреть воронку целиком — иначе бот классифицировал бы мусор вперемешку с живыми сделками. И почти сразу нашли клиента без движения полтора года. Саша, наш РОП, сначала уверял, что это активная сделка: «моя таблица меня ни разу не подводила, я её помню, там просто долгий цикл». Открыли карточку — последний контакт полтора года назад, ни одного звонка, ни одного письма с тех пор.

Решение — не удалять и не пытаться дожать здесь и сейчас, а вынести такие случаи в отдельную воронку по типу работ. Иначе они искажают среднюю длительность сделки и путают аналитику: система думает, что у нас нормальный цикл — полтора года, хотя на деле это просто забытая карточка.

Саша после этого перестал спорить с дашбордом. Не потому что поверил в ИИ вообще, а потому что конкретно эта сделка была его личной, и он был уверен в обратном. Это тот случай, когда одна найденная ошибка убеждает сильнее десяти презентаций.

Неделя 2: что сломалось

Сломалось не на стороне бота, а на стороне людей. Мы включили контроль вторичных звонков по паузникам — то есть после того как бот определял тон и повод, живой менеджер должен был позвонить в соответствии с этими рекомендациями. Оказалось, что менеджеры вообще не знали, по каким критериям система оценивает их звонки. Критерии были заведены в CRM для оценки ИИ, но их никто не довёл до отдела. В итоге менеджеры звонили «как звонили всегда», а система штрафовала их за несоответствие правилам, о которых они не подозревали.

Пришлось откатиться на шаг назад: сначала свести оценки бота и оценки РОПа вручную на одной и той же пачке звонков, убедиться, что они совпадают хотя бы в половине случаев, и только после этого объявлять отделу правила игры. Запускать контроль до того, как правила прозрачны — гарантированный саботаж.

Параллельно всплыла ещё одна причина, почему база вообще зависла: в мае отдел отвлёкся на побочную задачу (апсейл по стороннему направлению) и вместо плановых 60+ звонков новым контактам сделал 15.

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

Зато повторное касание по 19 тёплым лидам из апреля дало 4 рекомендации от клиентов — это около 21% конверсии повторного касания в рекомендацию, для сравнения: конверсия «первого звонка в никуда» в этой базе была близка к нулю.

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

Неделя 3–4: как выглядит автоматизация реанимации базы целиком

Схема пайплайна, до которой мы дошли к концу месяца:

1. Выгрузка сделок без движения из CRM (по расписанию)
2. Классификация причины паузы и тона — дешёвая модель
3. Фильтр «безопасно для контакта» — только те, кто когда-то отвечал
4. Запись рекомендации в карточку + очередь на звонок менеджеру

Платформа — amoCRM. Триггер — вебхук по смене статуса сделки на «долгая пауза» (мы завели отдельное правило: если 90+ дней без активности — статус меняется автоматически). Обработчик — облачная функция, которая забирает карточку через API, собирает историю переписки и отправляет в модель.

Модель на первом шаге — дешёвая (класса GPT-4o-mini): это массовая пакетная разметка тысяч старых карточек, где важна стабильность и цена, а не креативность. Дорогая модель включается только на следующем шаге — когда нужно сгенерировать персональный текст обращения для уже отфильтрованного, «безопасного» сегмента.

Промпт для первого шага — тот, с которого мы начали и который почти не меняли за месяц:

Ты аналитик отдела продаж. На входе — карточка сделки из amoCRM,
которая находится в статусе "долгая пауза" (90+ дней без активности).

Формат входных данных (JSON):
{
  "lead_id": "строка",
  "days_since_last_activity": число,
  "lost_reason_tag": "строка из CRM (может быть пустой)",
  "amount": число в рублях,
  "product_category": "строка",
  "messages": [
    {"role": "client" | "manager", "text": "строка", "date": "ISO-дата"}
  ]
}

Задача:
1. Определи наиболее вероятную причину паузы: "не готов платить",
   "не готов разговаривать", "заявка не оставлена", "решение отложено",
   "не удалось определить".
2. Проверь, отвечал ли клиент хотя бы раз голосом или текстом
   (не только оставил заявку). Если нет — safe_to_contact = false.
3. Предложи тон обращения: деловой без давления, тёплый неформальный,
   экспертный с кейсом.
4. Дай рекомендуемое следующее действие менеджеру одной фразой.
5. Оцени приоритет: высокий / средний / низкий, исходя из суммы сделки
   и давности последнего контакта.

Верни только JSON без пояснений, строго по схеме:
{"lead_id": "", "pause_reason": "", "confidence": 0.0,
 "tone": "", "recommended_action": "", "priority": "",
 "safe_to_contact": true}

Пример ответа модели на реальной по структуре карточке:

{
  "lead_id": "48213",
  "pause_reason": "не готов платить",
  "confidence": 0.78,
  "tone": "деловой, без давления",
  "recommended_action": "предложить рассрочку и показать кейс похожего заказа",
  "priority": "средний",
  "safe_to_contact": true
}

Инженерная обвязка: обработчик крутится на облачной функции с ежедневным крон-запуском по выгрузке через API amoCRM, плюс отдельный вебхук на ручную смену статуса. Результат классификации пишется в кастомное поле сделки и дублируется в гугл-таблицу для контроля РОПа — так Саша видит очередь на звонок без захода в CRM. Если модель не вернула валидный JSON — два автоматических повтора, при третьей ошибке лид падает в очередь «на ручной разбор», а в Telegram-канал отдела уходит алерт с ID сделки. Расходы на токены мы отслеживаем отдельно — как именно считать реальные счета за ИИ, писал в разборе по своим счетам.

Визуализация: что показала первая пачка

Ниже — то, что было видно на дашборде к концу первого месяца. Это не эффект только от бота: часть цифр — это провал в работе с базой ещё до автоматизации, который и стал поводом её запустить.

Прямая связь между звонком «как обычно» и звонком «по рекомендации бота» пока не измерена отдельно — мы не разносили эти два потока в первый месяц, и это наша методическая ошибка, о которой честно пишу ниже.

Экономика: что это стоит и что дало отдельно от прочих мер

Внедрение здесь не про покупку модели — про часы, которые ушли на выгрузку, разметку и обвязку. По нашей оценке ушло около 25 часов работы аналитика и разработчика суммарно: настройка вебхука, тестовый прогон на 200 карточках, доработка промпта после первых ошибок классификации. При условной ставке 1 500 ₽/час (оценка, для специалиста уровня middle) это порядка 37 500 ₽ разовых затрат на настройку.

Эксплуатация — токены на пакетную классификацию тысяч старых карточек стоят немного: по нашей оценке это единицы тысяч рублей в месяц (берём консервативно 3 000 ₽/мес) при разовой обработке базы такого объёма, дальше — только новые «паузники», которых прибавляется по несколько десятков в месяц.

Вклад бота отдельно от менеджеров — это не деньги в кассе, а сэкономленное время на квалификацию базы. Формула для своего случая: время на карточку вручную × количество карточек × ставка часа менеджера = стоимость ручной квалификации. У нас: 15 минут на карточку × 200 контактов = 3 000 минут = 50 часов; 50 часов × 1 000 ₽/час (оценка ставки менеджера) ≈ 50 000 ₽ ручной работы, которую забрал на себя классификатор за пару дней прогона.

Если сложить это в грубую окупаемость первого месяца: 50 000 ₽ сэкономленного времени на квалификацию минус 37 500 ₽ настройки минус 3 000 ₽ токенов ≈ 9 500 ₽ чистой экономии уже в первый месяц — и это без учёта самих закрытых сделок, только время. С каждым следующим месяцем настройка не повторяется, платить нужно только за токены и время на новые партии карточек, поэтому реальная экономия со второго месяца растёт.

Эффект от самой реактивации нельзя целиком приписать боту — здесь эффект составной. Бот отфильтровал безопасный сегмент и подсказал тон, но разговор и закрытие сделки — целиком работа живого менеджера с опытом. Без A/B-теста (мы его не ставили — см. методическую ошибку выше) честная консервативная раскладка вклада выглядит так: бот дал точный список «с кем можно говорить и как» и снял часы ручного разбора старых карточек — это ускорение и снижение риска спугнуть паузника неудачным тоном, а не сама конверсия в оплату. Решающий разговор, дожим и закрытие 4 сделок на 600 000 ₽ (легенда) — заслуга менеджеров, а не модели. Если бы не бот, эти же 4 сделки, скорее всего, тоже нашлись бы — но позже, ценой ручного прогона всей базы, и с риском, что часть «паузников» получила бы неподходящий тон обращения и окончательно ушла.

Отдельно — риск, который бот снял, а не создал: 1,2 млн ₽/мес зависшего pipeline при 10% сделок без движения (оценка по легенде компании) — это не деньги, которые бот заработал, а деньги, которые перестали быть невидимыми. Дальше их всё равно нужно закрывать руками.

Что осталось нерешённым

Мы прогнали через бота только паузников старше 90 дней с суммой сделки выше среднего чека — то есть меньшую часть базы. Остальное ждёт: часть контактов вообще не сохранила читаемую историю переписки, и классификатору там нечего анализировать. Отдельно не решён вопрос со скорингом и распределением реактивированных лидов под конкретного менеджера — по опыту, если отдать их первому свободному, а не тому, кто умеет закрывать сложные случаи, конверсия провалится так же, как семь лет назад. Это следующий шаг, и пока это ручная работа Саши.

Похожая проблема с квалификацией отказников без прозрачных критериев разбиралась ещё в одной статье — если у вас в отделе тоже штрафуют менеджеров за невыполнение правил, о которых те не знают, там есть разбор, как навести порядок без репрессий: внедрение контроля звонков без саботажа.

Чек-лист: с чего начать в понедельник

• Выгрузить из CRM все сделки без движения дольше 90 дней и отдельно — дольше года.
• Вынести долгожителей в отдельную воронку по типу работ, чтобы не портили аналитику по срокам.
• Прогнать первые 100–200 контактов через классификатор причины паузы на дешёвой модели, не масштабируя сразу на всю базу.
• Посчитать свою окупаемость по формуле: часы настройки × ваша ставка + токены — против часов ручной квалификации × ставка менеджера на то же количество карточек.
• Согласовать с РОПом единые критерии вторичного звонка до включения бота в работу отдела.
• Настроить лог ошибок и алерт в Telegram на случай сбоя классификации или пустого ответа модели.
• Тестировать только на «паузниках» минимум месяц, прежде чем трогать активную воронку.

Кстати, если после запуска подобной автоматизации выясняется, что без ручного контроля она перестаёт работать через пару недель — это не редкость, а типовой сценарий, разобранный в статье про автоматизацию, требующую надзора.

Частые вопросы

Сколько стоит автоматизация реанимации клиентской базы под ключ?

Основная статья расходов — не модель, а часы аналитика на выгрузку, разметку и обвязку: по нашей оценке это 20–30 часов работы на старте, дальше эксплуатация — токены на классификацию, обычно единицы тысяч рублей в месяц при базе в несколько тысяч контактов.

Можно ли реактивировать лидов, которые отказали 5–7 лет назад?

Да, если они хоть раз брали трубку и разговаривали — у них есть история диалога, по которой можно определить причину паузы и тон. Лидов, которые вообще не оставили контакт, реактивировать нечем.

С чего начать реанимацию базы, если она не в CRM, а в Excel?

Сначала перенести хотя бы минимальный набор полей — дата последнего контакта, причина отказа, сумма сделки — в таблицу с уникальным ID, и уже на неё натравливать классификатор через Google Sheets API, без ожидания полной миграции в CRM.

#автоматизация #ии и нейросети #аналитика и отчётность