Концепт «Дар»: сертификат с понятной историей

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

Концепт-проект: «Дар» — вымышленная компания. Результатов работы здесь нет: только решения и гипотезы.

О заказчике

• Задача: Подарочный сертификат в интернет-магазине
• Участники: Покупатель, получатель, поддержка
• Источник остатка: Предлагаемый журнал операций
• Граница: Без реальных оплат и коммерческих обязательств

Задача

В учебном сценарии интернет-магазин добавляет электронные подарочные сертификаты. Покупатель и получатель — разные люди; подарок можно применить частично. После использования человеку важно понимать, что осталось, а сотруднику — почему возникло конкретное движение.

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

Риски исходного процесса

Письмо отправили, но подарок не найден

Выпуск и доставка разделены. Повтор письма использует существующий экземпляр, а не создаёт новый баланс.

Две корзины видят одинаковую сумму

В проектной модели показан доступный остаток и описано серверное согласование конкурентных действий.

Поддержка не понимает возврат

Каждое восстановление связано с исходным использованием. История не заменяется ручным редактированием числа.

Решение

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

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

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

Как устроен продукт

1. Карточка подарка. Маскированный номер, состояние, доступный остаток и ясные ограничения. Зачем: Человек не ищет смысл подарка в нескольких письмах и не путает его со скидкой.
2. Применение к заказу. Выбранная сумма и результат одной команды; неопределённый ответ требует проверки. Зачем: Повтор технической попытки не должен превращаться в новый расход.
3. История операций. Покупка, использование и восстановление соединены ссылками на основания. Зачем: Поддержка объясняет остаток по событиям и не додумывает причину вручную.
4. Доставка получателю. Отдельный статус и повтор отправки для уже выпущенного экземпляра. Зачем: Неудачное письмо не отменяет существование сертификата и не создаёт второй.

Что помогает пройти сценарий

Связанная команда

Локальный повтор показывает прежний результат и не списывает условный остаток снова.

Проверяемое восстановление

Возврат относится к исходному движению и выполняется в демонстрации один раз.

Понятная сумма

Состояние после использования отображается текстом и числом; ошибка не обозначается только цветом.

Ключевые сценарии

Применить часть

Получатель тратит часть учебного остатка.

На входе: Активный демонстрационный сертификат и один выбранный заказ.

1. Проверить доступную сумму.
2. Создать команду применения.
3. Прочитать результат и запись истории.

На выходе: Остаток уменьшен на сумму одной операции.

Если что-то пошло не так: Недостаточная сумма отклоняется; баланс не меняется.

Критерий приёмки: Изменение объясняется одной связанной записью.

Повторить команду

Ответ мог потеряться после принятия.

На входе: Первая операция уже подтверждена.

1. Повторить тот же идентификатор.
2. Сопоставить результат.
3. Проверить историю.

На выходе: Возвращён исходный результат.

Если что-то пошло не так: Другая сумма с тем же ключом должна отклоняться на сервере.

Критерий приёмки: Не появилось второго расхода.

Восстановить использование

Проверка демонстрационного возврата.

На входе: Есть одна операция применения.

1. Выбрать исходное движение.
2. Выполнить восстановление.
3. Повторить действие для проверки защиты.

На выходе: Создано одно связанное восстановление.

Если что-то пошло не так: Повтор не увеличивает остаток ещё раз.

Критерий приёмки: Итог объясняется исходной операцией и её восстановлением.

Роли пользователей

Получатель

Использовать подарок и понять, что осталось.

Какая сумма доступна для следующей покупки?

Поддержка

Разобрать спорное движение без раскрытия секретного кода.

С каким заказом связано изменение?

Владелец магазина

Согласовать правила применения и последующей сверки.

Какие исключения требуют ручного решения?

Как устроено технически

Серверный журнал

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

Согласованные подключения

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

Сверка и доступ

Нужны роли поддержки, история оснований, обработка зависших операций и план восстановления после простоя.

Что входит в разработку

• Один учебный сертификат
• Локальное применение и повтор команды
• Связанный демонстрационный возврат
• Схема выпуска и журнала
• Три сценария приёмки

План реализации

1. Обследовать правила применения, каналы и источники подтверждения.
2. Согласовать состояния, роли и модель движений.
3. Проверить интерфейс на примерах использования и возврата.
4. Реализовать сервер и подключения только после утверждения границ.
5. Провести конкурентные тесты, сверку и передачу инструкции.

Что замеряем после запуска

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

Стек

Серверный журнал, Согласованные подключения, Сверка и доступ.

Все кейсы · Услуга · Калькулятор стоимости