Как перезапустить SaaS-продукт и не потерять пользователей. Опыт Everhour

Меня зовут Михаил, я сооснователь компании Weavora. Компания начинала исключительно как аутсорсер, и 5 лет мы в основном этим и занимались. Однако нам всегда хотелось создать собственный продукт

В сентябре 2015 года мы запустили первую MVP-версию своего продукта — Everhour. Собрав достаточно фидбека от первых пользователей, мы принялись за абсолютно новую версию, которую запустили около месяца назад.

Сегодня над продуктом работает 7 человек. Мы self-funded, «профитабл», и продолжаем расти.

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

Эффективная и выгодная реклама с сервисом от МегаФона

Широкий выбор рекламных каналов, более 100 параметров по интересам, подробная аналитика и другие возможности уже ждут в Личном кабинете. А еще кешбэк 100% за запуск рекламы в первый месяц и еще 10% — каждый месяц.

Узнать больше >>

Реклама. ПАО «МегаФон». ИНН 7812014560. ОГРН 1027809169585. ERID LjN8K1P7y.

Everhour — это система тайм-трекинга, которая работает по модели SaaS. Если вы используете Basecamp, Asana или GitHub в своей команде, то, если вы подключите свой аккаунт к EH, в каждой задаче у вас появится кнопка старта таймера, возможность выставлять оценки, а также информация о прогрессе каждого члена команды. Плюс можно настраивать очень гибкие отчёты.

1. Активный блогинг

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

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

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

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

2. Early adopters (ранние пользователи)

Ближе к дате запуска новой версии мы ненавязчиво предложили нашим пользователям стать beta-тестировщиками. Для этого мы разместили форму в одном из постов в блоге и уже в день старта получили регистрации на бета-тест от более чем 100 лояльных компаний.

Они нам здорово помогли: нашли несколько неприятных моментов, на которые у нас уже был «замылен глаз». Не было никакого негатива (как это бывает у новых пользователей, купивших продукт и обнаруживших ошибку).

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

Хочется отметить — мы неоднократно упоминали, что это будет отдельная версия, которая никак не связана с оригинальной, подчёркивали это и в пригласительных письмах, и прочих материалах. Тем не менее пользователи всё равно пытались залогиниться, используя старые логины или путались, когда не видели своих данных в новой версии.

Вывод:

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

3. Вебинары

Чтобы пользователи быстрее вникли в суть новой системы и установили всё правильно, мы решили организовать серию вебинаров. К email-приглашению попробовать бета-версию мы прикрепляли Google-форму регистрации на ближайший вебинар.

Процент желающих был довольно велик... но, к сожалению, на сам вебинар пришли единицы.

Мы, конечно, огорчились, ведь было потрачено много времени на подготовку. Команда задерживалась в офисе, чтобы подстроиться под часовой пояс US, готовила скрипты, демо-аккаунты, рассылала напоминалки. А проводить часовой вебинар ради пары человек, само собой, нецелесообразно.

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

В качестве площадки для проведения вебинара мы решили попробовать YouTube Live. Идея была в том, что если вебинар пройдет хорошо, мы выложим видео в своём канале. Но, если честно, мы остались недовольны качеством звука. Поэтому будем пробовать что-то ещё. Если у вас есть какие-то идеи и советы на этот счёт — пишите в комментариях, нам очень интересен ваш опыт.

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

4. Непрерывное общение

В Private Beta мы выходили с ограниченным функционалом, была вероятность возникновения ошибок в системе. Также были сомнения по поводу того, всё ли будет понятно пользователям с первого раза. Само собой, очень важно было оставаться на связи в режиме реального времени, чтобы пользователи не потеряли энтузиазм.

Поэтому с самого начала мы решили использовать Intercom.

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

У интеркома для этих целей есть 3 интересных продукта. Acquire и Resolve мы активно используем и сегодня, а вот Engage как-то не зашёл.

Если кому интересна цена вопроса, то при 2500 юзерах 2 продукта стоят $88/mo, на 5000 это $112, на 10 000 будет $160.

5. Привлечение новых пользователей

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

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

Мы говорим «ограниченному», так как в самом начале мы стартовали только с одной интеграцией (Asana) и расширением только для Chrome. Поэтому мы хотели показывать этот бар только этому сегменту пользователей.

Для этого мы попробовали HelloBar и SumoMe. Остановились на последнем, так как HB почему-то сразу не заработал.

Конверсия по баннеру была около 8%, что, в принципе, мы считаем неплохим результатом.

6. Приглашения для отвалившихся пользователей

Следующим шагом мы решили пригласить в новую версию тех пользователей, которые когда-то пользовались Everhour, но потом ушли.

Мы сегментировали их по размеру компании, роли, дате регистрации, типу интеграции, платящий/нет и подготовили несколько вариантов маркетинговых писем.

Чтобы их как-то мотивировать, мы начали с того, что предлагали им расширенный триал (30 дней вместо 14). Также в будущем не исключаем вариант дисконтов.

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

Но по факту Open Rate оказался довольно неплохим, порядка 25-30%. И, что важно, процент отписок был минимальным, буквально пару процентов.

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

7. Миграция существующих клиентов

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

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

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

Пользователям мы сделали следующее предложение:

1. Так как мы не могли провести автоматическую миграцию данных (сильно отличается структура), мы предложили всем переходящим пользователям бесплатно сохранить за ними доступ к историческим данным в v1.
2. У нас также менялся прайсинг (были пакеты, стало per user), и мы сохранили его за старыми пользователями с возможностью апгрейда в любой момент (для кого-то это было даже дешевле).
3. Тем, кто не хотел переходить на новую версию, мы дали возможность продолжить пользоваться оригинальной версией. Тем не менее мы предупредили, что новых фич там не будет, только поддержка.

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

Чтобы обобщить вышесказанное, советуем:

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

Надеемся, наш опыт наведет вас на новые идеи и, возможно, убережёт от возможных ошибок.

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

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