Два клиента записались на одно время: что предусмотреть в бронировании на сайте

Свободное время увидели оба клиента

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

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

Почему красивый календарь ошибается

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

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

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

Что именно занимает интервал

Услуга, подготовка и ресурс

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

У готовых систем такие настройки разделены. В Microsoft Bookings длительность называется Duration, а время до и после встречи — Buffers. Расписание доступности задаётся через Schedule customization. Эти названия показывают, что речь о разных параметрах, а не о единой продолжительности. Копировать интерфейс Bookings для собственного сайта необязательно. Полезно сохранить различие между длительностью услуги и полной занятостью ресурса.

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

Граница доступной записи

В той же документации Minimum Lead Time задаёт минимальное время между бронированием и началом встречи, а Maximum Lead Time — предельную глубину записи вперёд. Для бизнеса это вопросы подготовки и надёжности будущего расписания. Если услуга требует материалов, обещать ближайшее окно без времени на подготовку рискованно. Если график ещё не утверждён, дальняя запись создаёт обязательство на неизвестную смену. Лучше открыть действительно доступный период, чем потом массово переносить клиентов.

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

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

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

Последняя проверка перед сохранением

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

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

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

Повтор отправки и оплата создают другие ошибки

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

Такой подход называют идемпотентностью. В документации Stripe описан ключ Idempotency-Key, по которому сервис узнаёт повтор запроса. Это пример принципа, а не требование подключать именно этот платёжный сервис. В вашем проекте исполнитель показывает, как связаны первая отправка и повтор. Отдельно он объясняет, чем повтор отличается от осознанного создания новой записи тем же человеком. По отдельным результатам сотрудник поймёт, нужно ли разбирать платёж, запись или оба события.

Срок удержания времени

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

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

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

Отмена, перенос и закрытие смены

Перенос сохраняет связь со старой записью

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

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

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

Проверка перед публикацией

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

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

Что останется, если исправить только календарь

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

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