Четыре неочевидных проблемы при смене бизнес-модели

История Neatsy.ai: от ориентации на B2C клиентов до перехода в B2B сектор

Идея приложения, которое при помощи смартфона позволит решить вечную проблему подбора нужного размера обуви, появилась у нас в 2019 году. До этого мы с Антоном Лебедевым и Константином Семьяновым много работали с нейросетями и компьютерным зрением и опытным путем нащупали, что iPhone с технологией TrueDepth для Face ID можно использовать также для более точного измерения параметров тела. А значит, потенциально его можно использовать для определения размера.

В какой-то момент я сам понял, что устал от бесконечных примерок обуви в магазинах (а заказ из онлайн-магазинов мне давался с трудом из-за нестандартной ноги) – так появился Neatsy.ai: подбор кросовок с помощью первого в мире 3D-сканера через iPhone без каких-либо дополнительных устройств и референсов.

Изначально мы рассчитывали, что главным клиентом Neatsy будут сами покупатели кроссовок. Почему именно обувь? В случае с одеждой непопадание в размер не так болезненно: если футболка чуть больше, в ней можно пойти в спортзал, а если обувь не подходит на полразмера, носить ее часто невозможно. Покупателю приходится возвращать товар – это время, лишние усилия и иногда деньги – в первую очередь для продавца. На кроссовках мы остановились по простой причине – это самый большой рынок обуви в онлайне – примерно 75% продаж.

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

Мы пришли к такой точности определения размера, что на этапе пилотов смогли в 1,5 раза повысить вероятность того, что купленная обувь пользователю подойдёт (обычно она составляет всего 45-50%, с Neatsy — 75%). А для продавца обуви количество возвратов снижается вдвое.

Однако юнит-экономика при таком подходе не сходилась. Ритейлер готов отдавать 5-10% от суммы покупки, но за счет перехода пользователя на другой сайт сильно терялась конверсия. В результате маржа падала до 1% – пользователь должен был купить кроссовки 4-5 раз, чтобы отбить затраты на привлечение.

Однако болезненной проблема подбора правильных кроссовок является и для самих ритейлеров – возврат товара зачастую стоит дороже самой доставки. Тогда мы задумались, что вероятно нашим клиентом должен быть не покупатель кроссовок, а тот, кто заинтересован в том, чтобы ему подошел размер – бренд или онлайн-ритейлер. После публикации о запуске продукта нам начали писать потенциальные B2B-клиенты: онлайн-маркетплейсы одежды и обуви, производители кроссовок (и даже футбольная команда, но это другая история). Нам стало очевидно, что продукт нужно переориентировать с конечного пользователя на e-commerce ритейлеров: мы решили предложить встраивать наше решение на сторону продавца – за 2% от оборота магазина, который он получит с помощью наших рекомендаций по покупке. Для пользователя наше приложение – бесплатное.

Сама идея оказалась рабочей – сейчас мы реализуем несколько платных пилотов с крупными е-commerce ритейлерами. Но на всю перестройку с B2C-модели к B2B и отработку бизнес-процессов у нас ушло примерно 9 месяцев. Вот с чем нам пришлось столкнуться в процессе.

«Трудности перехода»

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

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

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

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

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

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

Помимо этого, сделали защиту внутреннего кода, который занимается непосредственно сканированием. Часть кода, которая непосредственно включает камеру глубины на iPhone, собирает точки стопы для обмера и дальнейшего прогноза, вынесена в отдельную библиотеку. Этот конкретный кусочек кода мы поставляем не в исходном виде, а в бинарном, собранном компилятором. И эта такая дополнительная защита того, что «под капотом».

Правда, о защите кода мы подумали еще до перехода на B2B модель, потому что не хотели показывать код с ключевой технологией разработчику iOS на фрилансе, который рисовал для нас экраны. Мы заранее «запаковали» стек в удобную коробочку, чтобы клиенты могли добавить свой дизайн.

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

Также был отдельный челлендж с встраиванием коробочного решения у клиентов, которые пишут свои приложения для iOS не классическим способом на языке SWIFT, а используют кросс-платформенные фреймворки React Native и Flatter. Оказалось, что не все из них умеют интегрировать iOS у себя в библиотеке. Поэтому нам пришлось потратить пару недель на создание минимального прототипа, чтобы они смогли вставить нашу технологию в своё приложение и получить работающее решение.

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

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

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

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

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

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

Постепенно мы пришли к такому выводу: нужно не мудрить, а сделать Saas-модель. Она работает гораздо лучше, чем классические методы ценообразования софта, когда предприниматель приходит к потенциальному клиенту и говорит, что “наш софт стоит 100 тысяч долларов в год”. А с Saas моделью можно начать буквально с копеек, брать пять центов за пользователя и далее масштабировать.

Важно, чтобы клиент видел, что вам он платит, например, один доллар за пользователя, а его дополнительная выгода от пользователя - пять долларов. Золотая середина Saas - от 10 до 20% приносимого экономического эффекта. Далее вы думаете, за что именно ставить цену, согласовываете с клиентом и масштабируете эту модель.

Saas-модель удобна для менеджеров магазина, потому что можно протестировать эффект на маленьких бюджетах (при маленьком объеме пользователей), и для предпринимателя. В работе с большими заказчиками есть неочевидная проблема: менеджеры часто меняются и потом сложно «заходить» в компанию с продуктом заново. Поэтому контракт, составленный так, чтобы позволять увеличение бюджета в рамках одного контракта (при увеличении объема работ и количества пользователей) – идеальное решение.

Держать в голове, что product market fit и клиент стартапа могут оказаться другими, стоит в самом начале работы над стартапом. Многие проблемы, с которыми мы столкнулись в процессе можно было бы предусмотреть на начальном этапе разработки. Сейчас мы работаем с несколькими клиентами в России, планируем расширяться на зарубежные рынки и считаем, что в целом, успешно нашли предложение для клиентов и «пофиксили» проблемы при смене бизнес-модели.

Приходилось ли вам сталкиваться с чем-то похожим? Пишите в комментариях!