Система онлайн-записи: расписание, слоты и отмены

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

Автор: Арнак Меликян, CTO, 404gen.

Система онлайн-записи начинается с обещания клиенту

Сначала определите, что именно получает человек после нажатия кнопки. Это может быть подтверждённое место, временное удержание до оплаты или только запрос на согласование. Эти результаты нельзя обозначать одной одинаковой надписью «Вы записаны». Если решение принимает администратор, клиент должен видеть статус ожидания и понимать, каким способом придёт подтверждение.

Опишите предмет записи: услуга, продолжительность, исполнитель, место и дополнительные условия. Часть параметров может определяться автоматически, но должна существовать в модели. Например, выбор специалиста влияет на доступные процедуры, а процедура — на необходимое оборудование. Если зависимости не зафиксированы, календарь начнёт предлагать формально свободное время, в которое выполнить обещанное невозможно.

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

Услуги, сотрудники и ресурсы

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

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

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

Рабочее расписание и исключения

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

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

Для обмена календарными событиями существует стандарт iCalendar, RFC 5545, который описывает события и повторения. Но поддержка формата файла сама по себе не делает внешний календарь источником истины для бронирования. В проекте отдельно решают, в каком направлении идёт обмен, какие события блокируют время и как обрабатывается задержка обновления.

Как рассчитывать доступные слоты

Слот — предлагаемый клиенту вариант начала услуги при конкретных условиях. Он не обязан быть постоянной строкой в базе: доступность можно вычислять по расписанию, занятым интервалам и выбранным параметрам. Важно, чтобы расчёт и подтверждение использовали согласованные правила. Иначе интерфейс покажет вариант, который сервер затем отклонит по другой логике.

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

Проверяйте границы интервалов. Если одна встреча заканчивается в момент начала другой, считается ли это пересечением? Нужен ли переход между помещениями? Какие правила действуют для записи через полночь? Ответы должны быть одинаковыми в публичном интерфейсе и в рабочем месте администратора. Создайте набор примеров на границах, чтобы обсуждать наблюдаемое поведение, а не абстрактную «корректность календаря».

Статусы записи и временное удержание

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

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

Защита от двойного бронирования

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

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

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

Оплата и запись: как связать два процесса

Перед подключением оплаты решите, когда возникает обязательство обслужить клиента. Варианты «сначала временно удержать время», «сначала принять запрос» и «подтвердить после оплаты» дают разный пользовательский опыт. У каждого варианта есть исключения: платёж задержался, клиент ушёл, подтверждение пришло повторно, ресурс уже освободили. Эти ситуации должны иметь понятное завершение.

Повторная отправка технического запроса не должна создавать независимую запись. Механизм идемпотентности на примере запросов описан в документации Stripe. Ссылка иллюстрирует подход, а не выбор платёжного провайдера для России. В самом продукте нужно согласовать, какое действие считается тем же самым и какие параметры нельзя менять в повторе.

Не подтверждайте оплату только по возвращению пользователя на страницу успеха. Надёжный статус получают из согласованного серверного канала провайдера и сверяют с записью. При спорном состоянии покажите «Проверяем оплату» и дайте безопасный способ продолжить. Подробный принцип защиты повторных операций разобран в статье об идемпотентности; здесь он связывается с жизненным циклом конкретного слота.

Перенос записи без потери старого места

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

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

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

Отмена, неявка и лист ожидания

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

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

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

Уведомления и подтверждение связи

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

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

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

Филиалы и часовые пояса

У записи должны быть однозначные момент времени и место оказания услуги. Для удалённой встречи полезно отдельно показать время клиента и исполнителя; для очного визита — время филиала. Нельзя полагаться только на настройки устройства: посетитель может находиться в поездке или иметь неверный часовой пояс на телефоне.

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

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

Рабочее место администратора

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

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

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

Интеграции и источник истины

Решите, какая система владеет записью и её статусом. CRM может хранить клиента, календарь — личную занятость, внутренний сервис — обязательства компании. Если все источники имеют равное право менять встречу без правил конфликтов, синхронизация станет непредсказуемой. Для каждого поля укажите владельца и допустимое направление обмена.

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

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

Интерфейс на телефоне и доступность выбора

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

Показывайте состояния без свободных вариантов: другой день, ближайшее время, лист ожидания или контакт администратора. Пустой календарь без объяснения выглядит как поломка. Отдельно проверьте загрузку, потерю связи и повторное открытие незавершённого шага. Человек должен понимать, существует ли уже запись и нужно ли повторять действие.

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

Границы первой версии

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

Составные услуги, групповые занятия, абонементы, несколько филиалов и автоматическая очередь могут появиться позднее. Однако их влияние на модель данных стоит обсудить заранее, если они уже входят в план развития. Не обязательно реализовывать всё сразу; важно не зафиксировать предположение «одна запись всегда равна одному человеку и одному сотруднику», если бизнес работает иначе.

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

Приёмочные сценарии перед запуском

Приёмка должна проверять не только счастливый путь, но и конфликтующие изменения. Подготовьте данные с занятым ресурсом, исключением из расписания, задержанной оплатой и переносом. Для каждого случая укажите ожидаемый статус записи, занятость ресурса, уведомление и действие сотрудника. Тогда результат можно воспроизвести и обсудить без субъективного «вроде работает».

• Два клиента одновременно подтверждают один доступный вариант.
• Администратор меняет расписание при открытой клиентской форме.
• Запрос повторяется после потери ответа сервера.
• Удержание истекает одновременно с подтверждением оплаты.
• Перенос не удаётся: прежняя запись остаётся в согласованном состоянии.
• Отмена прекращает напоминания и корректно освобождает ресурсы.
• Внешний календарь недоступен, затем обмен восстанавливается.
• Прямая ссылка показывает актуальное время в нужном часовом поясе.

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

Как оценивать пользу онлайн-записи

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

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

Для проектирования собственной системы в 404gen можно обсудить разработку веб-приложения и SaaS. Подготовьте примеры расписания, список ресурсов и правила отмены. Хорошая система онлайн-записи сохраняет ясное обещание клиенту при обычном сценарии, переносе и техническом сбое — именно это стоит закладывать в требования и проверять при приёмке.

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

Чем онлайн-запись отличается от формы заявки?

Форма передаёт запрос, после которого сотрудник уточняет возможность обслуживания. Онлайн-запись может сразу подтверждать конкретный ресурс и время, если правила это позволяют. Возможен и промежуточный вариант с ожиданием согласования. Важно обозначать результат точно: человек должен понимать, получил ли он место или только отправил пожелание, которое компания ещё проверяет.

Можно ли полностью полагаться на внешний календарь?

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

Как не допустить запись двух клиентов на одно время?

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

Нужна ли временная бронь до оплаты?

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

Что включить в первую версию сервиса?

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

Какие данные нужны для оценки разработки?

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

Источники и границы разбора

Первичные технические источники проверены 15 октября 2026 года. Они объясняют конкретные механизмы; проектные рекомендации нужно сверять с архитектурой и условиями эксплуатации. Иллюстрация обложки создана с помощью ИИ и не является снимком клиентского продукта. Учебные ситуации не описывают достигнутые результаты клиентов 404gen.

• PostgreSQL: диапазоны и ограничения пересечений
• IETF: календарные события iCalendar
• Stripe: идемпотентные запросы