ABM-мероприятие для целевых аккаунтов 1:few: роли

Практическое руководство по ABM-мероприятию 1:few: как объединить выбранные компании общей темой, развести роли и закрепить следующий шаг.

ABM расшифровывается как account-based marketing. По-русски это совместная работа маркетинга и продаж по заранее выбранным компаниям. Здесь мы разбираем формат 1:few: одну закрытую программу для нескольких компаний с общей темой и отдельным продолжением по каждому аккаунту. ABM-мероприятие для целевых аккаунтов строится вокруг этих компаний, ролей участников решения и конкретного вопроса, который они должны обсудить.

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

Если проект уже стоит в плане, начните с организации делового мероприятия. Мы поможем перевести список компаний и ролей в формат, программу, маршруты гостей и рабочий сценарий площадки.

Что делает мероприятие ABM, а не просто закрытым?

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

Salesforce описывает account-based marketing как работу маркетинга и продаж с выбранными ценными аккаунтами через персонализированное взаимодействие и измерение на уровне компании. Поэтому мы проектируем событие не только вокруг отдельного гостя. Мы учитываем компанию, состав участников решения и вопрос, который им нужно обсудить.

У обычного клиентского события может быть широкая тема и единая программа. Камерная встреча позволяет глубже разобрать один вопрос. Закрытый разбор для руководителей и экспертов, или executive briefing, обычно готовят для одной компании. ABM-мероприятие может объединять несколько выбранных аккаунтов, если для них есть общий контекст и предусмотрены отдельные ролевые маршруты.

Эта статья разбирает одно событие. Вопрос о том, как связать несколько форматов и действия между ними, мы вынесли в материал про сквозную модель event-led growth.

Граница проекта: аккаунты, роли и одно решение

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

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

Рабочая карточка границы отвечает на несколько вопросов:

• какие компании входят в программу;
• почему общая тема относится к их текущему контексту;
• какое решение или проверка объединяет участников;
• какие роли нужны со стороны каждой компании;
• какой результат можно получить прямо на событии;
• кто продолжит работу после него.

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

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

Как выбрать аккаунты для одной программы?

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

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

Salesforce рекомендует выбирать аккаунты с учётом характеристик компании, технологического контекста, истории отношений и сигналов интереса. 6sense показывает ограничение таких сигналов: модель собирает активность на уровне компании и не доказывает намерение конкретного человека. Поэтому мы не переносим внутреннюю оценку приоритета компании в приглашение и не делаем вывод о готовности купить по одному действию.

Практический порядок отбора выглядит так:

1. Заказчик формирует исходный список компаний и называет причину приоритета.
2. Владелец каждого аккаунта описывает текущий контекст без лишних конфиденциальных деталей.
3. Команда проверяет соответствие общей теме и вопросу события.
4. По каждой компании отмечают известных участников решения и пробелы в составе.
5. Мы проверяем совместимость аккаунтов, форматов и правил открытого разговора.
6. Для каждого приглашения назначают владельца и допустимый следующий шаг.

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

Карта группы принятия решения и пробелы в составе

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

LinkedIn отдельно выделяет участников, которые работают с потребностью, и менее заметные функции контроля. Они оценивают риск, финансы, право и операционную сторону. HubSpot позволяет собирать группу принятия решения на карточке компании, назначать контактам роли и отмечать недостающие связи. Для события это удобная логика: команда видит представленные вопросы и пробелы в составе.

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

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

Для одного стратегического аккаунта карта может привести к отдельному executive briefing для одного целевого аккаунта. В ABM-программе для нескольких компаний мы используем тот же принцип ролей, но собираем общие и персональные эпизоды в одном событии.

Как превратить карту ролей в приглашения?

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

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

Ролевой вариант точнее: «На рабочей сессии мы разберём требования к интеграции и эксплуатации решения. Со стороны организатора участвует технический эксперт. Если тема относится к вашему проекту, пришлите вопросы заранее или подключите коллегу, который отвечает за архитектуру». Это шаблон формулировки, а не готовое письмо для всех ролей.

Мы собираем приглашение по одной последовательности:

1. Называем деловой контекст, который можно открыто использовать.
2. Формулируем вопрос для конкретной роли.
3. Объясняем, кто будет собеседником и какой формат запланирован.
4. Просим подготовить данные или вопросы только при необходимости.
5. Указываем правила закрытого разговора и использования материалов.
6. Предлагаем подключить коллегу, если адресат не покрывает нужную функцию.
7. Фиксируем владельца приглашения и актуальный статус ответа.

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

Персональные маршруты вместо общей программы

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

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

Архитектура может включать:

• общий вводный блок по задаче;
• ролевые столы или тематические треки;
• назначенные разговоры аккаунта с экспертами;
• демонстрацию по заранее собранному сценарию;
• рабочую зону для разбора требований;
• место для короткой фиксации итогов с владельцем аккаунта.

Для программы с общей сессией и несколькими треками подходит механика организации конференции или семинара. При этом ABM-логика требует заранее связать каждый трек с аккаунтами, ролями и владельцами итогов. Сама сетка параллельных залов этого не делает.

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

Какие форматы нужны разным ролям аккаунта?

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

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

Формат бизнес-завтрака подходит, когда руководителям удобна короткая камерная встреча и общая тема допускает разговор между компаниями. Мы рассматриваем бизнес-завтрак с целевыми клиентами как оболочку. Смысл ABM-программы создают состав, вопросы и подготовленные продолжения.

Рабочие сессии и наблюдаемые сигналы

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

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

Шаблон карточки приоритетной сессии:

Аккаунт:
Тема и вопрос сессии:
Участники и их роли:
Контекст, который можно использовать:
Ожидаемый результат:
Наблюдаемые факты разговора:
Открытые вопросы:
Что обещано участнику:
Следующий шаг или решение не продолжать:
Владелец действия:
Срок, если он согласован:
Статус передачи владельцу аккаунта:

Заполнять карточку лучше сразу после сессии. Иначе формулировки быстро превращаются в пересказ по памяти. Запись должна быть понятна владельцу аккаунта без отдельного созвона с организатором.

Наблюдаемые сигналы помогают выбрать содержание продолжения. Они не служат автоматической оценкой готовности купить. Вопрос технического эксперта указывает на тему ответа. Подключение новой роли показывает изменение состава разговора. Отказ помогает остановить неуместную коммуникацию.

Аудитория партнёрского события устроена иначе: там роли связаны с совместными инициативами и экосистемой. Эту границу мы раскрываем в материале про партнёрский саммит компании.

Как согласовать следующий шаг до события?

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

Допустимые продолжения могут быть разными:

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

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

Salesforce Trailhead показывает принцип работы со статусами участников кампании: команда связывает контакты с кампанией и отслеживает ответы через согласованные статусы. Для практической работы достаточно одного вывода. Словарь статусов, поля результата и владельцы должны существовать до события, чтобы команда не восстанавливала процесс задним числом.

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

Передача итогов владельцам аккаунтов и критерии результата

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

Передача строится по порядку:

1. Связываем участника с нужной компанией и ролью в обсуждаемом решении.
2. Записываем вопрос, действие или ограничение без оценки по впечатлению.
3. Добавляем договорённость либо прямую фиксацию отсутствия продолжения.
4. Указываем обещанный материал, встречу или ответ.
5. Назначаем владельца и срок, если стороны его согласовали.
6. Передаём карточку в рабочую систему заказчика.
7. Проверяем, что владелец принял задачу и понимает контекст.

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

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

Перед финальным отчётом мы задаём четыре вопроса:

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

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

Источники

• Salesforce: The Complete Guide to Account-Based Marketing
• LinkedIn B2B Institute: The Hidden Buyer Gap
• LinkedIn Sales Solutions: How to Build and Navigate Buying Committees
• HubSpot: Set up account-based marketing
• HubSpot: Review stakeholders with buying groups
• 6sense: Intent Model
• Cvent: Event Formats
• Cvent: Roundtable Discussions
• Salesforce Trailhead: Campaign Members Tracking