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

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

Это статья по итогам выступления на конференции ProductSense в Москве весной 2018 года. На тот момент Михаил был руководителем направления в iiko, а сейчас работает в BeFit.

От торговой модели — к сервисной

Компания iiko существует на рынке 11 лет. Сейчас около 22 000 ресторанов использует наш продукт по всему миру. Основные клиенты находятся в России, при этом доля зарубежных продаж достаточно велика. Если вы ходите в рестораны, то скорее всего сталкивались с нашим продуктом: например, получали вовремя или не вовремя заказы, чеки и т.д.

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

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

 

В 2018 году произошли фундаментальные изменения нашей модели: за подписку мы стали получать больше денег, чем за разовые продажи лицензии. Разумеется, ещё долгое время разовые продажи будут лидировать. Но так называемый «квантовый скачок» состоялся, и, по моему мнению, через 5−6 лет доля разовых продаж значительно уменьшится.

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

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

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

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

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

Расскажу подробнее, как мы увеличили число подписок, с какими проблемами столкнулись и как их решили.

Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.

Как оптимизировать продажи в сервисной модели

В 2013 году мы запустили облачный сервис. Вначале это было топорно – клиент так же платил за лицензию, но в рассрочку. Услуга продавалась довольно вяло. В 2015 году мы сделали полноценный сервис: упаковали хостинг, поддержку, регулярное получение обновлений. Назвали продукт iikoCloud. После этого продажи увеличились.

 

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

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

Наконец, мы автоматизировали продажи. Если раньше требовалось очень много человеческого труда для установки софта, то сейчас клиент практически самостоятельно проходит от точки «Я хочу автоматизацию» до точки «Я пользуюсь и продаю через iiko». Через сервис iikoStore можно полностью купить наш продукт.

Сейчас большая часть клиентов использует локальную iiko, которую они один раз купили и установили. И это затрудняет развитие, потому что мы не можем достаточно быстро выпускать фичи. В облачных сервисах релиз выходит раз в две недели: мы можем оперативно добавлять новый функционал, тестировать, делать замеры. Но в локальных установках версия тиражируется примерно год. Обратную связь мы получаем в течение года. Это неэффективно, потому что бывает, что клиент только через 6−7 месяцев говорит «здесь не учтено такое-то требование».

Чтобы решить эту проблему, мы приняли волевое решение переводить всех в облако. За это мы даем скидки. Сейчас мы делаем новые продукты только в облаке. Так мы мотивируем клиентов: «хочешь новый сервис, который будет предсказывать продажи по типам бизнеса, иди в облако». В ближайшие несколько лет планируем перевести порядка 70−80% клиентов в облако.

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

Разберем основные проблемы, с которыми мы столкнулись, и как мы их решили.

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

 

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

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

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

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

В решении этой проблемы с мнительными клиентами нам помогает прием от обратного. Допустим, клиент хранит данные в ресторане, приходит ОБЭП, забирает стол с компьютером и данными. Всё, их уже не вернуть. А мы храним данные на хостинге и готовы отдать официальным органам только после судебного запроса. Но перед этим уведомим клиента о том, что такой запрос был за 1−2 недели. Этот аргумент помогает в работе.

Третья проблема — изменение способа продажи. Раньше был длинный цикл продажи: мы брали описание бизнеса, аналитику, решали, что из этого использовать в коммерческом предложении, какие бонусы предложить клиенту и так далее. Но с облачным сервисом такая система работала плохо. Получилось, что долгая продажа уводила нас в финансовую дыру на несколько месяцев. Нужно было выплачивать зарплату и бонусы продавцам и аналитикам. А небольшая ежемесячная оплата от клиента отбивает цену продажи только через 8−12 месяцев.

Эту проблему мы решили кардинально. Сначала перешли к отдельной категории продавцов, которые отвечают за облако. Расписали для них кейсы по каждой категории бизнеса в отдельности. На данном этапе мы анализируем проекты, выделяем некоторые типовые конфигурации и вооружаем продавцов готовыми кейсами. Делаем так, чтобы цикл продажи с двух месяцев сократился до 1−2 дней, максимум, недели.

Четвертая проблема — местные законы. Когда мы задумывали облако, планировали сделать так: у нас есть большой отказоустойчивый дата-центр в Германии, и мы его используем по всему миру. Выбрали Германию, потому что там адекватные цены, хороший хостинг, и рестораторов успокаивает фраза: «ваши данные хранятся в Германии». Но государство нам напомнило о статье 152 Федерального закона «О персональных данных». И чем дальше, тем больше необходимо делать стыковок с локальными государственными облаками — налоговыми, например, и не только.

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

Какие метрики измерять в сервисной модели

Мы часто измеряем NPS — индекс потребительской лояльности – внутри софта. Так мы можем понять, насколько клиентам нравятся разные части нашей системы. Например, получить отзывы от кассиров, собственников, бухгалтеров. Мы следим, чтобы NPS был высокий, поэтому в ручном режиме разбираем всех критиков.

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

Во-вторых, мы считаем отток по разным видам бизнеса. Например, кофе-пойнты постоянно появляются, работают 2−3 месяца, а затем умирают. Естественный отток кофейных точек очень большой, и с этим ничего не сделаешь. Ещё есть сезонный бизнес. Например, какое-нибудь прибрежное кафе открылось под одним юрлицом, три месяца поработало и закрылось. Мы не зацикливаемся, если на каких-то отдельных категориях большой отток. А вот если рестораны уходят, и отток становится больше определенного порога, мы поднимаем красный флаг и разбираемся, почему так происходит.

 

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

Стоимость рекламы тоже считаем, потому что не каждый вид рекламы может отбить прибыль, которую мы получаем с облака.

Наконец, мы измеряем LTV — прибыль, которую клиент приносит за всё время работы с ним. Этот показатель зависит от ситуации, цены продажи, Churn, костов. Есть разные виды продуктов, в некоторых LTV меньше, в некоторых больше. Мы считаем LTV по партнерам и по видам бизнеса, следим в динамике за тем, чтобы показатель был в референсных значениях. В результате LTV постоянно растет, потому что мы вкладываем много усилий в уменьшение всевозможных костов.

Выводы

• Если вы еще не используете сервисную модель, ее нужно обязательно запускать. Это помогает сделать компанию финансово-предсказуемой — вы сможете посчитать, сколько получите через два месяца или два года. Финансовые разрывы исчезают, а рыночная стоимость компании возрастает.
• Перед тем, как запускать сервисную модель, нужно провести «домашнюю работу». Внимательно измерить основные бизнес-параметры — сколько вы тратите на каждый юнит, поддержку, хостинг, плюс считать LTV. Там, где можно, подключить автоматизацию. Внедрить различные системы мониторинга. И добиться, чтобы продукт легко поддерживался.
• Если вы собираетесь работать по всему миру, открывайтесь заново для каждой страны. Это актуально для сегмента b2b, потому что в b2c можно из одной страны перейти на весь мир. Но в b2b нужно позаботиться о том, чтобы продажи не остановились из-за нового закона и вам не пришлось срочно менять платформу.

Благодарим за подготовку статьи редактора Елену Егину.