# Онлайн-запись: интервалы, отмены и защита от двойного бронирования

Источник: https://quicklanding.ru/knowledge/booking-system-rules/

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

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

## Назовите ресурс, который бронируется

![Занятие йогой как пример услуги по предварительной записи](/assets/images/knowledge/booking-system-rules.webp)

Это может быть конкретный специалист, стол, кабинет или место в группе. У группового занятия есть вместимость, у индивидуального приёма обычно один клиент на интервал. Иногда нужны сразу несколько ресурсов, например мастер и оборудованный пост.

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

## Определите, когда запись считается подтверждённой

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

| Состояние | Что видит посетитель |
| --- | --- |
| Запрос принят | Время требует подтверждения |
| Резерв создан | Условия и срок сохранения резерва |
| Запись подтверждена | Дата, услуга и способ изменения |
| Отмена выполнена | Подтверждение отмены и дальнейшие действия |

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

## Защитите сохранение от одновременных действий

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

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

## Согласуйте отмены и изменение времени

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

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

## Подготовьте работу администратора

Сотруднику нужны просмотр расписания, закрытие времени, изменение записи и объяснение конфликтов. История помогает понять, кто перенёс встречу и когда отправили уведомление. Не собирайте в журнале лишние личные сведения ради удобства диагностики.

При недоступности внешней системы выберите безопасный режим: запрос сотруднику или временная остановка автоматического подтверждения. Публикация старого календаря как актуального создаёт ложные ожидания. Посетитель должен получить понятный способ продолжить обращение.

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

## Документация и проверка сведений

Технические сведения сверены с документацией на 7 октября 2026 года. При настройке конкретного сервиса проверьте его текущую версию и действующие инструкции.

- [MDN: создание формы](https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Your_first_form)
- [OWASP: проверка прав доступа](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)

## Материалы по соседним задачам

- [Личный кабинет клиента: какие функции нужны в первой версии](/knowledge/client-portal-scope/)
- [Техническое задание на сайт: как описать результат без лишней документации](/knowledge/website-specification/)
- [Сервисы записи и бронирования](/services/development/apps/booking/)

## Частые вопросы

### Достаточно ли отключить кнопку после первого нажатия?

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

### Можно бронировать группу, а не конкретного человека?

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

### Что делать, если платёж пришёл после истечения резерва?

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

Автор: Владимир Николаев