Как была создана SaaS-платформа для бронирования

Какую проблему должна была решить платформа?

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

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

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

Что мультитенантная архитектура означает на практике?

Каждый бизнес в ZapaziChas — отдельный клиент единой платформы. У него есть собственный профиль, сотрудники, услуги, расписания, бронирования и настройки. Его клиенты видят публичную страницу для записи с названием, цветами и адресом конкретного бизнеса.

Для доступа к странице можно использовать поддомен, например salon-maria.zapazichas.com, или собственный домен. Новый домен должен получить SSL-сертификат и начать вести на нужный профиль без ручного вмешательства команды.

Мы использовали подход shared schema в PostgreSQL. Данные хранятся в общей базе, но каждый запрос выполняется в контексте конкретного бизнеса. Это снижает инфраструктурные расходы и упрощает поддержку, но требует строгих проверок на уровне приложения и базы данных.

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

Как работает бронирование с точки зрения клиента?

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

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

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

Какие приложения и панели включает решение?

Веб-приложение для бизнеса

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

Публичная страница для записи

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

Мобильное приложение

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

Мы использовали React Native и Expo для iOS и Android. Единая кодовая база уменьшает дублирование между платформами, но не отменяет необходимость реального тестирования на разных устройствах, работы с push-уведомлениями и публикации в App Store и Google Play.

Какой технологический стек мы использовали?

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

Как организовать onboarding без обучения и ручных настроек?

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

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

1. 01
   Описание процесса

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

2. 02
   Модель данных

   Проектируем связи между компаниями, пользователями, услугами, ресурсами, расписаниями, бронированиями и платежами. На этом этапе также определяются правила изоляции между клиентами.

3. 03
   Основной сценарий бронирования

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

4. 04
   Автоматизация и интеграции

   Добавляем SMS-, email- и push-уведомления, платежи, домены и API-интеграции. У каждой интеграции должны быть обработка ошибок и отображаемый статус, а не просто кнопка, которая иногда не работает.

5. 05
   Мобильное приложение и аналитика

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

6. 06
   Тестирование и запуск

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

Сколько стоит такая SaaS-платформа?

Цена зависит от того, создаёте ли вы первую рабочую версию или продукт, который должен обслуживать множество независимых компаний. Для ориентира: MVP с базовым календарём, публичной записью, административной панелью и базовыми уведомлениями обычно стоит 15 000–35 000 евро. Полноценная SaaS-платформа с мультитенантной архитектурой, мобильными приложениями, платежами, доменами, ролями и аналитическим модулем может стоить более 40 000–90 000 евро.

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

Какие решения нельзя откладывать до конца?

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

Правила календаря. Услуга продолжительностью 30 минут с 10-минутным перерывом не рассчитывается как обычный свободный слот. Нужно также описать пограничные случаи: изменение рабочего времени, отсутствие сотрудника и перенос уже созданной брони.

Поведение при ошибках. Если SMS не отправлено или платёж не подтверждён, администратор должен знать, что произошло. Тихая ошибка приводит к пропущенному времени и недоверию к системе.

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

Что этот кейс показывает о вашем следующем программном продукте?

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

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

Для такой разработки актуальны разработка программного обеспечения на заказ, мобильное приложение для iOS и Android и интеграции API. Чтобы сравнить другие реализованные системы, вы также можете посмотреть портфолио.