Когда хватит готовой системы, а когда нужна разработка
Сначала проверьте готовый сервис или виджет, если вы сдаёте зал по времени, указываете цену, принимаете предоплату и администратор заносит телефонные брони в тот же календарь. Это не компромисс «для маленького бизнеса»: у готовых продуктов уже могут быть разные объекты, длительности, оборудование и уведомления. Например, Booking Flow описывает залы, календарь, предоплату и виджет, а MySlot описывает ресурсы, оборудование, вместимость и разные сроки аренды. Проверяйте нужные функции на демо и в условиях выбранного продукта, а не по общему списку на сайте.
Свою систему стоит проектировать, если один заказ занимает несколько общих ресурсов, цена зависит от сложных условий договора, брони приходят из разных каналов без общего источника занятости или отмена должна согласованно изменить оплату, расписание и учёт. Например, две переговорные могут быть свободны, но обе заявки требуют один проектор. Если готовая платформа не умеет блокировать проектор для одной из них, красивый календарь не решает конфликт.
Для простого запроса «выбрать дату и прислать заявку» может хватить формы без мгновенного обещания брони. Разница важна: заявка ждёт подтверждения сотрудника, бронь обещает конкретный ресурс и интервал. Не называйте отправку формы подтверждением, если команда ещё должна проверить доступность вручную.
Что мы уже делали в сценарии записи
В приложении для студии маникюра мы собрали путь от выбора услуги и мастера до времени, подтверждения и истории визитов. Клиент видит своё решение до отправки, а после записи может к нему вернуться. Экраны ниже показывают именно этот пользовательский путь.
Реальный проект 13FOX
Выбор времени заканчивается подтверждением
В нашем проекте человек выбирает услугу, мастера и время, затем видит результат записи. Для аренды зала к этому пути добавляются общие ресурсы, вместимость и правила оплаты.
Если вы сдаёте помещения, полезно сохранить такой же понятный итог для клиента: какой объект, на сколько времени, что входит в бронь и что оплачено. Но подтверждение нельзя показывать раньше, чем система действительно закрепила зал и оборудование. Далее разберём, где проходит эта граница.
Бронируется не слот, а набор ресурсов
Представьте фотостудию: клиенту нужен зал А, общий световой комплект и время на подготовку. Календарь зала А может быть пустым, но комплект уже взял зал Б. Если считать доступность только по залу, обеим группам обещают одно оборудование. В карточке предложения перечислите каждый ограниченный ресурс и его связь с заказом: зал, прибор, человек сопровождения, технический перерыв.
Вместимость требует отдельного решения. Для брони целого зала число гостей ограничивает выбор зала; для экскурсии или группового занятия несколько клиентов могут разделить одну сессию, но суммарное число мест не должно превысить лимит. Длительность аренды тоже состоит не только из времени клиента: уборка и подготовка могут закрывать соседний интервал. Запишите эти правила до выбора интерфейса.
Если объекты находятся в разных часовых поясах, в карточке каждого фиксируйте местное время площадки. Клиент и администратор должны видеть одно и то же начало; при переводе часов систему проверяют отдельно. В обычной фотостудии одного города это проще, а в сети площадок становится частью проекта.
Когда слот занят: бронь, оплата и отмена
Самая частая неопределённость возникает между нажатием «Забронировать» и подтверждением оплаты. Если закрыть время навсегда при первом клике, календарь заполнится неоплаченными заявками. Если не закрывать вовсе, второй клиент может оплатить тот же ресурс. Нужен понятный временный резерв: сколько он живёт, что видит клиент, что происходит при отказе оплаты и кто помогает при исключении. Срок задавайте под свой процесс, не копируйте чужое значение без проверки.
Платёж может подтвердиться после того, как человек закрыл страницу. ЮKassa описывает уведомления о смене статуса платежа, которые приходят отдельно от действий клиента. Поэтому экран «успешно» не должен быть единственным доказательством оплаты. Если резерв уже истёк и ресурс отдали другому, позднее подтверждение оплаты нельзя превращать во вторую бронь. Клиент видит статус «требует проверки» и получает уведомление. Сотрудник проверяет платёж и предлагает другое доступное время или решает вопрос возврата по заранее показанным условиям. При повторной отправке запроса к платёжному сервису используют один и тот же ключ операции; ЮKassa описывает это правило. Для клиента главное, чтобы повторный сигнал об одном платеже не создал вторую бронь.
Отмена имеет два результата: освобождение ресурса и расчёт денег. Их не стоит скрывать за одной кнопкой. Администратор и клиент должны видеть, до какого момента разрешена отмена по вашим условиям, что произойдёт с платёжной операцией и когда слот снова доступен. ЮKassa поддерживает полный и частичный возврат через своё программное подключение, но правила возврата определяете вы и выбранная модель продаж. Покажите условия до оплаты и сохраните их в заказе.
Как сравнить виджет и собственную систему
Попросите показать не идеальную демозапись, а ваш путь: клиент на сайте выбирает зал и оборудование, администратор одновременно принимает телефонную бронь, затем один из заказов отменяется. Если продукт проводит этот путь без ручного переноса и с ясными статусами, разработка с нуля может не понадобиться. Если после демо менеджер всё равно ведёт «настоящий» календарь в таблице, уточните, какое правило платформа не покрыла.
| Проверка | Готовый сервис | Своя система |
|---|---|---|
| Зал и общее оборудование | Покажите одну покупку комплекта и отказ второй при общем приборе | Опишите ресурсы и закрепите весь комплект как одну операцию |
| Сайт и телефон | Администратор добавляет ручную бронь в тот же календарь | Все каналы пишут в один источник доступности |
| Оплата и отмена | Проверьте состояния ожидания, отказа и возврата на демо | Согласуйте статусы заказа, платежа и время освобождения |
| Данные и поддержка | Проверьте экспорт, тариф, доступ команды и поддержку | Планируйте размещение, мониторинг, резервные копии и сопровождение |
Не требуйте от собственной разработки всего сразу. Иногда достаточно встроить готовый виджет в сайт и наладить работу администратора; иногда нужен отдельный модуль поверх существующей CRM. Заказное решение оправдано лишь теми ограничениями, которые вы показали на тесте.
Артефакт: матрица конфликтов для вашего ТЗ
Представьте: на сайте зал Б ещё свободен. Клиент добавляет проектор и нажимает «Продолжить», а администратор в тот же момент оформляет зал А с этим проектором по телефону. Система должна заметить общий прибор до двух подтверждений: одному заказу закрепить комплект, второму показать занятость и предложить другое время или состав аренды.
Скопируйте матрицу ниже или скачайте CSV для поставщика. Замените вымышленные зал А и проектор вашими объектами. Для каждой строки зафиксируйте, что видит клиент и что видит администратор. Если оба канала создают подтверждение одному ресурсу, в смете нужна работа над общим источником занятости и защитой от одновременных запросов.
| Событие | Ресурс и правило | Ожидаемый исход | Что проверить |
|---|---|---|---|
| Сайт и телефон одновременно выбирают зал А | Один зал, пересекающиеся интервалы | Подтверждается только одна бронь; второму клиенту предлагают другое время | Календарь администратора и оба сообщения клиентам; технический журнал запросите у поставщика отдельно |
| Зал А и зал Б запрашивают один проектор | Общий прибор должен быть свободен для всей аренды | Второй заказ без прибора или с другим вариантом | Комплект ресурсов у каждой брони |
| Группа больше вместимости зала | Лимит относится к выбранной площадке | Система не обещает этот зал, показывает подходящий | Сайт и ручной ввод администратора |
| Временный резерв истёк, затем пришёл платёж | Освобождённый зал мог занять другой клиент | Нет второй брони; клиент видит «требует проверки» и получает уведомление | Номер заказа, альтернативное время или возврат по правилам; повторный сигнал не меняет исход |
| Клиент отменяет подтверждённую бронь | Условия отмены и платёж идут отдельно | Календарь и денежный статус меняются согласованно | Повторное открытие слота, уведомление и возврат по вашим правилам |
Мы прогнали эти правила на небольшом демонстрационном наборе без реальных клиентов и платежей. Он проверил, что зал и проектор не обещаются дважды, лимит мест не обходится, а поздний сигнал оплаты не подтверждает уже освобождённый резерв. Это полезная модель для разговора, но не нагрузочный тест будущей системы и не доказательство поведения выбранного платёжного сервиса.
На сервере конфликт нельзя решать только повторной проверкой календаря в браузере. Между показом свободного времени и созданием брони другой человек может занять слот. Например, PostgreSQL описывает ограничение непересекающихся интервалов для одной комнаты. Конкретную реализацию выбирает техническая команда, а вы в приёмке проверяете результат: одна подтверждённая бронь на один ресурс и интервал.
Из чего складывается стоимость
Если подрядчик оценивает только экран календаря, спросите, где в смете ресурсы, правила и исключения. Отдельные части работы: описание объектов и расписания; интерфейс выбора и итоговой цены; рабочее место администратора; временный резерв и защита от конфликтов; платёжные статусы, отмена и возврат; уведомления; связь с сайтом, CRM или учётом; тесты, запуск и поддержка. Для сети добавятся роли площадок, общие ресурсы и переносы между адресами.
Постоянные расходы могут включать тариф готового сервиса либо размещение своего приложения, платёжного провайдера, уведомления и сопровождение. Сравнивайте две оценки на одном наборе объектов, каналов и матрице выше. Назвать «среднюю цену системы бронирования» без этого состава было бы бесполезно: виджет одного зала и система аренды нескольких площадок решают разную задачу. Для общего веб-продукта поможет также разбор состава сметы веб-приложения.
Как принять первую версию
Проведите один полный путь как клиент и как администратор. Сначала выберите зал, оборудование, интервал и количество гостей; увидьте полную сумму и условия отмены до оплаты. Потом одновременно отправьте вторую бронь того же зала с другого устройства. На сервере должно остаться одно подтверждение, а второй человек должен получить понятный отказ или альтернативу, не «успешно» с конфликтом внутри.
- Добавьте телефонную бронь через администратора и убедитесь, что сайт тут же перестал обещать тот же интервал.
- Проверьте общий проектор, даже если залы разные. Система должна учитывать все части заказа.
- Прервите платёж, дождитесь освобождения временного резерва и попробуйте занять слот снова. Позднее подтверждение старого платежа не должно создать вторую бронь.
- Отмените оплаченную бронь и проверьте календарь, уведомление, платёжный статус и маршрут сотрудника. Не считайте одно письмо клиенту завершением отмены.
- Закройте зал на обслуживание, измените его вместимость, проверьте соседние интервалы с техническим перерывом.
В журнале администратора должны быть видны номер заказа, канал, ресурс, время, статус оплаты и причина исключения. Если после сбоя сотруднику приходится угадывать, чью бронь считать настоящей, первый выпуск ещё не готов. Эти проверки можно приложить к договору как измеримый результат.
Частые вопросы
Когда достаточно готового виджета бронирования?
Когда выбранный сервис на ваших объектах правильно учитывает длительность, вместимость, общие ресурсы, ручные брони, оплату и отмену. Проверьте этот путь на тестовых заявках из разных каналов до заказа собственной системы.
Как не допустить двойной брони?
Все каналы должны обращаться к одному источнику занятости, а сервер повторно проверять и закреплять нужные ресурсы в момент создания брони. Открытый календарь без такой проверки не защищает от двух одновременных запросов.
Считать ли слот занятым до оплаты?
Это правило бизнеса. Обычно нужен временный резерв с понятным сроком; после подтверждения платежа он становится бронью, а после отказа или истечения освобождается. Если оплата пришла слишком поздно и слот уже занят, клиент должен увидеть статус «требует проверки» и получить сообщение с дальнейшими действиями.
Из чего складывается стоимость системы бронирования?
Из модели ресурсов и расписания, клиентского пути, рабочего места администратора, интеграции оплаты и каналов, правил отмены, проверки конфликтов, запуска и дальнейшей поддержки. Сметы сравнивают по одной матрице сценариев, а не по цене календаря.
Источники
- Booking Flow: функции готового сервиса для залов и MySlot: аренда площадок и оборудования, проверено 23.09.2026; сведения об их собственных продуктах.
- PostgreSQL: технический пример запрета пересечения интервалов, проверено 23.09.2026.
- ЮKassa: уведомления о статусах, повторные запросы и возвраты, проверено 23.09.2026.
Разберём ваш сценарий бронирования
Оставьте номер для короткого разговора. На нём расскажите об объектах, каналах заявок и правилах оплаты и отмены; обезличенный пример заказа можно передать позже. Мы разложим одну бронь на ресурсы и статусы, проверим готовый сервис и составим сценарий для оценки разработки, если она понадобится.
После разбора у вас останутся вопросы для демо и сравнения смет.