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

Также прадед считал, что продвигают свои идеи и продукты (в смысле, прилагают к этому какое-то дополнительное усилие, кроме самого факта разработки) только скользкие люди и спекулянты. И он прожил честную — с его точки зрения — но довольно скромную в финансовом отношении жизнь. К сожалению, идеи и их реализованные прототипы сами себя продают достаточно редко.

Поэтому мы («Рейтинг Рунета») попросили экспертов, у которых есть подтверждённые кейсы по работе с софтверными компаниями, рассказать конкретно и без воды — что нужно делать, чтобы продвигать ПО. Брали этих людей, в первую очередь, из топ-10 отраслевых срезов нашей площадки (например, из «Рейтинга разработчиков сайтов софтверной тематики 2022»). Но также добавили мнения некоторых агентств, которые показались нам интересными.

Вводная часть про ситуацию с продвижением ПО

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

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

1. Общий язык, квалификация клиента. Клиенты из IT похожи на нас, мы имеем схожие процессы и проблемы, говорим на одном языке.

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

3. Интеграция команд. Софтверные компании обычно не заказывают проект «под ключ». Они приходят с чем-то уже имеющимся: дизайном, бэкендом, частично или полностью готовым проектом. Часто со своей инфраструктурой разработки. Всё это требует плотной коммуникации между командами. И не только технической, но и организационной.

4. Открытость. Тимлиды, проджект- и/или продакт-менеджеры либо знают чего хотят, либо готовы к исследованиям. Но в любом случае открыты к предложениям и обсуждению вариантов реализации. Главное — иметь обоснования, объяснить «зачем и как».

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

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

7. Экспертные продажи. Продажи осуществляются нашими тимлидами и топами. Продаётся экспертность и качество коммуникации.

Продаёт тот, кто будет делать.

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

Что учитывать при разработке сайта (с целью продажи софта)

Мы уже разрабатывали несколько маркетинговых сайтов для разработчиков SaaS-решений. Один из которых подробно отобразили в кейсе на про редизайн Okdesk.

Есть несколько ключевых моментов при разработке сайтов ПО, о которых кто-то забывает, а кто-то на них забивает:

1. Раздел «Отраслевые решения». Позволяет “примерить” функционал на свою сферу. Проработав раздел под каждую нишу, собираются посадочные, которые при продвижении существенно повышают конверсии. Например: Система автоматизации сервиса, техподдержки и выездного обслуживания медоборудования.

2. Раздел «Возможности» — подробный разбор ключевых функциональных возможностей, которые предоставляет сервис или ПО. Позволяет выделяться на фоне конкурентов и погружать в продукт. Здесь важным будет показывать функционал ПО или сервиса, через скриншоты и видео.

3. Возможность попробовать бесплатно. Потенциальному клиенту важно скачать демо, зайти в ЛК и пощупать своими руками продукт. Если возможности нет, то сделать уклон в CTA на онлайн-демонстрацию продукта.

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

Как настраивать таргетированную рекламу для продвижения софта

Поэтому в креативах для таргетированной рекламы акцентируем внимание на возможность «знакомства» с продуктом:

• бесплатную подписку на пробный период,

• ограниченный пробный функционал,

• продукт-трипваер,

• и так далее.

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

Главная ошибка в этой сфере — продавать сервис в лоб через таргет.

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

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

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

По результатам видно, что мы не прогадали — получили 172 регистрации на курс и 82 покупки софта. Конверсия в покупку при таком подходе составила 48%, что на 16% эффективнее, чем с продажи только через бесплатный доступ.

Брендинг для софта

Отрасль брендинга для софтверной тематики имеет свою специфику. Я бы выделил следующие моменты:

• Не всегда есть понимание важности бренда, как составной части продукта;

• Визуальный вкус, основанный на техническом образовании.

Эти два пункта связаны между собой.

Основатели tech-компаний часто видят продукт, как функционал, как технологию. Не всегда они понимают, что бренд — составная часть продукта.

«Бренд» (восприятие марки потребителем) может стать важным элементом выбора, если покупка преследует удовлетворение социальных потребностей целевой аудитории. Например, бренд воспринимается как профессиональный.

Основатели не всегда понимают этот принцип, думают, что бренд — внешний вид, а не «восприятие марки потребителем». Хотя сами основатели обычно пользуются хорошим ноутбуком, хорошим телефоном, умными часами, ездят на тесле, потому что эти бренды воспринимаются как «профессиональные», «технологичные» или «удобные». Это феномен бренда.

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

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

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

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

Условно можно выделить следующие направления разработки МП для софтверных компаний:

• Автоматизация процессов управления персоналом (кадровые процессы, внутрикорпоративная коммуникация, взаимодействие с бухгалтерией и т. д.).

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

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

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

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

Кроме того, существует «движение» от кроссплатформы в сторону нативной разработки и наоборот. Бывает так, что несколько лет назад проект написали на кроссплатформе, но потом решили от этого отказаться, потому что, например, сложно искать разработчиков под устаревшую кроссплатформу или в какой-то момент времени руководство решило перейти на натив, чтобы обеспечить большую стабильность работы приложения и предсказуемость разработки.

Но есть и обратный поток, который идет от натива в сторону новых кроссплатформ, — например, Kotlin Multiplatform. В 2022 году появилась новая кроссплатформа SCADE 2.0 на Swift, на которой можно также делать интересные проекты с общей логикой.

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

• Попытка развивать проект на старом и не всегда хорошо работающем коде, вместо того чтобы разработать новый вариант сервиса;

• Неумение и/или нежелание слушать команду разработчиков;

• Директивный подход в управлении сложными техническими проектами;

• Незаинтересованность в конечном результате со стороны менеджмента.

Что учитывать при использовании CRM

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

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

Работа CRM-системы для таких компаний должна поддерживать 3 основных процесса работы с клиентами:

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

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

• работа с оттоком. Здесь основное внимание уделяется причинам «не продления» и работе с возражениями.

Если говорить про основные показатели в отчетах, то там обязательно должны присутствовать: LTV, ROMI, Churn Rate, CPL. Как правило, это не базовые показатели в отчетах CRM и для сбора аналитики потребуется подключение и других систем в единый дашборд на базе BI-системы.

Возможно, кому-то подобные советы покажутся слишком очевидными, но мы видели ряд историй, когда увлечённые разработчики делали что-либо — от нового таск-менеджера до CRM-системы — в первую очередь, думая о функционале. Нередко потом создателям приходилось всё равно проходить некое самообучение по маркетинговому позиционированию продукта и его продвижению, чтобы суметь ответить на вопрос «Кому это реально нужно (кроме меня)?».