Концепт «Развоз»

Заказ и отправление связаны, но не смешаны. Магазин видит расчёт, подтверждение и причину, по которой операция требует сверки.

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

О заказчике

• Сценарий: Многоместный заказ и восстановление результата обмена
• Участники: Оператор магазина, склад и клиентская поддержка
• Первая версия: Один логистический продукт, склад и маршрут оформления
• Данные: Условные перевозчики, учебные упаковки, реальных заявок нет

Задача

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

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

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

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

Старая стоимость остаётся после изменения заказа

Расчёт связан с версией состава и упаковки.

Ответ потерян после создания

Операция направляется на сверку с устойчивым идентификатором.

Часть заказа принята за весь заказ

У каждого отправления самостоятельное состояние.

Ручное оформление создаёт дубль

Внешний номер связывается с заказом и согласованным источником.

Решение

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

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

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

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

1. Упаковки. Состав товаров, размеры и версия расчёта. Зачем: Оценка не отрывается от фактического отправления.
2. Варианты. Условный тариф и условия для текущего состава. Зачем: Предварительный расчёт не выдаётся за перевозку.
3. Отправления. Номера и состояния отдельных частей заказа. Зачем: Частичное завершение остаётся видимым.
4. Сверка. Операция, потерянный ответ и найденный результат. Зачем: Повтор не создаётся без проверки основания.

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

Пересчёт по причине

Изменение упаковки объясняет, почему прежнее предложение больше не актуально.

Один заказ, несколько состояний

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

Сверка вместо догадки

Потерянный ответ не отображается как обычный отказ.

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

Пересчитать упаковку

Обновить предложение после изменения состава.

На входе: В заказ добавлено крупное место.

1. Проверить состав.
2. Уточнить размеры.
3. Запросить новый расчёт.
4. Проверить применимость варианта.

На выходе: Выбран вариант для актуальной упаковки.

Если что-то пошло не так: Вариант недоступен: прежняя оценка не остаётся действующей.

Критерий приёмки: Сервер не принимает устаревший расчёт для нового состава.

Найти результат попытки

Не создавать перевозку повторно вслепую.

На входе: Ответ на создание не дошёл до магазина.

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

На выходе: Одна внутренняя операция соответствует нужному внешнему результату.

Если что-то пошло не так: Результат пока неизвестен: требуется уточнение, а не сообщение об успехе.

Критерий приёмки: Повтор после сверки не создаёт лишнее отправление.

Показать частичное завершение

Сохранить видимость оставшейся части.

На входе: Одна упаковка получена, другая ещё в пути.

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

На выходе: Общий заказ остаётся незавершённым в нужном объёме.

Если что-то пошло не так: Запоздавшее событие не отменяет более новое подтверждение без правила.

Критерий приёмки: Завершение частей соответствует сохранённой таблице статусов.

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

Оператор

Оформить перевозку по актуальным данным.

Что уже подтверждено и можно ли повторять?

Склад

Передать фактический состав мест.

Как связаны товары и упаковки?

Поддержка

Объяснить состояние каждой части покупателю.

Какая часть заказа ещё не завершена?

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

Владелец данных

Источник заказа, упаковок и транспортных событий согласуется до разработки.

Адаптер сервиса

Поля, подтверждения и отмены реализуются по API конкретного логистического продукта.

Повторы и журнал

Операция сохраняет идентификатор и результат; неоднозначность требует предусмотренной сверки.

Эксплуатация

Контроль зависших записей и инструкция ручного обхода входят в передачу интеграции.

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

• Модель заказа и упаковок
• Расчёт и создание для одного продукта доставки
• Статусная модель и обработка повторов
• Сверка и рабочее место ошибок

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

1. Карта обмена: определяем владельцев заказа, упаковок и внешних событий.
2. Контракт: фиксируем API выбранного продукта, поля и таблицу статусов.
3. Реализация: связываем расчёт и отправления устойчивыми идентификаторами.
4. Испытания: проверяем таймаут создания, частичное завершение и ручную сверку.

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

• Актуальный расчёт — Изменение адреса или места отменяет применимость прежней оценки.
• Отсутствие слепого повтора — После таймаута проверяется существование внешнего отправления.
• Частичная доставка — Завершение одной части не закрывает остальные.
• Восстановление связи — Ручной внешний номер связывается с той же внутренней операцией.

Стек

API перевозчика, Очередь операций, Статусная модель, Журнал обмена.

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

Интерфейс и рабочие состояния

Три настольных состояния и мобильный экран авторского интерактивного прототипа. Содержание вымышленное; реальный сервер, внедрение и бизнес-результаты не заявляются.