Build in public

Как мы потеряли 14 лидов — и что перестроили после этого

На прошлой неделе я заметил, что новые лиды с сайта перестали приходить мне на почту. Не было ни ошибок, ни алертов, ни жалоб. Просто тишина. Три дня тишины.

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

Как было. Для d8n.ai мы собрали Lead Engine — систему, в которой заявка с сайта сохраняется в CRM, дальше ИИ-агент квалифицирует лид: определяет сегмент, готовит черновик ответа, оценивает готовность к диалогу. И после квалификации отправляет уведомление команде и мне. Логика выглядела стройной: сначала машина разбирается, потом люди подключаются.

Здесь нужна деталь про нашу кухню. Под разные задачи мы используем разные модели: в диалогах с клиентами работают модели Anthropic, а внутренние задачи — скоринг, анализ, обратная связь — мы переводим на собственную LLM, развёрнутую в нашем контуре. Квалификацией лидов тогда занималась модель Anthropic. 16 июля на счету Anthropic закончился баланс: за три дня агенты сожгли 2,4 миллиона входных токенов — про экономику ИИ будет отдельный разбор, там тоже есть чему поучиться. Счёт ушёл в минус на 14 центов, доступ приостановился. ИИ-квалификация остановилась. А вместе с ней — и уведомления о новых клиентах.

Сайт продолжал принимать заявки. CRM исправно их сохраняла. Ни одна заявка не потерялась. Но никто в компании не знал, что они приходят. 14 лидов за три дня лежали в базе, и к ним никто не возвращался. Обнаружила это не система мониторинга. Обнаружил я — по ощущению, что «что-то слишком тихо». Для основателя это худший из способов узнавать о проблеме.

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

Старая цепочка останавливала уведомление при сбое ИИ; новая отправляет уведомление сразу, а ИИ и watchdog работают параллельно

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

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

Краткие выводы — для тех, кто внедряет ИИ в свои процессы:

  1. Критический путь не должен зависеть от ИИ. Ускорение — да, зависимость — нет.
  2. Тишина — не показатель здоровья. Отсутствие ошибок и отсутствие событий выглядят одинаково, пока не построена наблюдаемость.
  3. Если проблему обнаружил основатель, а не система — это не везение, это дыра в системе.
  4. Экономика ИИ — часть архитектуры: лимиты, алерты и учёт токенов проектируются вместе с агентом, а не после первого сюрприза в счёте.

Такие уроки не попадают в пресс-релизы. Но именно из них складывается настоящая ИИ-трансформация — не из красивых демо, а из процессов, которые переживают отказ любого своего компонента. Мы проходим этот путь на собственной компании и будем делиться уроками дальше — без глянца.

Если внедряете ИИ-агентов у себя — напишите мне, на чём споткнулись вы. Самые интересные случаи разберу в следующих выпусках.

ДАЙДЖЕСТ CEO

Читайте новые материалы первыми

Лонгриды сразу после выхода и один недельный дайджест. Подписка подтверждается по email.