От запроса ставки
до подтверждённой доставки.

Сайт логистической компании должен объяснять, что и куда она перевозит. Карта дополняет перечень направлений, а не заменяет его. Для сложного груза показываем требования к упаковке и составу заявки. В кабинете важнее понятное отклонение от плана и контакт ответственного, чем декоративное движение машин по карте.

На этапе проектирования фиксируем примеры экранов и ожидаемые действия пользователя. Для каждого решения указываем, какие сведения редактирует команда, какие получает из другой системы и кто отвечает за их актуальность.

Проверяем перед запуском: Новый посетитель находит нужное направление и следующий шаг на телефоне.

В рабочем сценарии последовательно связаны этапы: Параметры груза → Выбор ресурса → Проверка ограничений → Заявка диспетчеру. Каждый переход имеет исполнителя, входные данные и видимый результат. До разработки разбираем нормальный маршрут, возврат на исправление, отмену и повторное действие. Статус в интерфейсе должен отражать подтверждённое состояние, а не просто факт нажатия кнопки.

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

Заявка связывает отправителя, получателя, точки маршрута, грузовые места, вес, объём и окно доставки. Массу и объём проверяем независимо: свободное место в кузове не означает допустимую нагрузку. Плановые и фактические события храним отдельно. Время показываем с согласованным часовым поясом, а изменённый маршрут сохраняет историю.

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

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

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

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

Проверяем перед запуском: Недоступность источника не отображается как подтверждённый успех.

Для длинных операций показываем, что запрос принят, и сохраняем идентификатор результата. Повтор после потери связи не создаёт второй объект. Ошибки разделяем на исправимые пользователем и требующие специалиста; введённые данные сохраняются в пределах согласованных правил. Состояния «пусто», «загрузка», «нет доступа» и «сервис недоступен» проектируем до вёрстки, а не после запуска.

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

Структуру строим по направлениям, видам перевозки, типам груза и складам. Формы собирают параметры, необходимые для расчёта, вместо свободного поля «опишите всё». Предварительную ставку отделяем от подтверждённого предложения. Аналитика связывает источник заявки с её качеством и результатом обработки, а не только с нажатием кнопки.

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

Первый релиз включает законченный маршрут «Параметры груза → Заявка диспетчеру», необходимые страницы и редактируемые поля. На тестовом контуре проверяем мобильную версию, роли, формы, документы и ошибки интеграции. Перед переключением сохраняем исходное состояние и фиксируем порядок отката. Команде передаём инструкции редактора, схему обмена и перечень проверок для следующих обновлений.

Проверяем перед запуском: Восстановление проверено на копии, редактор умеет менять поля без разработчика.