Заявки из Директа есть, продаж нет: аудит пути до CRM

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

Результат этого аудита — конкретная карточка дефекта: на каком переходе потеряно обещание или действие, чем это подтверждается, кто исправляет проблему и какой повторный тест докажет исправление. Это инструкция рекламодателю для рынка РФ, а не обзор отчётов Метрики или руководство по сверке статистики. География сохраняется во всех переводах. Официальные источники проверены 25 октября 2026 года; рабочие шаблоны, пороги и оба сценария ниже — редакционная методика, а не требования Яндекса.

Зафиксируйте, что именно перестало работать

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

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

Заранее определите четыре уровня. «Событие» — сигнал аналитики. «Обращение» — запись, действительно полученная бизнесом. «Принятая заявка» соответствует известным на момент обращения условиям и пригодна для работы. «Сохранённая продажа» — выполненный и оплаченный заказ после предусмотренного в примере периода отмен. Отказ от покупки после принятой заявки не превращает её автоматически в некачественную. Для партнёрского вознаграждения действует отдельно согласованное событие.

Если готовите также партнёрский канал, зарегистрируйтесь как рекламодатель AffiliateCore и подготовьте описание предложения с проверенной посадочной. В нашей платформе есть создание черновика оффера с названием, описанием и адресом посадочной. Допуск продукта и источника проверяется отдельно. Сам аудит Директа выполняется в ваших рекламных инструментах и CRM; встроенную синхронизацию этой цепочки мы здесь не обещаем.

Пройдите пять переходов и соберите доказательства

1. Запрос → обещание объявления

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

Составьте три колонки: «чего ожидает посетитель», «что обещано», «что бизнес действительно исполнит». Например, «ремонт сегодня» нельзя подтвердить фразой «мы перезвоним сегодня». Нецелевой запрос требует проверки настройки показа; релевантный запрос при невыполнимом обещании требует изменения предложения. Это разные дефекты, даже если оба заканчиваются отказом менеджера.

2. Объявление → посадочная

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

Яндекс отдельно рекомендует проверять работу сайта с параметром yclid; ошибку при таком URL нужно устранять на сайте. См. справку о Директе и Метрике. В нашем аудите проверьте также конечный адрес после перенаправлений и сохранение контекста услуги. Пропажа метки — повод проверить измерение, но сама по себе не доказательство потери продажи.

3. Форма → полученное обращение

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

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

Для технической проверки Яндекс описывает параметр _ym_debug=2 и панель отладки при новом коде счётчика: проверка цели. Доказательство исправления требует и корректного события, и записи на стороне бизнеса. Не отправляйте телефон, email и текст переписки в диагностические URL или открытый документ аудита.

4. Контакт → ответственный сотрудник

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

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

5. Ответ → предложение → итог

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

Шаблон трассировки: внутренний ID; время и часовой пояс; группа объявления; версия обещания; посадочная; способ контакта; подтверждение получения; владелец; время первого ответа; предложенный следующий шаг; итог; причина; ссылка на доступное доказательство; неизвестные поля. Храните контакты в штатной системе с ограниченным доступом. Для передачи задания разработчику достаточно технического ID и воспроизводимых условий.

Публичный кейс Skillfactory: что считать принятой заявкой

Кейс Skillfactory у Яндекса от 20 февраля 2024 года описывает CRM-проверку с исключением дублей. Квалифицированные заявки не равны продажам; независимая проверка заявления поставщика здесь отсутствует. Yandex.

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

Учебный сценарий 1: срочный ремонт, который нельзя заказать сегодня

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

Материал до исправления: объявление «Мастер сегодня», первый экран без проверки доступности, форма с телефоном, разговор «сегодня мест нет». Материал после: объявление «Ремонт по записи — уточните доступное время», первый экран с тем же смыслом, форма «Уточнить время», разговор «Вы оставили запрос на запись; проверим район, неисправность и ближайшее доступное окно». Обещать срочность можно только там, где её действительно обеспечивают.

Тестовый проход начинается с мобильного адреса объявления. Сотрудник проверяет ошибочную и корректную отправку, затем наличие ровно одной рабочей записи, выбранной услуги и назначенного менеджера. Отдельно проверяется обращение в конце смены. Успех теста — сохранённая карточка с контекстом и понятный следующий шаг; тестовые обращения не оплачиваются и не входят в когорту.

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

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

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

Учебный сценарий 2: бизнес просит расчёт, менеджер продаёт другое

Вымышленный поставщик офисного оборудования в Екатеринбурге привлекает запросы на комплект для небольшого офиса. Объявление и страница предлагают подготовить расчёт по числу рабочих мест. Форма сохраняет телефон и количество мест, но менеджер получает уведомление без этого контекста и начинает с продажи одного устройства. Технически обращения доставлены; сломана передача задачи в обработку.

Шаблон сообщения менеджеру: «Запрос расчёта комплекта; ID; число рабочих мест; выбранная категория; версия посадочной; предпочтительный контакт; ответственный; ближайшее действие». Шаблон первого ответа: «Вы запросили комплект для указанного числа мест. Уточним состав и ограничения, затем согласуем, когда направить расчёт». Поля, которые клиент не предоставил, помечаются как неизвестные, а не заполняются догадками.

Проверка включает две корректные заявки с разными категориями и одну повторную отправку. Менеджер должен увидеть исходный запрос, открыть нужную карточку и назначить следующий шаг. Повтор связывается с прежним обращением по правилам компании. Способ переноса полей выбирает владелец CRM; статья не предполагает конкретный коннектор. Изменение назначения сотрудника проверяют отдельно от изменения текста страницы.

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

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

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

Для отдельного партнёрского предложения войдите в кабинет рекламодателя AffiliateCore и перенесите проверенное описание и URL в черновик своего оффера, если создание доступно вашему аккаунту. Условия приёмки сначала оформите в рабочем брифе. CRM, Директ и сроки ответа остаются вашей операционной ответственностью; эти учебные заказы не объявляются автоматически поддерживаемыми оплачиваемыми событиями платформы.

Рабочий лист передачи заявки в CRM

Скопируйте лист ниже в рабочий документ с ограниченным доступом. Согласуйте окно проверки с владельцем формы и руководителем продаж, используйте разрешённые тестовые контакты вне этого листа и помечайте каждый тест. Сначала заполните договорённость о передаче, затем выполните проверки и приложите обезличенное подтверждение получения или ссылку на запись. При наличии используйте тестовую среду. Сбой доставки моделируйте там либо разбирайте по существующему разрешённому инциденту; не ломайте рабочую интеграцию ради доказательства. Тестовые обращения не должны становиться оплачиваемыми конверсиями или обучать коммерческую цель оптимизации. Лист — редакционный документ, не интеграция AffiliateCore.

Скачать рабочий лист в текстовом формате

ПЕРЕДАЧА ЗАЯВКИ В CRM — РАБОЧАЯ КОПИЯ
Область: РФ / Яндекс Директ; язык не подтверждает доступность.
Не вписывайте имена, контакты, секреты или тексты переписки.

ПУСТОЙ ШАБЛОН ДОГОВОРЁННОСТИ
Маршрут / услуга / версия посадочной: ____
Обещание объявления / допустимые исключения: ____
Тестовая среда / согласованное окно проверки: ____
Код аудита / время получения и часовой пояс: ____
Подтверждение отправки / ссылка на запись CRM: ____
Обязательный контекст / фактически полученные значения: ____
Ответственный / замена / следующая задача / срок: ____
Правило квалификации и его версия: ____
Решение: принято / отклонено / дубль / неизвестно: ____
Причина / доказательство / проверяющий / время решения: ____
Правило дубля / ссылка на исходное обращение: ____
Исход заказа: открыт / потерян / выполнен / отменён: ____
Доказательство исхода / конец наблюдения: ____
Неизвестное / кто проверит: ____
Дефект / версия исправления / доказательство повторного теста: ____
Решение: пройдено / не пройдено / остановка; кто принял: ____

ЗАПОЛНЕННЫЙ УЧЕБНЫЙ ПРИМЕР — ВЫМЫШЛЕН, НЕ РЕЗУЛЬТАТ КЛИЕНТА
Маршрут: комплект офисного оборудования; посадочная версии B.
Код: TEST-B; время: согласованное окно, Europe/Moscow.
Обещание: обсудить полный комплект для рабочих мест.
Обязательный контекст: категория комплекта; канал ответа.
Подтверждение: TEST-RECEIPT-B; запись CRM: TEST-CRM-B.
Наблюдение: категория сохранена, но отсутствует в уведомлении.
Ответственный: руководитель теста продаж; замена: старший смены.
Решение: принятая тестовая заявка; не продажа.
Причина: услуга есть в предложении, получение подтверждено.
Следующая задача: открыть полную карточку и уточнить комплект.
Исход: открыт; доказательств выполнения или отмены нет.
Неизвестное: теряется ли категория в других уведомлениях.
Владелец дефекта: администратор CRM; правка: уведомление C.
Повтор: назначенный сотрудник видит категорию в новой версии.
Решение: до правки не пройдено; после — только с доказанным повтором.

ТЕСТОВЫЕ ОБРАЩЕНИЯ — ОЖИДАЕМЫЙ РЕЗУЛЬТАТ
КОРРЕКТНОЕ: разрешённый запрос предлагаемой услуги.
Ожидаются получение, связанная карточка, контекст, владелец и задача.
ОШИБОЧНОЕ: пропущено обязательное поле.
Ожидается видимая ошибка; принятого бизнес-обращения нет.
ПОВТОР: повторить тот же разрешённый запрос.
Ожидается связь с оригиналом, без второго принятого результата.
ДРУГАЯ ЗАДАЧА: тот же тестовый контакт, иной допустимый запрос.
Ожидается проверка правила дубля, а не автоматическое удаление.
ОТКЛОНЕНИЕ: запрос услуги вне условий предложения.
Ожидается причина по версии условий; доказательство получения сохранено.
НЕТ ОТВЕТА: разбор разрешённого тестового случая без связи.
Ожидается неизвестно/контакт не установлен, а не выдуманное мошенничество.
КОНЕЦ СМЕНЫ: проверка согласованной передачи замене.
Ожидаются ответственная роль, срок и подтверждение приёма.
СБОЙ ДОСТАВКИ: безопасная имитация в тестовой среде.
Ожидаются отсутствие ложного успеха, след для восстановления и владелец.

ЧЕК-ЛИСТ ПРИЁМКИ
[ ] Обещание соответствует реальным возможностям бизнеса.
[ ] Получение доказано отдельно от события аналитики.
[ ] Контекст, ответственный и следующая задача переданы.
[ ] У дублей и отклонений есть причины и доказательства.
[ ] Неизвестные и открытые исходы остаются видимыми.
[ ] Тесты исключены из коммерческих результатов.
[ ] Доказательство повтора относится к исправленной версии.
ПРОЙДЕНО: каждый применимый тест соответствует ожиданию.
НЕ ПРОЙДЕНО: записать расхождение, назначить исправление; не расширять.
СТОП: потеря верной заявки, ложное обещание или нет владельца; остановить затронутый маршрут.
ВОЗОБНОВЛЕНИЕ: записаны исправление, повтор и согласование руководителя продаж.

Оформите исправление и разрешение на следующий пилот

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

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

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

Для соседних задач: анализ источников в Метрике, расхождения статистики и надёжная доставка заявок в CRM. Здесь конечный документ другой: доказанный разрыв конкретной связки и проверяемое разрешение на её повторный запуск.