Маршрутизація лідів визначає, який менеджер отримає ліда і як швидко. Більшість B2B-команд налаштовують її один раз, зазвичай як правило round-robin у CRM, і більше не переглядають, доки великий клієнт не поскаржиться, що за тиждень з ним зв’язалися троє різних менеджерів. Найбільше страждають ліди із сайту, бо сайт знає про відвідувача набагато більше, ніж фіксують поля форми, і майже нічого з цього контексту не доходить до правила маршрутизації.
У цій статті розглянуто, як правильно розподіляти ліди з сайту: спочатку зіставлення з акаунтом, маршрутизація за наміром замість черговості надходження, урахування анонімних візитів із високим наміром, які так і не стають лідами, та вимірювання того, чи допомагає маршрутизація, чи шкодить.
Чому ламається маршрутизація лідів із сайту
Ціна повільної або неправильної маршрутизації добре задокументована. У дослідженні, опублікованому в Harvard Business Review, Олдройд, Макелгеран і Елкінгтон повідомили, що на вибірці з 1,25 млн лідів компанії, які намагалися зв'язатися з лідом протягом години, майже всемеро частіше кваліфікували його, ніж ті, що чекали навіть на годину довше. Кожен крок маршрутизації, кожна черга, кожен «нерозподілений» кошик з'їдає цю годину.
Типові точки збою:
- Маршрутизація за лідом, а не за акаунтом. Новий контакт від наявного клієнта чи з акаунта, з яким уже працює AE, потрапляє в розподіл по колу й дістається незнайомій людині.
- Усі форми обробляються однаково. Підписка на розсилку і запит демо зі сторінки цін потрапляють в одну чергу з однаковим SLA. Маршрутизація працює найкраще, коли форма для збору лідів запитує лише те, чого не може заповнити збагачення даних.
- Брак контексту. Менеджер бачить ім’я, email і компанію. Він не бачить, що троє колег з цієї компанії цього тижня читали сторінку цін.
- Анонімний намір ігнорується. Більшість відвідувачів сайту ніколи не заповнюють форму, зокрема багато хто з акаунтів, які активно оцінюють рішення. Маршрутизація, що починається з форми, бачить лише цю невелику частку.
Крок 1: насамперед зіставте лід з акаунтом
Перше рішення з маршрутизації — не «який менеджер наступний?», а «чи належить ця людина до акаунта, за який уже хтось відповідає?»
- Нормалізуйте домен електронної пошти і зіставте його з наявними акаунтами в CRM. Дочірні компанії та регіональні домени обробляйте через таблицю псевдонімів.
- Якщо в акаунта є відповідальний, маршрутизуйте до нього. Клієнти — до акаунт-менеджера. Відкриті можливості — до AE, який веде угоду. Цільові акаунти — до закріпленого менеджера.
- Якщо збігу немає, створіть або збагатьте акаунт фірмографічними даними до маршрутизації, щоб правилам за територіями та сегментами було з чим працювати.
- Лише після цього переходьте до розподілу за територією чи по черзі (round-robin).
Зіставлення ліда з акаунтом — це крок, що запобігає проблемі «три менеджери, один клієнт». Інструменти на кшталт LeanData та Chili Piper побудовані саме навколо цього, а HubSpot і Salesforce можуть робити базову версію через воркфлоу та правила призначення, якщо ваші дані про домени чисті. У нашій статті про підключення даних персоналізації сайту до CRM описано схему зіставлення акаунтів, яку ми рекомендуємо.
Крок 2: розподіляйте за рівнем наміру, а не за порядком надходження
Не кожен лід із сайту заслуговує на однакове ставлення. Визначте три-чотири рівні наміру на основі того, що відвідувач робив до і під час конверсії, і задайте кожному рівню власний шлях і SLA.
| Рівень | Типові сигнали | Кому передати | Цільовий час відповіді |
|---|---|---|---|
| Активний запит | Запит на демо або зв'язок із продажами, особливо після перегляду цін | Власник акаунта або AE за територією | Хвилини, а не години |
| Високий намір | Завантаження контенту плюс перегляди цін, порівнянь чи інтеграцій; кілька людей з акаунта | SDR за територією чи акаунтом | Того ж робочого дня |
| Дослідження | Завантаження контенту верхньої частини воронки, без сторінок пізнього етапу | Маркетинговий nurture | Автоматизовано |
| Погано підходить | Поза ICP, особистий email на тарифі з участю відділу продажу, студент або конкурент | Шлях самообслуговування або без маршруту | Немає |
Сформулюйте SLA як відлік, що починається з моменту надсилання форми, а не з призначення, і заздалегідь вирішіть, що відбувається в разі порушення: перепризначення наступному вільному менеджеру або сповіщення керівнику команди. SLA без наслідків — це лише побажання.
Рівень визначає ваша модель скорингу. Якщо її ще немає, наш шаблон моделі скорингу лідів дає таблиці відповідності й поведінки, які можна адаптувати за пів дня.
Крок 3: передавайте контекст із сайту разом із лідом
Розподілений лід має надходити з достатнім контекстом, щоб менеджер міг почати розмову без додаткових пошуків. Як мінімум:
- Сторінки, переглянуті за останні 30 днів, з виділеними сторінками пізніх етапів
- Кількість інших людей з тієї самої компанії на сайті за цей період
- Кампанія чи джерело, що їх привели, включно із самостійно вказаним джерелом, якщо ви про це запитуєте
- Який персоналізований досвід вони бачили (галузь, сегмент, варіант), щоб перша фраза менеджера відповідала повідомленню, яке покупець уже прочитав
Цей останній пункт часто пропускають. Якщо ваш сайт показав відвідувачу з логістики логістичний кейс і CTA «подивіться на ваших даних Salesforce», перший лист SDR не повинен починатися із загальної презентації. Наш посібник з узгодження продажів і маркетингу за допомогою даних про відвідувачів містить шаблон передачі для цього.
Крок 4: розподіляйте також анонімні акаунти з високим наміром
Найцінніша зміна, яку може зробити більшість команд, — маршрутизувати акаунти, а не лише ліди. Коли ідентифікація на рівні компанії показує акаунт з ICP із кількома відвідувачами на сторінках цін та інтеграцій, ніхто не заповнив форму, тож класична маршрутизація лідів так і не спрацьовує. Проте в цього акаунта є власник — або має бути.
Налаштуйте сповіщення на рівні акаунта:
- Визначте компанію за відвідуванням.
- Зіставте його з акаунтом у CRM і його власником (та сама логіка, що й у кроці 1).
- Коли акаунт перетинає поріг (наприклад, двоє або більше відвідувачів і перегляд сторінки цін за сім днів), сповістіть відповідального у Slack чи email, указавши переглянуті сторінки.
- Якщо в акаунта немає власника, призначте його за територією, так само як для ліда.
Ідентифікація відвідувачів Markettailor надає збіг компанії та історію сторінок, потрібні для цього сповіщення, тож власники дізнаються про акаунт, поки той ще досліджує, а не після того, як конкурент призначив перший дзвінок. Більше про пошук таких акаунтів серед анонімного трафіку — у статті ШІ-лідогенерація з анонімних відвідувачів сайту.
Розібраний приклад: три запити за один день
Ілюстративний приклад: ось як наведені вище правила обробляють три конверсії на сайті, що надходять з інтервалом менше години.
Запит 1: запит демо від нового контакту в наявного клієнта. Проста ротація надіслала б його наступному SDR, який почав би продавати продукт, за який компанія вже платить. Із зіставленням акаунтів домен збігається з акаунтом клієнта, тож запит іде до акаунт-менеджера як імовірна розмова про розширення — разом зі сторінками, які переглядав контакт (сторінка цін другої продуктової лінійки).
Запит 2: завантаження електронної книги з невідомої компанії-розробника ПЗ середнього розміру. Зіставлення з акаунтом немає. Збагачення показує хорошу відповідність. Відвідувач прочитав дві статті в блозі й більше нічого. Це рівень дослідження: лід іде у вирощування, а акаунт — у список спостереження. Через два дні колега з тієї самої компанії читає ціни та сторінку інтеграцій. Акаунт перетинає поріг високого наміру й маршрутизується до SDR території з історією сторінок обох відвідувачів.
Запит 3: форма зв’язку з відділом продажів від агенції з 4 осіб з особистою email-адресою. Погана відповідність для продажів через менеджерів. Замість того щоб забирати час SDR, відвідувач отримує автоматичну відповідь із посиланням на тариф самообслуговування та записаний тур продуктом.
Черга SDR бачить лише другий запит і лише тоді, коли акаунт проявляє реальний інтерес.
Round-robin: де він доречний, а де ні
Ротація підходить як останній резервний варіант для лідів середнього рівня без власника. Вона не працює, коли на ній тримається вся система:
- Менеджери у відпустці продовжують отримувати ліди. Використовуйте round-robin з урахуванням доступності, інакше лід чекатиме днями.
- Рівний розподіл — не справедливий розподіл. Десять лідів дослідницького рівня й один, хто сам виявив інтерес, не рівноцінні. Зважуйте за рівнем або ведіть окремі ротації для кожного рівня.
- Немає захисту від колізій. Коли кілька SDR працюють зі спільних списків чи однієї території, двоє можуть узятися за того самого потенційного клієнта. Командам, що ведуть outbound зі спільних списків, зазвичай потрібне резервування лідів, коли відкриття ліда закріплює його за одним менеджером на певний час. Резервування лідів у Dialbrew — один із прикладів такого підходу.
Як вимірювати маршрутизацію лідів
Звітуйте про це щомісяця з розбивкою за рівнем наміру:
- Час до призначення: від надсилання форми чи сповіщення до призначення власника. Для автоматизованих правил це мають бути секунди.
- Час до першого контакту: від призначення до першого дзвінка чи листа. Відстежуйте частку оброблених у межах SLA, а не лише середнє значення, бо середні приховують лідів, які чекали три дні.
- Частка помилкової маршрутизації: частка лідів, перепризначених вручну після маршрутизації. Якщо вона перевищує кілька відсотків, ваші правила зіставлення чи територій потребують доопрацювання.
- Конверсія в зустріч за рівнем: якщо ліди рівня досліджень конвертуються так само добре, як ліди з високим наміром, ваші рівні нічого не розділяють.
- Частка дублікатів контактів: акаунти, з якими протягом одного тижня зв’язувалися кілька менеджерів.
Детальніше про час реакції читайте в нашій статті про швидкість реакції на B2B-запити демо.
Почніть тут
- Додайте зіставлення з акаунтами перед вашим поточним round-robin.
- Виділіть тих, хто сам виходить на зв'язок, в окремий шлях з SLA у хвилинах.
- Додавайте історію переглядів сторінок до кожного переданого ліда.
- Додайте одне сповіщення на рівні акаунта про анонімні відвідування з високим наміром.
- Щомісяця переглядайте неправильні маршрутизації та порушення SLA.
Щоб побачити, які акаунти досліджують вас сьогодні й запустили б сповіщення на рівні акаунта, замовте демонстрацію на нашій сторінці цін.