Модель 4 — партнёрка как часть пресейла Есть такой вариант, и я его не придумал. Он реально встречается у крупных вендоров: Cloudflare и ServiceNow держат отдельные роли Partner Solutions Engineer именно внутри пресейл-организации. Но я не планирую писать про большие компании, потому что рискну предположить: функции иногда переходят из одной вертикали в другую, это нормальный процесс поиска лучшего пути конкретно под страну, зрелость, рынок.
Могу лишь отметить плюсы передачи функции партнерки в пресейл, но минусы, справедливости ради, распишу, какие вижу. 👍Плюсы 1️⃣Партнёры получают техническую экспертизу без посредников. Все же самую большую (но при этом невидимую) часть работы с партнером тащит на себе инженер поддержки продаж, который помогает партнеру пропилотировать решение, получить в нем экспертизу, научиться его администрировать. Так же именно “околопресейловый” эксперт (или BDM) учит партнеров, как позиционировать и продвигать продукт своим заказчикам. Пресейл это единственная роль, которая может дать такую поддержку нативно, без формирования дублирующей функции где-то в другом юните.
2️⃣Обратная связь с рынка доходит быстрее и накапливается в одном центре компетенций. Пресейл традиционно ближе всего к тому что реально хочет рынок, потому что видит больше живых кейсов чем кто-либо в компании. Если партнёрские технические специалисты тоже сидят в пресейле, собранная ими информация не теряется на стыке отделов, а сразу попадает в общий контур обратной связи с продуктом.
3️⃣Партнёр получает единую точку технического контакта (а я верю, что технический контакт важнее, чем “сейловый”. Через сейлз канал партнер сверяет свой статус и процент скидки, а через пресейл получает буквально все остальное: экспертизу, поддержку, слайды, демо платформы, и, что так же доступно: часть маркетинговых коммуникаций, проходящих через пресейл.
4️⃣Пресейл пропускает через себя все сделки, как коммерческие так и партнерские - и может повлиять в тех местах, где сейл невольно (или намеренно) нарушает границы интересов партнеров.
👎Минусы 1️⃣Пресейл оптимизирован под скорость сделки, а не под построение партнёрства. Метрики пресейла — это закрытые демо, проведенные пилоты, конверсия в сделки в моменте. Партнёрские отношения (повторюсь) требуют совершенно другого горизонта: сертификация партнёра, выстраивание его собственной экспертизы, совместное планирование на кварталы вперёд. Встроенная в пресейл партнёрка рискует скатиться в режим быстро закрыть конкретную сделку с партнёром вместо системного развития канала.
2️⃣Риск превратиться в бесплатных тренеров без коммерческого фокуса. Есть отдельно отмеченная опасность: партнёрскому пресейлу слишком легко скатиться в роль просто тренеров, а не полноценных драйверов партнёрских продаж.
3️⃣Пресейл силён в объяснении технологии — но слаб в выстраивании коммерческой стратегии канала, работе с мотивацией партнёра зарабатывать, управлении конфликтами между партнёрами за одного заказчика.
4️⃣Пресейл-лид редко обладает нужным набором навыков для управления каналом. Руководство партнёрской программой это по сути роль генерального менеджера, нужно балансировать интересы продаж, маркетинга, продукта и самого партнёра одновременно. Пресейл-лид обычно силён в технической экспертизе и управлении инженерами, но не обучен коммерческой архитектуре канала, юридическим аспектам партнёрских соглашений, финансовому моделированию совместных инвестиций.
5️⃣Двойная нагрузка на ограниченный ресурс. Пресейл-команда и так разрывается между прямыми сделками. Добавление полноценной партнёрской нагрузки без выделенных людей означает что либо страдают прямые продажи, либо партнёры получают техническую поддержку по остаточному принципу.
6️⃣Нет естественного веса для отстаивания партнёра перед остальным бизнесом. В отличие от отдельной функции с прямым выходом на CEO, партнёрка внутри пресейла подчиняется тем же приоритетам что и весь пресейл — а значит партнёрские интересы всегда будут вторичны по отношению к горящим прямым сделкам.
🏆Вместо вывода:
