Смена цен в онлайн-записи: новый прайс и действующие брони

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

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

Разделите данные услуги и данные заказа. Каталог отвечает на вопрос «какое предложение доступно сейчас», бронь — «что согласовано для этого визита». Удаление старой услуги тоже не должно лишать запись названия, длительности и стоимости, которые были важны при подтверждении.

Сначала письменно сформулируйте правило. Например, новый прайс применяется к новым бронированиям, созданным после определённого момента. Другой вариант — заранее опубликованный сезонный тариф для посещений начиная с конкретной даты. Это разные модели: одинаковая дата визита не означает одинаковый момент согласования условий.

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

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

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

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

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

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

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

На демонстрации MySlot попросите изменить цену тестовой услуги после создания брони и показать результат в календаре, уведомлении и оплате. Такой тест сразу выявляет, где используется сумма заказа, а где текущий каталог. Отдельно проверьте связанный процесс в CRM.

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