BRD Widget 3.2.1 Упрощенная регистрация в виджете
Направление работ: Widget Код раздела: 3.2.1 Раздел: Авторизация > Регистрация > Упрощенная регистрация в виджете Статус: черновик Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 11.08.26
1. Назначение
Раздел описывает сценарий упрощенной регистрации клиента в виджете при завершении бронирования без входа и полноценной регистрации.
Сценарий доступен, если партнер при настройке виджета выбрал формат работы виджета без регистрации. В этом случае на финальном шаге виджет запрашивает минимальные контактные данные клиента: имя, номер телефона и email.
Документ описывает только ввод и передачу контактных данных клиента. Оборудование, услуги, промокод, комментарий, оплата, согласие с правилами площадки, карточка заказа и итоговая стоимость относятся к соседнему разделу Widget: 5.1 Дополнительные позиции к заказу.
Раздел зависит от Back: 1.1.1 Регистрация и Back: 1.3 Клиенты.
2. Ключевые понятия
Упрощенная регистрация в виджете — сценарий, в котором клиент без входа в аккаунт указывает минимальные контактные данные на финальном шаге бронирования.
Регистрация — системный процесс, который принимает регистрационные данные, фиксирует источник регистрации и связывает данные с аккаунтом или карточкой клиента.
Карточка клиента — сущность с персональными и контактными данными клиента, которая может быть создана при бронировании в виджете без регистрации.
Контактные данные клиента — имя, номер телефона и email, которые клиент заполняет в виджете для продолжения бронирования без регистрации.
3. Scope
Входит
S1: Доступность упрощенной регистрации при бронировании без регистрации
S2: Ввод имени, номера телефона и email клиента
S3: Отображение пустого и заполненного состояния контактных данных
S4: Передача контактных данных в продолжение бронирования
Не входит
- Widget: 3.1 Авторизация > Вход
- Widget: 3.2 Авторизация > Регистрация
- Widget: 3.3 Авторизация > Восстановление пароля
- Widget: 5.1 Дополнения к заказу и подтверждение > Дополнительные позиции к заказу
- Back: 1.1.1 backend-логика регистрации
- Back: 1.3 backend-логика карточки клиента
4. BR
Указаны в пункте 4 разделов Back: 1.1.1 Регистрация и Back: 1.3 Клиенты.
5. Функциональные требования (UC + FR)
FR — functional requirements, что интерфейс должен уметь делать по определенному UC.
Вердикт по разделу: Не реализовано. Сценарий недостижим целиком: он открывается только из ветки «Пропустить» развилки идентификации, а самой развилки в виджете нет — см. Widget: 4.1, OQ4.1-1. Полей контактных данных на шаге оформления в коде не существует. Раздел реализуется одной задачей вместе с развилкой, см. OQ3.2.1-1.
| ID | Сценарий | Функциональное требование | BR | Вес | Статус |
|---|---|---|---|---|---|
| S1: #FR3.2.1-1 | Клиент завершает бронирование в виджете без входа и регистрации | Интерфейс показывает блок контактных данных на финальном шаге, если партнер выбрал формат работы виджета без регистрации (widgetFormat = WithoutRegistration). | 1 | Не реализовано | |
| S2: #FR3.2.1-2 | Клиент видит пустые контактные поля | Интерфейс показывает обязательные поля На чьё имя будет заказ*, Номер телефона* и Email*; продолжение недоступно, пока обязательные данные не заполнены. | 1 | Не реализовано | |
| S2: #FR3.2.1-3 | Клиент вводит имя | Интерфейс принимает имя клиента в поле На чьё имя будет заказ* и сохраняет введенное значение в поле. | 1 | Не реализовано | |
| S2: #FR3.2.1-4 | Клиент вводит номер телефона | Интерфейс принимает номер телефона в поле Номер телефона*, применяет формат телефонного номера и сохраняет введенное значение в поле. | 1 | Не реализовано | |
| S2: #FR3.2.1-5 | Клиент вводит email | Интерфейс принимает email в поле Email*, проверяет формат email и сохраняет введенное значение в поле. | 1 | Не реализовано | |
| S3: #FR3.2.1-6 | Клиент заполнил контактные данные | Интерфейс отображает введенные имя, номер телефона и email в соответствующих полях без перехода в отдельный экран регистрации. | 1 | Не реализовано | |
| S4: #FR3.2.1-7 | Клиент продолжает бронирование после заполнения контактных данных | Интерфейс передает имя, номер телефона и email в сценарий завершения бронирования без регистрации. По номеру телефона выполняется поиск существующей карточки клиента: если карточка найдена — заказ привязывается к ней; если не найдена — создаются аккаунт и карточка клиента с неподтвержденными телефоном и email, и заказ привязывается к ним. В создание заказа передается идентификатор клиента полученной или созданной карточки. | 1 | Не реализовано | |
| S4: #FR3.2.1-9 | Клиент бронирует повторно с теми же контактами | Повторное бронирование без входа не создает новую карточку клиента: заказ привязывается к ранее созданной карточке, найденной по номеру телефона, поэтому история заказов клиента у партнера остается единой. | 1 | Не реализовано | |
| S4: #FR3.2.1-8 | Клиент возвращается к предыдущему шагу | Интерфейс позволяет вернуться назад из финального шага без потери уже введенных контактных данных, если они были заполнены в текущей сессии. | 2 | Не реализовано |
6. Открытые вопросы
| ID | Источник | Вопрос | Кому | Статус |
|---|---|---|---|---|
| #OQ3.2.1-1 | Код | Требование говорит: при формате работы без регистрации клиент вводит имя, телефон и email на финальном шаге, и по ним незаметно создается карточка клиента. В коде ни блока контактных данных, ни самой ветки пропуска входа не существует. Раздел реализуется одной задачей вместе с развилкой идентификации — см. Widget: 4.1 OQ4.1-1. | Разработка | Закрыт |
| #OQ3.2.1-2 | Код / контракт | Что уточнено: для создания заказа достаточно идентификатора клиента — контакты в заказе не хранятся, они попадают в карточку клиента. Требуется подтвердить контракт упрощенной регистрации: каким методом создается карточка клиента по имени, телефону и email, что возвращается в ответе и как полученный идентификатор передается в создание заказа. Смежные разделы — Back: 1.1.1 Регистрация и Back: 1.3 Клиенты. Решение: сверку контракта выполняем перед стартом работ по развилке идентификации, сейчас не блокирует. Поведение уже определено в FR3.2.1-7 и FR3.2.1-9, остаётся сопоставить его с существующими методами. | Разработка | Закрыт |
| #OQ3.2.1-3 | Продукт | Подтвердить поведение при повторном бронировании: если клиент с таким телефоном или email уже существует, упрощенная регистрация создает новую карточку или переиспользует существующую. Решение: карточка переиспользуется. Сценарий целиком: клиент вводит имя, телефон и email → по этим данным ищется карточка клиента → если найдена, заказ вешается на неё → если не найдена, создаются аккаунт и карточка клиента с неподтвержденными телефоном и email, и заказ вешается на них по идентификатору клиента. Дубликаты карточек при повторных бронированиях не создаются. Требования зафиксированы в FR3.2.1-7 и FR3.2.1-9. | Бизнес | Закрыт |
| #OQ3.2.1-4 | Решение 11.08.26 | Уточнить у бэкенда правило поиска карточки: искать по телефону, по email или по любому совпадению, и что делать при конфликте — когда телефон принадлежит одной карточке, а email другой. От этого зависит, не привяжется ли заказ к чужой карточке при опечатке в контактах. Решение: поиск ведется по номеру телефона. Email в поиске не участвует, поэтому конфликт «телефон одной карточки, email другой» не возникает: телефон — основной идентификатор клиента, его вводят реже с ошибками и он не бывает общим. Зафиксировано в FR3.2.1-7 и FR3.2.1-9. | Разработка | Закрыт |