20% от подписки - еще не партнерское предложение

Мне пришло рекламное письмо с темой:

Лаборатория автоматизации “LOG [IN] OFF”, вашим клиентам нужны боты - зарабатывайте на этом 20%

Компания предлагает стать партнером Ai платформы.
Логика выглядит понятной:

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

Тема для меня не посторонняя.
Я сам думаю, как развивать партнерскую сеть “Дожми Продажи”. Среди потенциальных партнеров могут быть интеграторы Битрикс24, CRM, телефонии, разработчики приложений и компании, которые уже работают с отделами продаж.

Я продолжаю собирать такие решения в серии о маркетинге “Дожми Продажи”.
Поэтому я не хочу разбирать это письмо с позиции человека, которому все очевидно.

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

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

Это непростая работа.
Но именно поэтому я бы не начинал ее с массового письма про 20%.

Что в письме сделано нормально

Сначала о сильных сторонах.
В письме есть конкретный процент:

20% от подписки в течение 12 месяцев.

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

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

Есть демо без регистрации.
Есть предложение взять настройку на себя или провести ее вместе с партнером.
То есть это не пустое письмо в духе:

У нас уникальный AI-продукт. Предлагаем взаимовыгодное сотрудничество.

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

Название компании в обращении - не персонализация

Письмо начинается так:

Здравствуйте, Лаборатория автоматизации “LOG [IN] OFF”!

Формально название нашей компании подставили.
Но дальше идет текст, который можно отправить почти любому интегратору:

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

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

Персонализация начинается с ответа на вопрос:

Почему вы решили написать именно этой компании?

Например:

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

Здесь уже появляется причина для диалога.
Партнер видит, что отправитель изучил его продукт и нашел конкретную точку пересечения.
В полученном письме такой точки нет.
Есть только предложение получить доступ к клиентам партнера.

”Вашим клиентам нужны боты” - диагноз без проверки

Фраза звучит уверенно:

Вашим клиентам нужны боты и ИИ.

Возможно, некоторым действительно нужны.
Но потребность клиента не возникает просто потому, что существует технология.
Один клиент хочет быстрее отвечать на типовые вопросы.
Другой хочет квалифицировать обращения.
Третий хочет снизить нагрузку на поддержку.
Четвертый просит AI-бота, хотя его реальная проблема находится в сломанном процессе, плохих данных или отсутствии ответственного.

Поэтому сильное предложение начинается не с диагноза:

Вашим клиентам нужны боты.

А с проверяемой гипотезы:

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

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

20% - это процент, но еще не деньги

Главный оффер письма:

20% от подписки - 12 месяцев.

Цифра конкретная.
Но я не понимаю, сколько это в рублях.
В письме нет:

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

20% может быть существенной суммой.
А может быть суммой, ради которой партнеру невыгодно проводить даже одну дополнительную встречу.
Сам процент ничего не говорит об экономике партнерства.
Партнер считает не только комиссию.
Он считает всю работу:

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

Кроме того, партнеру важно понимать, кому достаются деньги за сопутствующие работы:

• обследование;
• настройку;
• интеграцию;
• обучение;
• доработки;
• сопровождение;
• развитие проекта.

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

Вы получите 20%.
А:
На таком-то тарифе вы получаете такую-то сумму за год. Дополнительно вы самостоятельно продаете внедрение, настройку и сопровождение. Клиент закрепляется за вами на таких-то условиях.

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

Функции продукта не объясняют работу партнера

Большая часть письма посвящена возможностям платформы:

• несколько ботов;
• продажи;
• поддержка;
• внутренние ассистенты;
• корпоративный чат;
• работа с документами;
• разные каналы связи;
• собственная AI-модель;
• отсутствие отдельной платы за каждый ответ.

Возможно, все это важно для конечного клиента.
Но партнер сначала хочет понять другое:

Что должен сделать я?
Мне достаточно познакомить производителя с клиентом?
Или я должен провести продажу?
Нужно ли самостоятельно показывать продукт?
Кто собирает требования?
Кто делает внедрение?
Кто отвечает за интеграцию?
Кто оказывает поддержку?
Кто общается с недовольным клиентом?
Кому принадлежит дальнейший контакт?
Может ли производитель продавать этому клиенту напрямую?

В письме есть фраза:

Настройку берем на себя или делаем вместе с вами.

Это полезно.
Но она не описывает распределение ответственности.
Пока мне предлагают целый штат AI-ботов, но не показывают, как будет устроено партнерство между двумя человеческими компаниями.

Партнер рискует не только временем

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

Это проблема производителя, а интегратор здесь ни при чем.

Чаще он говорит:

Вы рекомендовали мне это решение.

Поэтому партнеру недостаточно ссылки на демо.
Ему нужно понимать:

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

Партнерская сеть строится не только на возможной выгоде.
Она строится на понятном распределении риска.

Это больше похоже на реферальную программу

По механике письмо предлагает:

• привести клиента;
• получить процент от подписки;
• при необходимости участвовать в настройке.

Это нормальная реферальная модель.
Но партнерская сеть обычно требует большего.
Партнеру нужны:

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

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

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

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

Как бы я привлекал партнеров

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

Вариант 1. Максимальная персонализация

В первоначальном варианте этого разбора я выбрал приложение CRMbot и построил предложение вокруг простой связки:

Ваш продукт показывает руководителю данные из CRM, а мы добавим к ним факты из звонков и переписок.

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

Remark позиционирует себя не как разработчика одного приложения, а как отраслевого digital-интегратора с основной экспертизой в недвижимости. Компания внедряет CRM, строит BI-аналитику, выпускает собственные решения для застройщиков, проводит отраслевые мероприятия и показывает кейсы, связанные в том числе с качеством обработки лидов.

То есть писать им:

Мы покажем то, чего вы не видите в продажах,

было бы не персонализацией, а новым диагнозом без исследования.

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

У нас есть несколько компаний из недвижимости, которым мы помогаем с речевой аналитикой. Это не делает нас большими экспертами по цифровизации девелоперов, чем Remark. Но дает основание для профессионального разговора о более узком слое:

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

Поэтому я бы не начинал ни с партнерской программы, ни с публичного вебинара.

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

Сообщение могло бы выглядеть так:

Добрый день.

Изучил ваш сайт и продукты для девелоперов. Вижу, что Remark работает значительно шире отдельного приложения: внедряет CRM, развивает BI-аналитику, создает отраслевые решения и отдельно занимается качеством обработки лидов.

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

Не хочу заранее утверждать, что наш подход дополняет ваши решения. Возможно, часть этой задачи вы уже закрываете внутри проектов.

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

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

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

Есть ли смысл сначала сверить наши подходы на такой рабочей встрече?

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

Во-вторых, я не пытаюсь объяснить Remark, как устроены продажи девелоперов. У них значительно больше отраслевого опыта. Я приношу ограниченный собственный опыт и предлагаю проверить, дополняет ли он их систему.

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

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

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

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

Последовательность тогда выглядит так:

изучение отраслевой экспертизы партнера - закрытая сверка подходов - одна узкая гипотеза - пилот на специальных условиях - совместный материал или мероприятие - партнерская модель.

Это медленнее, чем отправить письмо про процент.
Но именно так партнер видит, что ему предлагают не привести клиентов в чужой продукт, а вместе проверить новый слой ценности для уже знакомой ему отрасли.

Вариант 2. Максимальный доход партнера

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

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

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

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

Тогда модель может выглядеть так:

• производитель получает оплату за платформу;
• партнер получает оплату за внедрение;
• партнер получает сопровождение;
• партнер дополнительно получает долю подписки.

Это значительно сильнее, чем просто:

20% в течение 12 месяцев.

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

Вариант 3. Максимально простой первый проект

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

Например:

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

До первого контакта нужно зафиксировать:

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

Так партнеру не нужно сразу:

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

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

Какой подход я бы выбрал для “Дожми Продажи”

Я бы не выбирал только один из трех вариантов.
Для ограниченного списка сильных партнеров я бы соединил их.
Сначала - максимальная персонализация:

Почему наши продукты могут дополнять друг друга именно в проектах этой компании?

Затем - понятная экономика:

На каких работах и в какой момент зарабатывает каждая сторона?

После этого - один простой совместный проект:

Проверяем полный путь от первого разговора до результата для клиента.

Последовательность могла бы выглядеть так:

подходящий продукт - совместная клиентская задача - полезное мероприятие - первые обращения - совместный проект - партнерская модель.

А не так:

массовое письмо - обещание процента - ссылка на демо - ожидание, что партнер сам найдет способ это продавать.

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

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

Партнерская сеть не начинается с регистрации в личном кабинете.

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

Главный вывод

Потенциальному партнеру недостаточно сообщить:

У нас хороший продукт, вашим клиентам он нужен, а вы получите 20%.

Ему нужно ответить на четыре вопроса:

• Почему вы выбрали именно меня?
• Кому из моих клиентов это действительно подходит?
• Сколько конкретно я заработаю?
• Какую работу и какой риск вы забираете на себя?

Процент без расчета остается цифрой.
Название компании в шаблоне не становится персонализацией.
Список функций не объясняет модель партнерства.
А доступ к клиентской базе партнера нельзя получить только потому, что у продукта есть демо и реферальная ссылка.

Партнерская сеть строится не вокруг процента.
Она строится вокруг повторяемой ситуации, в которой партнеру понятно:

кому предложить продукт, какую дополнительную пользу получит клиент, сколько заработает каждая сторона и почему производителю можно доверить отношения с этим клиентом.

FAQ о партнерских программах и привлечении партнеров

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

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

Что должно быть в партнерском предложении?

Партнеру нужно объяснить:

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

Список функций продукта этих вопросов не закрывает.

Чем партнерская программа отличается от реферальной?

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

Какой процент нужно платить партнеру?

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

Что является настоящей персонализацией партнерского письма?

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

Зачем предлагать партнеру совместное мероприятие?

Мероприятие позволяет проверить сразу несколько гипотез:

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

Это менее рискованный первый шаг, чем требование сразу обучить отдел продаж и начать приводить клиентов.

Как защитить клиента партнера?

До первого совместного контакта нужно зафиксировать:

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

Без этого партнер рискует своей клиентской базой и репутацией.

С чего начать создание партнерской сети?

Я бы прошел последовательность:

подходящий продукт - совместная клиентская задача - мероприятие или пилот - первый проект - проверка экономики - масштабируемая партнерская программа.

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