Перенос и лист ожидания без потерянных визитов

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

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

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

После нажатия переноса интерфейс может потерять ответ, хотя сервер уже выполнил действие. Покажите состояние «проверяем результат» и сохраните идентификатор операции. Повторный запрос сначала должен узнать состояние обеих записей. В приемке проверяйте не только отсутствие дубля, но и возможность сотрудника объяснить клиенту, какой визит сейчас действует. История должна связывать старое и новое время одной операцией.

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