Заявка не дошла до CRM: как за 20 минут найти, где она потерялась

Форма на лендинге отправилась, человек увидел «спасибо», а в CRM пусто. Оплата прошла, деньги на счёте, доступ к курсу не выдался. Заявок за понедельник пришло вдвое меньше обычного, но никто не жаловался - просто цифра в отчёте стала меньше.

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

Ниже - рабочий протокол поиска: карта маршрута заявки, как устроена передача через правила в Vakas-tools (Вакас-тулз), семь точек отказа по частоте и что сделать, чтобы в следующий раз искать не пришлось.

Первое правило: не чинить, а локализовать

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

Проблема даже не в потерянном времени. Когда меняешь несколько вещей сразу, теряется причинно-следственная связь: непонятно, что именно починило, а значит, невозможно ни описать поломку, ни предотвратить её повторение.

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

Работает это как поиск делением пополам. Маршрут заявки состоит из пяти-шести звеньев. Проверять их по очереди с начала - долго. Быстрее проверить середину: если данные до середины дошли - проблема во второй половине маршрута, если нет - в первой. Два-три таких шага, и остаётся одно звено. Именно поэтому двадцать минут - реалистичный срок, а не фигура речи.

Карта маршрута: из чего состоит путь заявки

Прежде чем искать, нужно понимать, что именно искать. Маршрут типовой заявки в онлайн-школе почти всегда раскладывается на шесть звеньев.

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

Отсюда практический вывод: искать нужно там, где эти переходы записаны. В Vakas-tools (Вакас-тулз) это раздел «История событий» - и в нём три вкладки, которые закрывают три разных вопроса:

1. Журнал событий - что произошло с каждой заявкой: ID, время, правило, сервис, условия, событие и статус «Успешно» или «Ошибка»;
2. Текущие очереди - сколько заявок прямо сейчас ждут отправки, отдельно по заказам, отчётам, регистрациям и запросам в amoCRM;
3. Управление запросами - необработанные запросы и история успешных отправок.

Как устроена передача: правило → условия → действия

Дальше вся диагностика опирается на одну и ту же конструкцию, поэтому разберём её отдельно. Передача данных в подключённый сервис настраивается правилами, и устройство у них одинаковое для amoCRM, Bitrix24, GetCourse, SaleBot, BotHelp и остальных.

Открываете базу, нажимаете на нужный сервис - и попадаете на страницу с вкладками «Регистрации», «Отчёты», «Заказы» и «Сводка». У каждой свой список правил, и правила одной вкладки не влияют на другие. Настроили передачу заказов - регистрации от этого передаваться не начнут.

Каждое правило состоит из трёх частей, и на каждой из них диагностика может закончиться:

1. Галочка «Правило активно» - выключенное правило сохраняется со всеми настройками, но не срабатывает.
2. «Порядок» - число, по которому правила проверяются от меньшего к большему.
3. «После выполнения не выполнять другие правила» - тот самый флаг «Стоп»: если он включён, правила ниже по списку пропускаются.
4. «Название» - единственное, что через полгода объяснит, зачем это правило вообще создавали.

Как работают Условия. Фильтр из трёх частей: поле, оператор и значение. Набор операторов подстраивается под поле: у текстовых это «равно», «не равно», «содержит», «не содержит», «заполнено», «не заполнено», у числовых - сравнения >, <, =, !=, >=, <=. Условий может быть несколько, и работают они по «И» - правило сработает, только если выполнены все сразу. Правило без условий срабатывает для каждого события на своей вкладке.

Как работают Действия. То, что происходит в сервисе, когда правило сработало: создать или обновить сделку, записать значения в доп. поля, перевести на другой этап, добавить теги, поставить задачу менеджеру. Набор действий зависит от сервиса - у amoCRM это сделки и каталоги, у GetCourse пользователи, группы и заказы.

Здесь же живёт правило, которое стоит запомнить до того, как начнутся сбои: если событие подошло под несколько правил, выполнятся действия каждого из них, а поля последнего сработавшего перезапишут значения предыдущих. Это удобно (одно правило создаёт сделку всем, второе переносит горячих на отдельный этап) и это же - источник самых непонятных на вид поломок.

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

Семь точек отказа, отсортированных по частоте

За годы работы с чужими и своими связками список повторяющихся поломок оказывается на удивление коротким. Вот он - в том порядке, в каком стоит проверять.

1. Источник не отправил.
   Человек увидел «спасибо», но запрос никуда не ушёл. Причины: форма показывает благодарность до фактической отправки, не прошла валидация скрытого поля, блокировщик рекламы вырезал скрипт, капча отклонила отправку молча. Отдельная классика - правку на лендинге вносил не техспец: дизайнер пересобрал блок с формой, и настройки отправки уехали вместе со старым блоком. В Журнале событий при этом пусто: события просто не было.
2. Отправил, но не туда.
   Запрос ушёл на старый адрес: связку пересобрали, ссылка приёма изменилась, а в источнике осталась прежняя. Сюда же - тестовая база вместо боевой, HTTP вместо HTTPS, редирект, при котором тело запроса теряется. Снаружи выглядит идентично полной тишине, поэтому пункты 1 и 2 всегда проверяются вместе.
3. Событие есть, но данные не те.
   Контакт в базе появился, а нужных полей в нём нет: сервис-источник обновил формат, поле переименовали, значение пришло пустым. Дальше по цепочке это выглядит как «передалось, но пусто» — например, сделка создалась без источника или без суммы.
4. Правило выключено - или его нет.
   Пункт, на котором теряют больше всего времени, потому что он не выглядит как поломка. В списке правил есть колонка «Статус»: у выключенного правила стоит «выкл», и оно молча не срабатывает, сохраняя все настройки. Второй вариант того же - правил на вкладке нет вообще: передачу заказов настроили, а на вкладку «Регистрации» никто не заходил. Третий, самый коварный: правила есть, все с условиями, и событие не подошло ни под одно - тогда оно не передаётся никуда. Именно поэтому имеет смысл держать хотя бы одно правило без условий: оно ловит всё, что не попало в остальные. Проверять это нужно раньше, чем поля и действия: пять секунд против получаса.
5. Условия не пропустили событие или его перехватило другое правило.
   Данные есть, правило активно, но фильтр не совпал. Условие по сумме заказа отсекает бесплатные регистрации. Условие по названию тарифа перестаёт совпадать в тот день, когда маркетолог тариф переименовал. Здесь помогает колонка «Условия» в списке правил: видно, у какого правила «Без условий», а у какого фильтр, и какой именно. И отдельно проверьте флаг «Стоп» у правил с меньшим порядком: если событие подошло под правило с этим флагом, все правила ниже не выполнятся — на вид это выглядит как «правило настроено, но не работает».
6. Сервис-получатель отклонил данные.
   Статус события - «Ошибка», а если раскрыть событие плюсом, видно три вещи: метод, отправленные данные и ответ (а под ним - ссылка «Показать полный ответ»). Именно ответ и содержит диагноз. Самый частый - истёкший доступ: Ошибка amoCRM [Общая ошибка авторизации. Неправильный логин или пароль.]. Лечится переподключением сервиса, а не перенастройкой полей. Второй по частоте - «сервис не знает о поле»: в CRM создали новые поля, воронку или добавили менеджера, а подключение о них ещё не в курсе. Лечит это кнопка «Обновить поля и воронки» на странице правил с последующей перезагрузкой страницы; там же рядом есть меню создания типовых полей - UTM, поля отчётов и поля оплат создаются одним нажатием и без дублей.
7. Всё дошло, но не видно.
   Статус «Успешно», а найти сделку не получается. Она создалась в другой воронке. Или осталась на прежнем этапе: в действии «Сделка» есть настройка «Не перемещать если сделка на этапах», и указанные там этапы становятся неприкасаемыми - что правильно для оплаченных сделок и неожиданно для всех остальных. Или этап переопределило отдельное действие «Изменить этап», у которого приоритет выше, чем у этапа в действии «Сделка». Или у сделки нет ответственного, и поэтому она не попала в рабочий список менеджера. Или всё в порядке, но смотрят не в том аккаунте. Прежде чем разбирать интеграцию, потратьте минуту и поищите заявку глобальным поиском по номеру телефона с выключенными фильтрами.

Отдельный случай: заявка не потеряна, а стоит в очереди

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

Отправка в подключённые сервисы идёт очередями, и у них есть приоритет: сначала запросы на получение данных из amoCRM, затем заказы и оплаты, затем отчёты, и только потом регистрации. Логика понятная - деньги вперёд. Но следствие такое: если приёмник полчаса не отвечал и очередь набухла, свежая регистрация уедет последней.

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

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

Там же прячется объяснение всплесков «сервис отвечает ошибкой лимита»: такая ошибка почти никогда не приходит одна. Сервис полежал, очередь накопилась, потом всё выстрелило залпом - и принимающая сторона начала отбивать запросы. Диагностика по одному событию тут врёт, смотреть надо на соседние.

Разбор конкретных связок с полями и ответами есть в отдельных материалах блога - например, по передаче заявок с Tilda в GetCourse и по оплатам из Prodamus в amoCRM со статусами и дублями.

Протокол на двадцать минут

Теперь всё вместе, по шагам и с таймингом. Смысл жёсткого регламента не в скорости ради скорости, а в том, чтобы не сорваться в хаотичное перещёлкивание настроек.

Минуты 0–3.

Воспроизвести с меткой. Оставить собственную тестовую заявку так, чтобы её потом можно было найти одним поиском: имя «Тест 14:35», уникальный адрес почты (во многих почтовых сервисах работает приём имя+test1435@домен - письма придут в тот же ящик), номер телефона, которого точно нет в базе. Без метки следующие пятнадцать минут уйдут на то, чтобы отличить свою заявку от чужих. Если воспроизвести не удаётся и сбой был разовым - это уже полезный результат: значит, разбирать нужно не настройки, а конкретное событие в журнале, и, скорее всего, речь о временном отказе одной из сторон.

Минуты 3–5.

Исключить очередь и выключенное правило. Две проверки, которые дешевле всех остальных: счётчики на вкладке «Текущие очереди» и колонка «Статус» в списке правил нужной вкладки. Если очередь пустая, а правило активно — идём дальше.

Минуты 5–9.

Проверить середину маршрута. Открыть Журнал событий, отфильтровать по нужной базе, статусу и периоду (галочку «учитывать» у периода легко забыть) и найти свой тест. Появилось событие или нет - это главная развилка всей диагностики, она отсекает половину гипотез.

Минуты 9–13, если событие есть.

Смотреть по колонкам: какое правило сработало, что показала колонка «Условия», какой статус. Дальше раскрыть детали: метод, данные, ответ. Как правило, точка отказа звучит здесь конкретно: «не выполнилось условие по тарифу», «CRM ответила ошибкой авторизации», «поле не найдено».

Минуты 9–13, если события нет.

Идти в источник: журнал отправки формы или платёжной системы, актуальность адреса приёма, живой ли доступ. Проверить, не менялся ли лендинг за последние дни, - это первый вопрос команде.

Минуты 13–16.

Одна гипотеза - одно изменение. Не два. Не «заодно поправлю ещё вот это». Одна правка - один повторный тест. Если гипотеза не подтвердилась, откатить правку, прежде чем пробовать следующую.

Минуты 16–20.

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

Мини-кейс: заявки «перестали приходить», хотя приходили все

В одном из проектов, которые я вёл, команда пришла с формулировкой «второй день не приходят заявки от повторных обращений». В журнале при этом было видно: события приходят, правило срабатывает, статус «Успешно» - и новых сделок нет.

Дело было в поиске дублей. Настройка работала штатно: система находила существующий контакт по email и работала с ним, а не создавала новый. Правильное поведение - ровно то, ради чего дубли и проверяют. Но те же люди проходили через воронку полгода назад, и их обращения аккуратно приземлялись в старые сделки, которых никто не ждал в работе.

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

Вывод, который я с тех пор проверяю первым: если событие видно в журнале со статусом «Успешно», а в CRM ничего нового нет, проблема почти никогда не в передаче. Она в логике, которую настроили под прошлую реальность.

Дубли - вторая половина той же проблемы

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

Первое, что стоит понять про эту настройку: она про сделки, а не про контакты. Контакт ищется всегда - по email, потом по телефону, потом по указанному доп. полю - и при повторном обращении обновляется. А выбор из двух вариантов - «искать существующую сделку и обновлять её» или «всегда создавать новую сделку» - решает, попадёт свежее обращение в старую сделку или начнёт отдельную. Первый вариант при слишком широком поиске схлопывает разные обращения в одно (кейс выше). Второй плодит сделки: менеджеры звонят одному человеку по три раза, а статистика превращается в вымысел.

Что стоит осознанно решить в этом блоке:

1. Чем добираем контакт. Email и телефон - база, но человек оставляет заявки с разных почт. «Доп. поле контакта для поиска» вроде Telegram ID закрывает эту дыру;
2. Что считаем одной сделкой. Здесь и живёт контекст: «Доп. поле сделки для поиска» с идентификатором вебинара или запуска отделяет новое обращение от прошлогоднего. Без него свежая заявка приземляется в старую сделку;
3. Где ищем. «Искать только в воронках» разводит продукты, чтобы они не перемешивались, а переключатели поиска в «Успешно реализовано» и «Закрыто и не реализовано» решают, поднимать ли закрытые сделки обратно в работу;
4. Что делаем с контактными данными. «Добавлять дополнительные email/телефон в найденный контакт» дописывает новые данные, а не затирает старые.

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

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

Чтобы в следующий раз не искать вовсе

Диагностика.

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

Сквозной идентификатор.

У заявки должен быть один опознавательный признак, который живёт по всему маршруту: телефон в едином формате, идентификатор заказа, идентификатор запуска. Если на каждом звене человек называется по-своему, диагностика превращается в сверку вручную.

Понятные названия правил.

Поле «Название» кажется формальностью, пока список правил не дорастёт до десятка строк с именами «1», «2», «3». Через полгода - а тем более при передаче проекта другому техспецу - разбор начинается с вопроса «а это правило вообще зачем?». «Все регистрации», «Был больше 60 минут», «Оплата от 5000» экономят те самые двадцать минут. И если правило создавалось Мастером настройки, дать ему осмысленное имя стоит сразу: мастер соберёт действия за вас, но смысл в название не впишет.

Журнал, который ведётся сам.

Не «отправлено», а полная запись: событие, правило, условия, сервис, статус, метод, данные, ответ. В Vakas-tools (Вакас-тулз) это пишется по умолчанию - вместе с возможностью переотправить неудавшиеся события пачкой. Это, пожалуй, главный практический аргумент собирать связки в одном месте, а не размазывать по встроенным интеграциям пяти сервисов: чинить можно там же, где смотришь.

Привычка смотреть на ошибки, а не только на заявки.

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

Уведомление о том, что кончается. Самая обидная поломка - не ошибка, а исчерпанный баланс SMS, звонков или email-рассылки: формально всё исправно, просто сообщения перестали уходить. В разделе «Проверка балансов» настраиваются уведомления о низком балансе подключённых сервисов - десять минут работы, и целый класс сбоев закрыт.

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

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

Задача техспеца - не в том, чтобы такого никогда не случалось. А в том, чтобы в момент, когда случилось, ответ на вопрос «где именно?» занимал двадцать минут и находился в журнале, а не в догадках.

Если хочется проверить свою связку прямо сейчас - оставьте тестовую заявку с меткой и пройдите её маршрут целиком, от формы до сделки с источником, сверяясь с Журналом событий. Двадцать минут, а список того, что нужно починить, часто оказывается длиннее ожидаемого.