Mini App перед подтвер­ждением: как не потерять выбранный вариант на последнем шаге

Последняя кнопка знает меньше, чем кажется

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

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

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

Выбрано, проверяется и подтверждено – три разные вещи

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

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

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

Подтверждать должен тот, кто отвечает за условие

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

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

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

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

Изменение не должно стирать выбор

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

Покажите изменившееся рядом с выбранным. Например: «Вы выбрали 17:00. Это время уже проверяем. Если оно занято, предложим ближайшее». Или: «Вариант сохранён, стоимость уточняется перед ответом». Человек узнаёт свой путь и сразу понимает, какая часть требует нового решения.

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

Здесь легко переборщить с подробностями. Человеку не требуется список всех причин, по которым условие могло поменяться. Достаточно одного наблюдаемого факта и действия рядом с ним. «Время занято, выберите соседнее» полезнее длинного объяснения. «Стоимость проверяется, отправим ответ сюда» полезнее декоративной загрузки без смысла.

Один последний шаг можно проверить до макетов

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

Теперь проведите путь пальцем. Что увидит человек перед финальной кнопкой? Кто отвечает после неё? Что произойдёт, если один пункт из второй колонки изменится? Зачеркните красным любое слово, которое обещает готовый ответ раньше, чем он появляется. Упражнение занимает несколько минут и хорошо показывает, нужен ли отдельный экран.

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

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

Экран перед подтверждением нужен не всегда

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

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