Запись через Telegram-бота удобна, пока расписание свободно. Настоящая проверка начинается, когда два человека выбирают одно время, сотрудник меняет длительность услуги, а клиент возвращается к старому сообщению для переноса. Если бот лишь показывает список часов, он ещё не обеспечивает корректное бронирование.
Нужен единый источник расписания и понятные состояния записи: выбранный вариант, подтверждённая встреча, перенос и отмена. Telegram предоставляет интерфейс общения, а занятость ресурсов и правила сохранения реализует ваше приложение. Ниже разобран процесс для услуги с конкретным исполнителем и длительностью, без обещания готовой календарной функции платформы.
Определите, что именно занимает время
Один слот может зависеть от сотрудника, кабинета, оборудования или нескольких ресурсов одновременно. До создания кнопок опишите это ограничение. Если мастер свободен, но нужное помещение занято, время не является доступным. Иначе оператору придётся вручную отменять записи, которые интерфейс объявил подтверждёнными.
У услуги есть длительность и, возможно, технический промежуток между встречами. Эти значения должны учитываться источником расписания. Не формируйте кнопки только по круглым часам, если услуга длится дольше интервала. Также определите, кто вправе менять длительность и как изменение влияет на уже подтверждённые встречи.
Сохраните время в согласованной форме и показывайте клиенту понятный часовой пояс. Для дистанционной консультации участники могут находиться в разных регионах. Подпись «завтра в десять» недостаточна для подтверждения: рядом нужны дата и зона либо другой однозначный ориентир, соответствующий вашему процессу.
Разделите просмотр и подтверждение
Показанный список отражает доступность в момент запроса. Пока пользователь читает сообщение, свободное время может занять другой клиент. Поэтому окончательное сохранение проверяет актуальное состояние ещё раз. Наличие кнопки в истории не означает, что слот зарезервирован навсегда за человеком.
Если приложение временно удерживает выбранное время, объясните срок и состояние такого удержания. Не называйте его подтверждённой записью до выполнения нужных условий. После окончания удержания человек должен получить актуальные варианты, а не техническую ошибку без продолжения.
Перед финальным действием покажите услугу, дату, время, исполнителя при необходимости и последствия подтверждения. Если требуется дополнительный этап, например согласование администратором, обозначьте его явно. «Заявка на запись принята» и «встреча подтверждена» описывают разные результаты и не должны использоваться как синонимы.
Условный пример: консультация с переносом
Предположим, сервис предлагает дистанционную настройку программы. Клиент выбирает услугу и видит свободные интервалы одного специалиста. Он открывает вариант на четверг, но до подтверждения другой человек уже занимает это время. Сервер отклоняет устаревший выбор и предлагает обновлённый список, сохранив тему консультации.
После успешной записи клиент хочет перенести встречу на пятницу. Приложение показывает текущую запись и отдельное действие переноса. Новый слот проверяется заново. Если сохранение нового времени успешно, прежний освобождается по согласованной транзакционной схеме. При ошибке первоначальная встреча не должна пропасть без объяснения.
Это условный пример архитектуры. Bot API предоставляет сообщения и кнопки, но не выбирает календарь, не определяет рабочие ресурсы и не гарантирует атомарный перенос во внешней системе. Эти свойства нужно проверить в конкретной реализации бота и календарного сервиса.
Безопасный порядок переноса
Начните с проверки принадлежности записи и возможности изменения. Номер встречи в кнопке не подтверждает, что текущий пользователь вправе её переносить. Затем проверьте актуальное состояние: встреча может уже завершиться, быть отменена или изменена администратором после показа старого сообщения.
Правила сроков переноса должны быть понятны до выбора нового времени. Если изменение доступно только через сотрудника, бот предлагает этот путь вместо бесполезного списка вариантов. Не обещайте свободный перенос, когда внутренний процесс требует согласования или ограничен договорённостями услуги.
При взаимодействии с внешним календарём определите поведение неопределённого результата. Если новый слот сохранился, но ответ потерялся, повтор не должен создавать вторую встречу. Используйте поддерживаемые API-механизмы поиска результата и собственную запись операции. Не отменяйте исходный слот вслепую до выяснения состояния новой записи.
Повторы нажатий и старые сообщения
У подтверждения записи должен быть собственный идентификатор операции. Повторное нажатие возвращает текущий результат либо состояние обработки, а не создаёт ещё одну встречу. При этом другая самостоятельная запись того же клиента должна оставаться возможной, если это разрешено процессом.
После переноса старое сообщение может по-прежнему находиться в истории. Если человек нажмёт прежнюю кнопку, сервер сверяет версию записи. Ответ должен объяснить, что данные изменились, и показать актуальное состояние. Удаление или изменение клавиатуры улучшает интерфейс, но не заменяет эту проверку.
Отдельно проверьте одновременное действие администратора и клиента. Специалист мог закрыть запись для изменения, пока пользователь выбирает время. Нельзя отдавать приоритет последнему пришедшему запросу без проверки смысла. Правила версий и полномочий должны быть частью источника расписания.
Напоминание не равно подтверждение присутствия
После записи бот может отправлять предусмотренные сервисные напоминания в доступный диалог. Содержание должно соответствовать актуальному времени. Если встреча перенесена, отложенное старое сообщение отменяют либо проверяют его актуальность непосредственно перед отправкой. Иначе клиент получит два разных времени.
Успешная отправка напоминания не означает, что человек прочитал его или подтвердил участие. Если процесс требует явного подтверждения, предусмотрите отдельное действие и состояние ожидания. Не делайте вывод о согласии по одному техническому результату отправки сообщения.
При невозможности доставки используйте согласованный запасной порядок. Не ищите случайный похожий аккаунт по имени для передачи деталей встречи. Связь получателя и записи остаётся обязательной частью процесса, даже когда привычный канал временно недоступен.
Проверка расписания перед запуском
Испытайте обычную запись, два одновременных выбора одного слота, перенос и отказ календаря. Затем проверьте разную длительность услуг, границу рабочего дня и часовые пояса. Используйте тестовые встречи и отдельные ресурсы, чтобы проверка не занимала настоящее время специалиста.
Отдельный тест нужен для обновления расписания после выпуска новой версии. Уже подтверждённые записи не должны незаметно менять время из-за нового правила отображения. Сверьте серверное значение, клиентский текст и напоминание. Если они расходятся, сначала исправьте преобразование и источник данных, а не только подпись кнопки.
Приёмка завершается проверкой глазами администратора: видна ли запись в основном календаре, понятно ли её происхождение и можно ли корректно продолжить работу после сбоя? Полезный результат — одна подтверждённая встреча с однозначным временем и управляемым переносом, а не просто сообщение об успехе в Telegram.
Изменение доступности сотрудником
Администратор иногда закрывает часть расписания из-за болезни, задержки или другой рабочей причины. Определите, затрагивает ли изменение уже подтверждённые встречи. Удаление свободного интервала и отмена назначенного визита должны быть разными действиями. Иначе техническая правка календаря незаметно изменит договорённость с клиентом.
Если встречу нужно перенести по инициативе команды, сохраните прежние параметры и предложенное изменение. До подтверждения нового времени не показывайте его как уже согласованное. Для клиента должна оставаться ясная точка связи, особенно когда доступных вариантов несколько или требуется индивидуальное обсуждение.
На испытании возьмите тестовую встречу и закройте соответствующий ресурс в календаре. Проверьте список доступных слотов, карточку клиента, очередь напоминаний и интерфейс сотрудника. Все части должны отражать одно состояние. Затем восстановите доступность и убедитесь, что ранее отменённая запись не появляется снова сама собой. Это отдельный тест бизнес-логики, который не заменяется проверкой одной успешной новой записи.
Источники
Кнопки подтверждения описаны в Bot API: InlineKeyboardButton, события взаимодействия — в CallbackQuery. Календарь, удержание времени и перенос реализуются вашей системой отдельно от Telegram.