Partner Enablement Day: подготовка партнёров к продажам

Partner Enablement Day готовит партнёров к продажам продукта. Разбираем роли, практику, демо, проверку готовности и план действий после события.

Partner Enablement Day нужен, когда партнёрам уже мало услышать новости продукта. Им предстоит объяснять ценность клиенту, задавать вопросы по его задаче, показывать рабочий сценарий и вовремя передавать сложный запрос эксперту. Один доклад редко готовит к этим действиям.

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

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

Что такое Partner Enablement Day для партнёров?

В этой статье мы используем рабочее определение «Авентуры»: Partner Enablement Day - очный или гибридный практический день подготовки действующих партнёров к продаже, демонстрации и сопровождению конкретного продукта. Слово enablement здесь означает готовность к работе: участник понимает аудиторию, выполняет выбранное действие и знает, кому передать вопрос за пределами своих полномочий.

Официальные программы Google Cloud и SAP разделяют обучение по рабочим ролям; похожий подход используют Oracle и Red Hat. Отдельные модули предназначены для продаж и предпродажной технической подготовки. Такую подготовку часто называют пресейлом: специалист помогает продавцу уточнить задачу клиента, подобрать решение и подготовить демонстрацию. Salesforce описывает partner enablement через инструменты, материалы и обучение для продажи и поддержки продукта.

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

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

Граница формата: саммит, конференция, запуск и сертификация

В работе «Авентуры» Partner Enablement Day посвящён конкретному продукту, сценарию продажи или новому периоду работы. Чтобы не смешивать его с соседними форматами, мы используем рабочее разграничение: саммит сверяет направление партнёрской сети, дилерская конференция обсуждает общую повестку, запуск знакомит аудиторию с новинкой, а сертификационная сессия проверяет результат по заранее утверждённой процедуре.

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

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

Как определить готовность партнёра?

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

Работу удобно начать в таком порядке:

1. Выберите продукт, сценарий или коммерческий период, к которому готовится партнёр.
2. Назовите роли партнёра, от которых зависит работа с клиентом.
3. Определите исходный уровень каждой роли через анкету, интервью или короткое задание.
4. Выберите несколько действий, которые участник выполнит во время дня.
5. Согласуйте признаки качественной попытки с владельцами продукта, продаж и предпродажной технической подготовки.
6. Решите, какой материал и дальнейший маршрут получит участник после обратной связи.

AWS описывает партнёрскую трансформацию как оценку исходного уровня, обучение и подготовку к работе по индивидуальному плану. Red Hat проверяет, связывает ли продавец задачу клиента с решением, объясняет ли ценность, уточняет ли запрос, отвечает ли на возражения и проводит ли демонстрацию. Эти примеры поддерживают простой вывод: одного присутствия на обучении для оценки готовности мало.

Для Partner Enablement Day можно выбрать такой базовый набор:

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

Продуктовая команда заказчика утверждает критерии. Мы переводим их в задания, расписание, короткий чек-лист для эксперта и инструкции ведущим. Участник видит критерии до начала практики, поэтому понимает, на что будет смотреть эксперт во время обратной связи.

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

Роли участников и разные маршруты

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

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

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

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

Как построить программу от контекста к действию?

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

Рабочий цикл выглядит так:

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

Oracle даёт партнёрам материалы по позиционированию, планированию работы с клиентом, продажам и демонстрации продукта. HubSpot выстраивает последовательную учебную программу из продукта, продаж, подготовки партнёров, аналитики и работы с материалами. Очный день соединяет такие элементы в один маршрут, а дальнейшее обучение остаётся в партнёрском портале.

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

Как устроить практические станции?

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

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

1. роль и исходный уровень участника;
2. рабочий вопрос;
3. действие, которое выполняет участник;
4. исходные материалы и доступы;
5. критерии наблюдения;
6. длительность и вместимость;
7. ведущий и профильный эксперт;
8. допустимый уровень раскрытия;
9. основной и резервный сценарии;
10. материал или действие после станции.

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

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

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

Демо-зона и технический резерв

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

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

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

Обучение или сертификация?

Основная часть Partner Enablement Day даёт участнику право на ошибку, корректировку и повтор. В проектах «Авентуры» слово «сертификация» используем только тогда, когда заказчик утвердил критерии, процедуру проверки, полномочия экспертов, фиксацию решения и порядок обратной связи. В остальных случаях называем модуль практикой или диагностикой текущего уровня.

Google Cloud, Oracle, Red Hat и HubSpot используют в своих системах обучения подтверждения, цифровые знаки и сертификаты. Эти механики принадлежат конкретным программам компаний и не образуют универсальный отраслевой стандарт. Заказчик сам определяет, нужна ли формальная оценка, по каким правилам она проходит и кто вправе принимать решение.

Если сертификационный модуль входит в день, мы отделяем его от учебных станций по времени, ролям и данным. Участник заранее знает критерии и формат. Команда события отвечает за организацию потока и среды, а решение о квалификации остаётся у уполномоченных экспертов заказчика.

Эксперты, репетиция и передача вопросов

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

Подготовку проводим по шагам:

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

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

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

Метрики готовности и план после события

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

В финале участник составляет короткий план применения. В нём можно зафиксировать:

1. продукт или сценарий;
2. целевую аудиторию;
3. материал, который партнёр возьмёт в работу;
4. первый разговор, демо или внутреннюю передачу;
5. вопрос, который должен закрыть вендор;
6. владельца следующего контакта;
7. согласованную контрольную точку.

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

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

Что входит в организацию и смету?

Смета Partner Enablement Day зависит от числа ролей, маршрутов, станций, демонстраций и формата подключения. Число гостей влияет на площадку и сервис, но не объясняет весь объём работ. Сначала мы согласуем программу, роли, практические модули и требования продукта. После этого считаем помещения, технику, производство и команду.

В смету могут входить:

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

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

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

Источники

• AWS Partner Transformation Program - оценка исходного уровня, обучение, подготовка к работе и индивидуальный план развития партнёра.
• Google Cloud Learn and Grow - отдельные коммерческие и технические маршруты, практические лаборатории и подтверждения обучения.
• Salesforce - What is Partner Enablement? - инструменты, материалы, сценарии продаж и постоянное обучение партнёров.
• Oracle PartnerNetwork - обучение продажам, позиционирование, планирование работы с клиентом, демонстрации и материалы.
• IBM Partner Plus - Go to market - обучение продажам, цифровые знаки, учебные маршруты и готовые маркетинговые материалы.
• SAP Learning for Partners - обучение партнёров по продажам, предпродажной подготовке, маркетингу, внедрению и поддержке.
• Red Hat Partner Training - ролевые маршруты, уточнение запроса, объяснение ценности, работа с возражениями, демонстрация и подтверждения обучения.
• HubSpot Academy - Sales Hub Software for Solutions Partners - последовательная учебная программа и практическое обучение для партнёров.