SaaS / S+S *

Выйдя из состояния бета-версии, в нашем стартапе Trak.io мы приняли непопулярное решение: убрали бесплатную подписку и заменили её подпиской за $9/мес.

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

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

Продолжение хаба, опубликованного 30-го января.

Краткое содержание предыдущей серии: Россия, Москва, 2014-й год, телефонный провайдер решает запустить облачную IP-PBX, интегрировать ее с доработанной FMC-платформой одного из мобильщиков и зарядить все это в коммерцию, да так, чтобы сервис был полезным, клиенты счастливыми, а начальство довольным.

Мобильную составляющую сервиса мы разрулили — симки стали звонить так, как хотелось нам, а не так как это было задумано разработчиками FMC-платформы: мы видим все вызовы, получаем все, что набирается на мобильниках (принимаем от 2 до 20 символов), управляем звонками онлайн, включаем-отключаем все это, да еще и создали интерфейс, читай «Личный кабинет клиента», в котором можно назначать симкам короткие номера, блокировать-разблокировать трафик и, вообще, наводить доселе невиданную красоту в коммуникациях.

Вот такой личный кабинет получился:

Несмотря на то, что наша компания давно и плотно занимается интернет-телефонией и еще 5 лет назад получила все лицензии, понастроила узлов и успешно развела и кормит целый зоопарк астерисков, фрисвитчей и прочих коммунигейтов, модная облачная история упорно обходила нас стороной, хотя все необходимое для создания PBX в облаке было давно готово. Мы молча завидовали коллегам-конкурентам, запускавшим облачные сервисы один за другим и надеялись, что когда-нибудь и мы устремимся в заоблачные дали. Именно это и произошло полгода назад: летом 2014-го было решено — облакам быть и мы их будем продавать!



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

Когда у вас есть нужный софт и железо, техническая служба, состоящая исключительно из суровых ветеранов телекома и лояльная абонентская база, запуск нового продукта не выглядит пугающей историей. Более того, у нас было что предложить «вкусного», избалованному облачными чудесами, рынку: давняя (порядка двух лет) дружба с одним из представителей большой тройки и доработанная FMC-платформа. Об этом (и не только об этом) подробно.

Услуга FMC предлагается в России всеми крупными мобильщиками, называться она может по-разному, но суть услуги всегда одна — возможность через стык с операторским свитчем задружить корпоративные сотовые с офисной PBX и присвоить всем симкам короткие номера. Как говорится, все бы хорошо, да что-то нехорошо. При стандартной FMC-услуге на корпоративном мобильном появляется кривоватый внутренний номер с хитрым префиксом, ходят непонятные CallerID и идентификаторы транков. Для непосвященного в тонкости телефонии клиента, подобная услуга выглядит странновато, да и просит дополнительных платежей не очень понятно за что. Одним словом, FMC в России в сегменте малого и среднего бизнеса, что называется, понимания не встретил. Мы же, однажды попробовав FMC на вкус, поняли, что это штука крайне полезная и при некторой доработке на стороне мобильщиков и на стороне офисной PBX, может получиться отличный продукт для корпоративного VoIP-сервиса.

Примерно вот такой:



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

Первые конструкторы появились около 15 лет назад. Не так давно, но и не недавно, учитывая, что первый сайт появился в девяносто первом. С тех пор они претерпели немало изменений и сейчас большинство конструкторов работают по SaaS модели (англ. Site as a Service — сайт как сервис/услуга). Это значит, что сайт можно создать с помощью веб-приложения, которое разрабатывается и поддерживается поставщиком услуг, который сам следит за его работоспособностью и занимается обновлением ПО и оборудования. Поддержание работоспособности системы, техническая поддержка и иногда некоторые другие работы входят в оплату, которая обычно взимается с клиентов помесячно. При этом конечный пользователь не приобретает лицензию на программу, что позволяет ему значительно сэкономить. Но при этом нужно понимать, что конструктор – это, по сути, аренда сайта, а не его покупка.

Если вы продаете ПО, то наверняка при виде бюджетов больших корпораций задумывались, как бы и вам откусить кусочек от этого пирога. Лично мы в Web-payment.ru, проекте о платежных системах, постоянно ищем способы заполучить в партнеры крупные платежные системы или сервисы на рекламные услуги, разработку, или даже помощь в ведении блога на Хабре. В этой статье-переводе как раз пойдет речь о том, как работать с крупной рыбой. Сразу хотел бы предупредить, что наши реалии отличаются от западных, которые описываются в статье, но в чем-то они пересекаются, так что почитать интересно.

Многие задаются вопросом о продаже ПО офигенно большим организациям. Работать с такими крутыми компаниями в установленном вами ценовом диапазоне крайне непросто, так как любые величины меньше 500$ для них выглядят как ошибка в округлении. В то же время, наличие пары таких клиентов дарует вам социальную значимость, которая позволяет вам продавать как другим таким же гигантам, так и более мелким клиентам. Получив IBM в качестве клиента, вы ничего не потеряете. Ну а если при этом в самом IBM никого не уволили за выбор вас в качестве поставщика, значит, и вы вполне подходите для большой игры.

Наверное, вы уже прочитали тонны статей о том, как начать настройку метрики на своем сайте, измерить его ключевые показатели эффективности (КПЭ) и принимать грамотные решения на основе полученных данных. И, если вы уже применяете эти знания на практике, начав создавать собственную метрику и отслеживать события на ресурсе, вы отлично знаете, насколько это непросто.

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

Продолжаем перевод статьи Роба Уоллинга. В своих предыдущих работах автор уже успел осветить целый ряд важных вопросов (Клиент, исчезнувший на дне воронки и Почему уделять слишком много внимания трафику опасно для вашего бизнеса). Он обсудил тот факт, что сначала необходимо «заткнуть воронку», в которую утекают посетители, затем поработать над коэффициентом конверсии, а уж потом работать над привлечением максимального объема трафика на ваш веб-сайт. Но мы не поговорили о том, какую роль играет качество трафика в определении коэффициента конверсии. Думаю, не меня одного заинтересовал именно этот материал. Надеюсь, он принесет пользу многим!.

Приветствую вас, уважаемое Хабрасообщество. Привлечение и удержание клиентов – важнейшие задачи бизнеса. Поэтому хочу поделиться с вами переводом материала, написанного Робом Уоллингом. Информация окажется полезной как для стартапов, так и для тех, кто уже добился определенных результатов. .

Часть 1: Клиент, исчезнувший на дне воронки

Беседуя недавно с одним из участников Micropreneur Academy, я понял: ребята в стартапах считают увеличение трафика и повышение конверсии увлекательной игрой. Однако, если предлагаемая услуга является регулярной, необходимо помнить и о следующем этапе – удержании уже существующих пользователей.

Определенная доля текстовой части моего диплома была написана на Nokia E63 — было срочно и поздно, поэтому работать приходилось в пути, переездах, на конференциях, а ноутбука у бедного студента не было. Удобная QWERTY-клавиатура и доступный Интернет позволяли набирать и редактировать текст даже с определенным комфортом. В общем, некоторый опыт извращений в наборе текста у меня есть.



То ли дело современные студенты — ноутбуки, планшеты, редакторы онлайн и оффлайн, совместная работа над документами. Кажется, проблемы в далеком прошлом.

Здравствуй, Хабрасообщество!

Сегодня я расскажу вам, как и обещал в прошлой статье, про реализацию 3-D Secure authentication в SaaS-приложениях. 3-D Secure добавляет ещё один шаг аутентификации для онлайн-платежей. Обычно происходит редирект на сайт банка-эмитента, где пользователю предлагается ввести проверочный смс-пин для подверждения платежа. Этот процесс жутко неудобен, ваши клиенты обязаны уходить с вашего сервиса, чтобы пройти эту аутентификацию.

В LPCloud мы решили сделать 3-D Secure аутентификацию во фрейме, чтобы пользователь не покидал наш сервис.

Что было до этого?

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



Чуть больше года назад я рассказал о применении игрового подхода в электронной коммерции, а в январе показал во что превратилась эта идея и как мы с ней подавались в Канадские инкубаторы. В инкубатор мы не попали, хоть и добрались до самого финала. Мы могли присоединиться к любому инкубатору в Украине, но их условия показались нам не очень привлекательными. Так что, мы просто очень много работали эти 9 месяцев, а на хабре за это время так и не появилось новых материалов о «геймификации» в онлайн-торговле, разве что, кроме этого материала почему-то яро заминусованного публикой.

Существуют определенные закономерности в оформлении SaaS-проектов. В этом мы убедились, когда решили разрабатывать LPCloud – SaaS-платформу для работы с продающими страницами.

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

Когда перед разработчиками встает вопрос реализации подписки, как это было с нами при разработке LPCloud, многие используют уже готовые решения, например recurly.com, chargify.com, spreedly.com и др. У них есть, конечно, свои плюсы и минусы, но мы так и не смогли найти подходящий сервис, который бы удовлетворял нас по всем факторам и мы решили написать свою собственную систему регулярных платежей. В качестве процессинга карт мы выбрали cloudpayments.ru

Для удобства работы с оплатой по картам, мы заюзали известный gem activemerchant от Shopify, но столкнулись с такой делемой – activemerchant не поддерживал cloudpayments. Мы быстренько решили эту проблему допилив гем, он доступен на нашем аккаунте на гитхабе.

Вкратце

Нам требовалась система, которая бы имела следующие возможности:

• Возможность привязки карт пользователей
• Ежемесячный/ежегодный биллинг
• Индивидуально настраиваемый триальный период для пользователей
• Возможность обновления тарифа клиентом в любое время

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

BaasCMS — это JavaScript CMS, использующая в качестве бэкенда популярных провайдеров BaaS. На данный момент поддерживается только Parse.com.

Исходный код BaasCMS доступен на GitHub.

BaasCMS Demo на GitHub Pages
Тоже самое BaasCMS Demo на Tumblr

Можно посмотреть Админ-панель для этого демо (изменения/добавление запрещены). В соответвующую форму на главной странице админки нужно вставить следующие ключи:

• Application ID: nM7P7NnFA95CK1WrqWOf9wa3mskctaTOdk9vYflj
• Javascript Key: 0zHfA9FG8L1xR699qmFXjxkZ1pDxgml0MWZMpqJG

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

Мы предоставляем решение, которое может быть поднято за одну минуту. Простым вводом одной команды в ssh или предоставления нам логина и пароля от сервера вы получаете слепок вашей файловой системы и баз данных сервера (MySQL, MongoDB, PostgreSQL). Вы отмечаете, что нужно сохранить и с какой периодичностью. Не нужно писать или искать скрипты, покупать сервер или искать хостинг.

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

Поговорим о том, как устроена одна из главных составляющих облачной компании — финансы.

Оценить экономику компании помогают несколько простых метрик — MRR, CLV, CAC. В этом посте мы расскажем о том, как их считать и интерпретировать.

MRR: как оценить рост бизнеса

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

Здравствуй, Хабр!

Год назад мы столкнулись с проблемой. Если в двух словах — нас взломали. Взломали творчески, так, что мы не сразу поняли, что вообще происходит. В процессе решения проблемы получилось овладеть полезными навыками: составлять abuse-обращения и результативно общаться с хостерами, в т.ч. — зарубежными, больше радеть о безопасности нашего ресурса, постоянно мониторить наличие нашего сайта в индексе Яндекс и Google, и внимательно относиться к мелочам. В описываемом случае обычный символ «-» (дефис, минус, тире, черточка, палочка, дефисоминус) сыграл с нами злую шутку.

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

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

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

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