Команда нашла удобную CRM, руководитель согласовал подписку. Через неделю выясняется, что нужный отчёт доступен в другом тарифе, вложения не попали в импорт, а интеграцию предстоит делать отдельно. Это условный пример, но он показывает, почему выбор SaaS нельзя заканчивать на красивом интерфейсе и месячной цене.
В Гуси-Лебеди мы предлагаем пройти путь будущего пользователя до оплаты и массового переноса данных. Сначала объясним модель простыми словами, затем разберём расходы, контрольный сценарий внедрения и отдельную задачу: создание собственного продукта по подписке.
Что такое SaaS и чем он отличается от PaaS и IaaS
SaaS расшифровывается как Software as a Service: программное обеспечение как услуга. Вы пользуетесь приложением через интернет, а поставщик размещает и обслуживает его. Оплата часто зависит от подписки или использования. Такое определение и варианты тарификации приведены в объяснении SaaS от AWS.
Представьте облачную почту: сотрудник открывает приложение, читает письма и меняет доступные настройки. Ему не приходится самостоятельно устанавливать почтовый сервер и выпускать обновления его программного обеспечения. Но создать рабочие учётные записи, определить права и обучить коллег нужно своей компании.
К SaaS относятся, например, облачные CRM, офисные приложения и инструменты совместной работы. Категория продукта не гарантирует одинаковый набор функций: две CRM могут совершенно по-разному поддерживать ваш процесс продаж. Для знакомства с моделью полезен материал Microsoft Azure; возможности выбранного продукта проверяйте в его документации.
В названиях облачных моделей легко запутаться. Отличие удобнее увидеть через результат, который получает клиент:
| Модель | Что вы получаете | Какую задачу решаете |
|---|---|---|
| SaaS | Готовое приложение | Пользуетесь сервисом и настраиваете доступные функции |
| PaaS | Платформу для создания и запуска приложений | Разрабатываете и размещаете своё приложение |
| IaaS | Вычислительные ресурсы, сеть и хранилище | Организуете инфраструктуру и управляете своим программным окружением |
Это сравнение общих моделей, а не полный перечень обязанностей по договору. Границы управления конкретной услугой нужно уточнять у провайдера.
SaaS и установка программы на собственном сервере также требуют разной организации работы. В первом случае приложение обслуживает поставщик сервиса. Во втором нужно определить, кто отвечает за размещение, обновления и восстановление вашей установки. Само наличие ежемесячного платежа ещё не доказывает, что продукт является SaaS: обслуживание собственной программы тоже может оплачиваться регулярно.
Преимущество готового сервиса становится полезным, когда его возможности подходят задаче. Если каждое действие приходится обходить через таблицы, ручные выгрузки и переписку, стоит пересмотреть выбор. Заказная разработка тоже требует денег и сопровождения, поэтому сравнивать нужно рабочие варианты, а не идеальный собственный продукт с неудобным чужим.
Сколько стоит использование: проверьте весь сценарий, а не одну подписку
На странице тарифа ищите прежде всего единицу оплаты. Один сервис считает пользователей, другой объём операций, третий предлагает пакеты функций. Запишите условия именно выбранного тарифа: возможности всей линейки могут в него не входить.
Для сравнения предложений соберите расходы на одинаковый период. Практическая схема расчёта выглядит так: подписка по фактическому объёму использования плюс нужные дополнения, внедрение, перенос данных, интеграции, обучение и сопровождение. Это способ организовать расчёт, а не готовая цена или обещание экономии.
Если вы платите за участников, уточните, какие роли считаются платными и как оформляется изменение их числа. Приглашённый наблюдатель и полноценный редактор могут тарифицироваться по-разному. Не переносите правила одного сервиса на другой.
Если тариф ограничивает операции или хранение, пройдите привычную рабочую задачу и посмотрите, что учитывается в лимите. Затем выясните порядок его превышения: блокировка действия, доплата или переход на другой пакет. Нужен ответ из условий поставщика, а не предположение менеджера вашей команды.
Если нужна интеграция, проверьте её отдельно. Доступность API ещё не подтверждает, что через него получится передать нужные поля, вложения и события. Выясните ограничения, кто разрабатывает подключение и кто разбирает ошибки после запуска.
Поддержку тоже оценивайте через ситуацию. Например, данные перестали поступать из сайта. Куда отправить обращение? Кто проверяет сам сервис, а кто ваш коннектор? Какие обязательства и сроки реакции закреплены в условиях? Наличие кнопки чата не отвечает на эти вопросы.
В конце проверьте отмену подписки, автопродление и доступ после окончания оплаченного периода. Сохраните действующие условия и дату их проверки. Так у команды останется основание для решения, если позже изменятся тариф или потребности.
Как проверить данные, права и возможность уйти из сервиса
Мы советуем провести небольшой пилот на согласованном наборе данных. Его цель: пройти реальную работу целиком. Для первичной проверки не обязательно сразу загружать всю клиентскую базу.
Начните с записи, у которой есть не только название, но и связи: ответственный, несколько полей, вложение и история действий, если она нужна процессу. После импорта проверьте, что сохранилось, что изменилось и что не перенеслось. Зафиксируйте ограничения до массовой миграции.
Далее попросите будущего сотрудника выполнить обычное действие под его ролью. Видит ли он нужную запись? Может ли изменить её? Получает ли лишний доступ к другим отделам? Проверка из аккаунта владельца не заменяет проверку ограниченных прав.
Назначьте владельца рабочего пространства, определите порядок выдачи и отзыва доступа. Если сервис поддерживает второй фактор, используйте предусмотренные им способы и заранее подготовьте восстановление. Подробно этот вопрос разобран в статье о двухфакторной защите аккаунтов команды.
Теперь сделайте экспорт. Откройте полученные файлы, проверьте поля, связи и вложения из контрольного набора. Кнопка «Скачать» подтверждает только запуск действия; пригодность выгрузки определяется содержимым. Если историю переписки или часть вложений забрать нельзя, это существенное условие выбора.
Экспорт не следует автоматически считать полноценной резервной копией. Выясните, что позволяет восстановить сервис, за какой период и на каких условиях. Отдельно определите, как команда продолжит работу при временной недоступности приложения. Возможности автономного режима, если он есть, нужно проверять у конкретного продукта.
Последний шаг пилота: прекратить тестовое использование предусмотренным способом. Кто отключает интеграции, кто получает данные, когда заканчивается доступ и как оформляется удаление информации? Не проверяйте необратимое удаление рабочей базы ради эксперимента. Достаточно изучить условия и проверить доступные действия на согласованном тестовом наборе.
Результатом должен стать короткий протокол: выполненный сценарий, обнаруженные ограничения и решение по каждому из них. Тогда обсуждение «нравится или не нравится» превращается в понятный выбор.
Если вы хотите создать собственный SaaS
Разработка своего сервиса начинается с другой задачи. Вы становитесь поставщиком и должны организовать не только интерфейс, но и постоянную работу продукта. Проверку первоначальной гипотезы мы рассматриваем отдельно в материале о MVP и проверке спроса.
Для SaaS опишите клиента: человек, команда или организация. Далее разберите путь от регистрации до прекращения использования. В каких состояниях находится подписка? Что происходит после успешной оплаты, ошибки платежа, смены тарифа или окончания периода? Какие действия доступны пользователю в каждом случае?
Например, компания перестала оплачивать сервис. Нужно заранее решить, сможет ли её администратор выгрузить данные, как увидит ограничение и какие сообщения получит. Это вопросы к проектированию вашего продукта; ответ нельзя взять из названия модели.
Разделение клиентов проверяйте как самостоятельное требование. Участник одной организации не должен получать сведения другой через интерфейс, API, поиск или выгрузку. Один общий экран со списком организаций ещё не подтверждает корректность разграничения доступа.
Перед запуском согласуйте эксплуатацию: кто получает сигнал об ошибке, отвечает клиенту, выпускает обновление и проверяет восстановление. Поддержка и резервирование должны иметь ответственных и понятный порядок работы. Обещания в тарифе нужно связывать с тем, что команда действительно готова обеспечивать.
При создании веб-сервиса для клиентов мы предлагаем обсуждать весь этот путь вместе с функциями. В Гуси-Лебеди считаем полезным проверять результат через работу клиента: он понимает условия, получает нужный доступ и может распоряжаться своими данными предусмотренным способом. Это и есть основа управляемого продукта по подписке.