Человек записался через приложение в автосервис на пятницу, 11:00. Получил подтверждение, приехал — мастерская его не ждёт. Приложение сохранило заявку, а время никто не подтвердил.

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

Требование «после нажатия показать успешную запись» в таком продукте можно выполнить идеально. Оно просто проверяет слишком мало.

До разработки бизнес и мастерская должны определить, кто вправе закрепить время, когда должен прийти ответ и что делать при задержке. Может ли мастерская заменить 11:00 на 13:00 без согласия клиента? Кто разбирает случай, когда приложение подтверждает запись, а мастерская её не видит? Это решения о работе сервиса, которые нельзя оставить разработчику вместе с задачей нарисовать галочку.

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

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

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

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

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

Полный разбор с примером требования и событиями для проверки — ArkTelos Lab. ArkTelos · Lab RU · Lab EN · ArkTelos RU · ArkTelos EN.