Факапы автоматизации: почему тесты на идеальных данных ломают реальную воронку заявок - Блог Папы Карло

Привет. Тут история старая, как мой верстак: на тесте всё летает, а на бою воронка заявок начинает чудить. Причина обычно не в “кривой кнопке”, а в том, что мы проверяли сценарий на стерильных лидах: один канал, один webhook, ровный телефон, заполненные поля, менеджер ничего руками не трогает. В жизни прилетает каша: дубли, пустые поля, повторы доставки, разный формат номера, задержки по API, ручные правки в CRM. Ниже покажу, где именно это рвёт автоматизацию, какие кейсы я гоняю перед запуском и какой чек-лист держу рядом, чтобы заявки не терялись, не дублировались и не зависали между этапами.

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

Когда собираешь автоматизацию заявок, рука сама тянется к “красивому” тесту. Берём одну форму, вбиваем имя, телефон, почту, жмём отправку, смотрим: лид создался, менеджер назначился, уведомление ушло, в таблице строка появилась. Красота. Но это проверка на уровне демки, а не боевого процесса.

Идеальные тестовые данные почти никогда не отражают то, что реально прилетает в CRM. На бою люди пишут номер через восьмёрку, через плюс, через пробелы, с доб. номером, с опечаткой в почте, с пустым UTM, с кривым названием услуги, с двумя отправками подряд, потому что кнопка “Отправить” не мигнула мгновенно. Плюс сами источники событий тоже живут своей жизнью: webhook могут прислать повторно, обновление статуса может приехать раньше создания карточки, а API партнёрского сервиса может ответить не сразу.

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

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

Где реальная воронка ломается чаще всего

Я обычно вижу пять точек поломки. Они не самые гламурные, зато встречаются постоянно.

1. Дедупликация сделана “на авось”

Если ты ищешь дубль только по одному полю, например по телефону в том виде, как он пришёл, жди сюрпризов. Один и тот же человек может оставить номер как +7 999 123-45-67, 8 999 1234567 и 89991234567. Для человека это один клиент. Для сырой автоматизации это три разных лида. Я сперва нормализую контактные данные, потом уже сравниваю, и только после этого создаю карточку.

Ещё один частый прикол — дедупликация срабатывает уже после создания записи. Итог: заявка успела попасть в CRM, триггеры запустились, уведомления улетели, менеджер схватил задачу, а система потом такая: “О, это дубль”. Лучше сначала проверка на уникальность, потом запись, потом уже вся мишура вокруг.

2. Сценарий не держит повторные события

Многие вебхуки и API живут по принципу at least once: если система сомневается, дошло событие или нет, она пришлёт его ещё раз. На бумаге это звучит логично. На практике webhook дублирует заявку, создаёт второй лид, а иногда и вторую сделку. Тут и нужен idempotency-подход: у каждого входящего события должен быть понятный ключ, по которому ты видишь, обрабатывал его или нет. У меня это железное правило для всего, что связано с лидами, оплатами, заявками на запись и повторными уведомлениями.

3. Пустые и “грязные” поля ломают маршрутизацию

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

4. Менеджер руками трогает карточку, и логика едет боком

Автоматизацию часто рисуют так, будто люди вообще не вмешиваются. Но в живой воронке менеджер меняет владельца, двигает стадию, редактирует комментарий, закрывает задачу раньше времени, откатывает статус назад. Если workflow на это не рассчитан, начинается цирк: переназначение, повторные напоминания, бесконечные обновления одной записи. Особенно весело, когда изменение поля снова включает тот же сценарий, и он гоняет карточку по кругу.

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

5. На тесте одна заявка, на бою прилетает пачка

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

Отсюда и вывод: тест одной заявки — это проверка на наличие жизни. Тест пачки заявок — это уже разговор про устойчивость.

Как я тестирую автоматизацию перед выкладкой

У меня тут подход ремесленный: не верю красивому прогону, пока не прогнал сценарий на кривых кейсах. В n8n, например, удобно работать с mock-данными и pinned data во время сборки, но на бою эти костыли не участвуют. Поэтому одной ручной проверки в редакторе мне никогда не хватает.

1. Собираю набор грязных тестовых лидов. В нём всегда есть разные форматы телефонов, пустые поля, дубль почты, дубль номера, лид с задержкой по событию, лид с неизвестной услугой и лид, который приходит дважды с одинаковым внешним ID.

2. Гоняю сценарий на ручном запуске, чтобы увидеть, где криво мапятся поля и на каких ветках условие думает не то.

3. Потом беру реальный сбойный кейс из логов и прогоняю его повторно. Это сильно полезнее, чем придумывать “идеальный” пример из головы.

4. Отдельно тестирую автоматический запуск, а не только редактор. Некоторые штуки, вроде обработки ошибок и реальных retry-сценариев, на ручной прогон не похожи вообще.

5. Проверяю порядок действий: сначала дедупликация и нормализация, потом создание записи, потом уведомления, задачи, отчёты и вся остальная красота.

6. Запускаю пачку заявок подряд, чтобы поймать гонки условий и проблемы при одновременной обработке.

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

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

Чек-лист перед запуском

• Все телефоны и email приводятся к одному формату до поиска дублей.

• Есть внешний ID события или свой ключ идемпотентности.

• Повторная доставка webhook не создаёт новую заявку.

• Пустые поля уводят лид в понятную ветку, а не в туман.

• Ручная правка менеджера не запускает цикл повторно.

• У каждой автоматической задачи есть понятный создатель и статус.

• Сохранены логи успешных и проваленных прогонов.

• Есть уведомление о сбое, а не надежда на удачу.

• Тестировалась пачка лидов, а не только один “образцовый” контакт.

• Есть понятный маршрут для лидов с неизвестным источником и спорными данными.

Когда автоматизация уже выросла в цепочку “заявка → расписание → напоминание → отчёт”, очень полезно держать рядом кейсы, похожие на связку заявки, расписания и напоминаний. Такие сценарии ломаются не в одном месте, а по стыкам между этапами.

Что смотреть уже после запуска

Запуск — это не финал, а начало нормальной проверки. Я после выкладки всегда смотрю не только на ошибки выполнения, но и на бизнес-сигналы. Потому что workflow может отработать “успешно”, а воронка при этом уже поплыла.

• Сколько входящих заявок пришло и сколько карточек реально создалось.

• Сколько лидов ушло в дедупликацию и сколько попало в ручной разбор.

• Есть ли скачок по задачам и уведомлениям на одного лида.

• Сколько заявок зависло между стадиями больше обычного.

• Совпадает ли первый владелец лида с тем, кого должна была назначить логика.

• Не поехала ли аналитика по источникам после новой интеграции.

Если метрики смотреть лень, потом дорого выходит. Я в таких случаях вижу один и тот же сюжет: команда чинит “ошибку в боте”, а проблема вообще не там. На деле съехал маппинг полей, дедупликация пропускает похожие номера, а повторная доставка события плодит хвосты в CRM.

Что в итоге

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

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