Модель коммерциализации в заявке «Сколково»: что показать до первых продаж

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

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

Начните с карточки предполагаемой сделки

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

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

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

Выберите основную гипотезу оплаты

Модель оплаты должна соответствовать пользе и способу применения продукта. Возможные варианты — платежи за доступ, за объект использования, за объём обработанных данных или за отдельное внедрение. До проверки это варианты, а не установленный рыночный факт. Не перечисляйте их все как равновероятные источники выручки.

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

Отделите цену от себестоимости и готовности платить

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

Запланируйте проверку каждой ключевой гипотезы

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

Различайте интерес, намерение и состоявшуюся продажу

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

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

В официальных критериях Фонда указан существенный потенциал коммерциализации.¹ Он требует содержательного объяснения перспективы проекта. При отсутствии продаж показывайте имеющиеся подтверждения и путь проверки модели; не заполняйте пробелы предполагаемой выручкой под видом фактической.

Свяжите пилот с решением о покупке

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

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

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

Покажите прогноз вместе с его основаниями

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

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

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

Соберите честный раздел о первой продаже

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

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

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