ABM-кейс: как Aviasales собрал «свои» аккаунты через multi-touch и сократил цикл до MQL

ABM-кейс: как Aviasales собрал «свои» аккаунты через multi-touch и сократил цикл до MQL

В 2026 году классическая схема «контент → лид → MQL → SQL» в B2B всё чаще буксует: информационный search всё менее полезен, а AI-overviews съедают часть кликов. Поэтому выручку всё чаще требуют закрывать не только маркетингом, но и связкой RevOps (маркетинг–sales–customer success). В этом контексте ABM становится не “кампанией”, а системой: точечные списки + последовательные касания + атрибуция, которая учитывает путь, а не последний клик.

Ниже разберём кейс, вдохновлённый публично известной практикой Aviasales (как B2C-медиабавает превращают в B2B-направления для корпоративных клиентов: travel-операции, сервисы для компаний, подписки для отделов закупок/HR/финансов). Логика кейса переносится на B2B: принцип тот же — работать не с “рынком”, а с конкретными аккаунтами и их ролями.

Контекст
Рынок корпоративных поездок в России в 2025–2026 ужесточился: компании стали требовательнее к контролю бюджета и SLA по билетам/изменениям, а путь принятия решения стал длиннее. По данным внутренних разборов крупных travel-провайдеров (и типовой для индустрии структуре воронки) цикл от первого касания до статуса MQL обычно растягивался, потому что решение не принадлежит одному человеку:
— инициатор (закупки/админ/HR) ищет “удобно и быстро”
— финансы хотят контроль (лимиты, правила, отчётность)
— эксплуатация/пользователи оценивают UX и качество сервиса
И если маркетинг говорит с рынком “в среднем”, выигрывает тот, кто попадает в роль и момент.

Задача
Сжать время до MQL и повысить долю конверсий в корпоративном канале без увеличения рекламного бюджета. Конкретные KPI, которые взяли за основу:
— снизить цикл до MQL (от первого касания до события в CRM)
— увеличить долю аккаунтов, дошедших до MQL
— обеспечить multi-touch: чтобы у аккаунта было не одно случайное касание, а последовательность релевантных сообщений
— добиться “чистой” атрибуции: учитывать impact не только кликами, а по серверной аналитике (server-side) и инкрементальности (incrementality), где это возможно

Решение
1) Списки вместо “рынка”
Сначала собрали 2 слоя аккаунтов:
— ICP-ядро: компании по численности, отрасли и признакам регулярных поездок/активности закупок (примерно 1 500–2 000 компаний)
— lookalike/расширение: те же признаки, но с меньшей уверенностью (ещё 3 000–4 000)
Важно: ABM стартовал не с креатива, а с правил отбора. Для каждой отрасли сформировали 3 “сценария боли” (экономия времени, контроль бюджета/политик, стабильность сервиса).

2) Ролевые сообщения (не “про продукт”, а “про решение задачи”)
Сделали контент и офферы под роли. На уровне касания это выглядело так:
— для инициатора: короткие материалы “как внедрить процесс за X недель” (без магии, с чек-листами)
— для финансов/закупок: документы с примерами отчётности, правил списаний, логики лимитов
— для пользователей: демонстрация удобства (кейсы “что происходит при изменениях”, понятные сценарии)
В 2026 это особенно важно из‑за Zero-click: AI-overviews показывает “ответ”, но не заменяет практическую инструкцию под контекст конкретной компании.

3) Multi-touch по последовательности, а не по частоте
Построили journey из 4 касаний на аккаунт за 21–28 дней:
— Touch 1: персонализированная страница (landing) с отраслевым блоком и “что получит отдел”
— Touch 2: кейс или разбор процесса (короткий, без воды)
— Touch 3: targeted-материал “для финблока” (policy/контроль/отчётность)
— Touch 4: приглашение на короткую практическую сессию с sales (не “созвон ради созвона”, а предварительная диагностика по чек-листу)
Ключ: касания были связаны темой и ролью. Если пользователь/аккаунт “проваливался”, цепочка адаптировалась: не повторяли то же сообщение, а меняли блок (роль→контекст→формат).
…