Меня зовут Михаил, я сооснователь компании Weavora. Компания начинала исключительно как аутсорсер, и 5 лет мы в основном этим и занимались. Однако нам всегда хотелось создать собственный продукт
В сентябре 2015 года мы запустили первую MVP-версию своего продукта — Everhour. Собрав достаточно фидбека от первых пользователей, мы принялись за абсолютно новую версию, которую запустили около месяца назад.
Сегодня над продуктом работает 7 человек. Мы self-funded, «профитабл», и продолжаем расти.
В своей статье я бы хотел поделиться некоторым опытом перезапуска продукта, этапами, идеями, результатами и, конечно, ошибками.
Everhour — это система тайм-трекинга, которая работает по модели SaaS. Если вы используете Basecamp, Asana или GitHub в своей команде, то, если вы подключите свой аккаунт к EH, в каждой задаче у вас появится кнопка старта таймера, возможность выставлять оценки, а также информация о прогрессе каждого члена команды. Плюс можно настраивать очень гибкие отчёты.
Продвижение медцентров и клиник: три кейса о SEO, TikTok и Instagram*
Как получить измеримые результаты в фарммаркетинге.
Показываем на примерах →
Спецпроект
1. Активный блогинг
Ещё в процессе работы над макетами, архитектурой и дизайном новой версии мы начали обсуждать наши планы с пользователями старой версии. Мы открыто писали обо всём происходящем в нашем блоге: рассказывали, какие изменения мы собираемся внести в систему и почему, от чего хотим избавиться, а что добавить.
Тем самым мы одним выстрелом убили нескольких зайцев:
- Пользователи видели, что продукт развивается. И, если кого-то что-либо не устраивало в текущей версии, он мог дождаться этого в новой.
- Мы проверяли наши новые идеи на платных пользователях до затрат на их реализацию.
- Мы сделали наши идеи и процессы максимально прозрачными и дали пользователям почувствовать, что их мнение действительно важно для нас.
- Мы получили несколько интересных идей, до которых сами не додумались.
С каждой новой статьёй нам приходили письма с вопросами, предложениями, макетами, идеями и благодарностью. Люди оставляли комментарии в блоге, общались между собой, видели, что пишут другие.
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.
Пользователям мы сделали следующее предложение:
- Так как мы не могли провести автоматическую миграцию данных (сильно отличается структура), мы предложили всем переходящим пользователям бесплатно сохранить за ними доступ к историческим данным в v1.
- У нас также менялся прайсинг (были пакеты, стало per user), и мы сохранили его за старыми пользователями с возможностью апгрейда в любой момент (для кого-то это было даже дешевле).
- Тем, кто не хотел переходить на новую версию, мы дали возможность продолжить пользоваться оригинальной версией. Тем не менее мы предупредили, что новых фич там не будет, только поддержка.
В целом не нужно бояться того, что вы не даёте пользователям мигрировать данные. В нашем случае отнеслись с пониманием. Многие захотели оставить за собой доступ к обеим версиям.
Чтобы обобщить вышесказанное, советуем:
- сделать переход на новую версию максимально прозрачным для старых и новых юзеров;
- открыто общаться;
- собрать базу лояльных клиентов;
- экспериментировать маленькими шагами и ничего не бояться.
Надеемся, наш опыт наведет вас на новые идеи и, возможно, убережёт от возможных ошибок.
Если у вас также есть интересный опыт перезапуска собственного SaaS-проекта, делитесь им в комментариях, нам очень интересно.
Мнение редакции может не совпадать с мнением автора. Если у вас есть, что дополнить — будем рады вашим комментариям. Если вы хотите написать статью с вашей точкой зрения — прочитайте правила публикации на Cossa.
Источник:
