Заявки з Директа є, продажів немає: аудит шляху до CRM

Коли Директ приносить заявки, а відділ продажів не отримує замовлень, порада «змінити аудиторію» передчасна. Людина могла побачити обіцянку термінового виїзду, потрапити на сторінку з іншою послугою, залишити телефон і почути від менеджера зовсім інші умови. Кожен окремий інструмент при цьому працює: оголошення показується, форма надсилається, CRM створює картку. Не працює узгодженість шляху.

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

Зафіксуйте, що саме перестало працювати

Оберіть одну зв’язку: конкретна група оголошень, послуга, місто, посадкова сторінка та спосіб контакту. Для першого проходу зручні пошукові звернення зі зрозумілим наміром. Не змішуйте їх із рекламною мережею Яндекса, повторними клієнтами та іншими послугами: вони мають інший контекст. Візьміть завершений період зі сталими умовами пропозиції та запишіть дату закінчення спостереження. Тривала угода, що ще перебуває в роботі, не дорівнює відмові.

Потрібні доступ до оголошень та їхніх адрес, звіти Директа й Метрики, перевірка форми розробником, знеособлена історія CRM і відповідальний керівник продажів. Збережіть версії тексту оголошення, першого екрана, форми та сценарію першої розмови. Також потрібні години роботи, фактична зона обслуговування, наявність товарів або вільних фахівців. Якщо історії версій немає, поточна сторінка не доводить, що бачив учорашній клієнт: позначте це обмеження.

Заздалегідь визначте чотири рівні. «Подія» — сигнал аналітики. «Звернення» — запис, який справді отримав бізнес. «Прийнята заявка» відповідає умовам, чинним на момент звернення, та придатна до роботи. «Збережений продаж» — виконане й оплачене замовлення після передбаченого в прикладі періоду скасувань. Відмова від купівлі після прийняття заявки не робить її автоматично неякісною. Для партнерської винагороди діє окремо погоджена подія.

Якщо готуєте також партнерський канал, зареєструйтеся як рекламодавець AffiliateCore та підготуйте опис пропозиції з перевіреною посадковою сторінкою. У нашій платформі є створення чернетки офера з назвою, описом і адресою сторінки. Допустимість продукту та джерела перевіряється окремо. Сам аудит Директа відбувається у ваших рекламних інструментах і CRM; вбудовану синхронізацію цього ланцюжка ми тут не обіцяємо.

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

1. Запит → обіцянка оголошення

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

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

2. Оголошення → посадкова сторінка

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

Яндекс радить перевіряти роботу URL із параметром yclid і виправляти спричинені ним помилки сайту: довідка про Директ і Метрику. У цьому аудиті перевірте також кінцеву адресу після перенаправлень і збереження контексту послуги. Втрата мітки — привід дослідити вимірювання, але сама собою не доводить втрату продажу.

3. Форма → отримане звернення

Ціль надсилання форми може враховувати невдалу спробу; це описує довідка Метрики. Тому окремо перевірте порожню форму, помилковий номер, правильне надсилання та повторне натискання. Для кожного тесту позначте видиму відповідь, отримання бізнесом і появу картки. Повідомлення подяки не замінює підтвердження збереження.

Метрика підтримує передавання цільових подій методом reachGoal: офіційний опис. Наша рекомендація — доручити розробнику прив’язати потрібну подію до підтвердженого збереження звернення, а не просто натискання. Це налаштування вашого сайту, не універсальне виправлення одним прапорцем. Тестові записи позначайте та виключайте з комерційних результатів.

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

4. Контакт → відповідальний працівник

Клік на телефон не доводить розмову. Передавання відомостей про дзвінки до Метрики потребує окремого колтрекінгу: офіційна довідка. Якщо його немає, використовуйте доступний журнал телефонії та чесно залишайте невідомим зв’язок із конкретним рекламним візитом. Для форми перевірте час отримання, призначення працівника та першої змістовної відповіді.

З’ясуйте, хто приймає звернення наприкінці зміни, за відсутності основного менеджера та коли обрано рідкісну послугу. Повідомлення в загальному чаті не дорівнює призначеному відповідальному. Простежте кілька записів: чи бачить працівник обіцяні умови, потрібну послугу та бажаний спосіб зв’язку? Відсутність відповіді клієнта не доводить помилковий телефон або поганий трафік.

5. Відповідь → пропозиція → підсумок

Порівняйте першу розмову з рекламою. Чи запропоновано обіцяну дію, чи пояснено вартість до погодження, чи визначено наступний крок? Для кожного втраченого продажу оберіть доказову причину: немає вільного часу, інша послуга, невідповідна пропозиція, відмова клієнта або невідомо. Не замінюйте невідоме зручною категорією «нецільовий».

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

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

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

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

Навчальний сценарій 1: терміновий ремонт, недоступний сьогодні

Вигадана сервісна компанія в Казані ремонтує побутову техніку. Оголошення обіцяє виїзд сьогодні, сторінка пропонує залишити заявку на ремонт, а фактично найближчий час є лише за кілька днів. Обрано одну пошукову групу та послугу. Збір триває сім днів, спостереження — до 21-го дня від початку; всі записи прикладу на цей момент закриті. Це не реальні результати клієнта й не універсальна рекомендація строку.

До виправлення: оголошення «Майстер сьогодні», перший екран без перевірки доступності, форма з телефоном і відповідь «сьогодні місць немає». Після: «Ремонт за записом — уточніть доступний час», відповідний перший екран, форма «Уточнити час» і розмова «Ви залишили запит на запис; перевіримо район, несправність і найближче вільне вікно». Терміновість можна обіцяти лише там, де її справді забезпечують.

Тестовий прохід починається з мобільної адреси оголошення. Працівник перевіряє помилкове та правильне надсилання, потім рівно один робочий запис, обрану послугу та призначеного менеджера. Окремо тестується звернення наприкінці зміни. Успіх — збережена картка з контекстом і зрозумілий наступний крок. Тестові звернення не оплачуються та не входять до комерційної когорти.

У навчальному журналі розділіть повторні звернення щодо того самого ремонту, запити іншої послуги, відсутність контакту та прийняті заявки. Повтор пов’яжіть з оригіналом, не стираючи історію. Клієнт, якому не підходить запропонований час, усе ще міг подати якісну заявку. Виконане замовлення та його подальше скасування фіксуйте окремо: прийнята заявка не повинна зникати з історії через невдалий продаж.

Доказ збою — збережена обіцянка виїзду сьогодні та дозволена нотатка, що підтверджує відсутність часу. Не виводьте причину з падіння графіка конверсії. Відмову з іншої причини не включайте до цієї групи. Виправте обіцянку та розмову про час, потім за робочим аркушем перевірте, чи бачить призначений працівник початкову задачу.

Зупиніть уражений маршрут за нездійсненної обіцянки або втрати правильного надсилання. Після виправлення повторіть його на комп’ютері й телефоні, включно з передаванням наприкінці зміни. Продовжуйте обмежений пілот лише після успішної перевірки обіцянки, отримання та призначення, якщо команда може виконати пропоновані записи. Відкриті замовлення залишаються в очікуванні до погодженої межі спостереження. Технічний успіх не доводить зростання продажів.

Навчальний сценарій 2: бізнес просить розрахунок, менеджер продає інше

Вигаданий постачальник офісного обладнання в Єкатеринбурзі залучає запити на комплект для невеликого офісу. Оголошення та сторінка пропонують розрахунок за кількістю робочих місць. Форма зберігає телефон і кількість, але менеджер отримує повідомлення без цього контексту та починає продавати один пристрій. Технічно звернення доставлено; зламана передача задачі в обробку.

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

Перевірка включає дві правильні заявки з різними категоріями та одне повторне надсилання. Менеджер має побачити вихідний запит, відкрити потрібну картку й визначити наступний крок. Повтор пов’язують із попереднім зверненням за правилами компанії. Спосіб перенесення полів обирає відповідальний за CRM; конкретний конектор не передбачається. Зміну призначення працівника перевіряють окремо від зміни тексту сторінки.

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

Спочатку керівник порівнює текст форми, вміст картки та першу пропозицію. Якщо кількість місць є в CRM, але працівник її не використав, проблема в обробці. Якщо поля немає вже у збереженому зверненні, задачу повертають відповідальному за форму. Це визначає виправлення: навчання та відповідальність або відновлення передавання поля.

Зупиніть уражений маршрут, якщо працівник не бачить обов’язкового контексту або ніхто не приймає відповідальність. Після правки перевірте різні категорії, повтор запиту та призначення заміни. Продовжуйте лише коли працівник може переказати початкову задачу й записати обіцяний наступний крок. Розширювати пілот можна за наявності потужності для підготовки пропозицій і без невирішених дефектів доставки. Пропозиція не дорівнює виконаному замовленню.

Для окремої партнерської пропозиції увійдіть у кабінет рекламодавця AffiliateCore та перенесіть перевірені опис і URL у чернетку офера, якщо створення доступне вашому обліковому запису. Умови приймання спочатку оформіть у робочому брифі. CRM, Директ і строки відповіді залишаються вашою операційною відповідальністю. Навчальні замовлення не оголошуються автоматично підтримуваними оплачуваними подіями платформи.

Робочий аркуш передавання заявки в CRM

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

Завантажити робочий аркуш у текстовому форматі

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

ПОРОЖНІЙ ШАБЛОН ДОМОВЛЕНОСТІ
Маршрут / послуга / версія сторінки: ____
Обіцянка оголошення / допустимі винятки: ____
Тестове середовище / погоджене вікно перевірки: ____
Код аудиту / час отримання та часовий пояс: ____
Підтвердження надсилання / посилання на запис CRM: ____
Обов’язковий контекст / фактично отримані значення: ____
Відповідальний / заміна / наступна задача / строк: ____
Правило кваліфікації та його версія: ____
Рішення: прийнято / відхилено / дубль / невідомо: ____
Причина / доказ / перевіряльник / час рішення: ____
Правило дубля / посилання на початкове звернення: ____
Замовлення: відкрите / втрачене / виконане / скасоване: ____
Доказ підсумку / кінець спостереження: ____
Невідоме / хто перевірить: ____
Дефект / версія виправлення / доказ повторного тесту: ____
Рішення: пройдено / не пройдено / зупинка; хто прийняв: ____

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

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

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

Оформіть виправлення й дозвіл на наступний пілот

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

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

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

Для суміжних задач: аналіз джерел у Метриці, розбіжності статистики та надійна доставка заявок до CRM. Тут кінцевий документ інший: доведений розрив конкретної зв’язки та перевірювані умови її повторного запуску.