Wildberries
Autoqueue
From manual vehicle coordination to a transparent yard management system.
B2B · Yard Management · Logistics · Operational UX · Decision Systems
I designed more than a vehicle table: I designed how control moves between an algorithm and a human operator.
Autoqueue evolved from a vehicle-calling interface into an operating model that combines automation, transparency, and safe human control.
The case in 60 seconds
Product
Autoqueue is part of a yard management system. It sequences vehicles for loading and unloading, selects the next vehicle for an available gate, and makes the current operational state visible to every participant.
Problem
A large part of the operation depended on manual coordination. Dispatchers checked vehicle readiness, maintained the queue, contacted drivers, and negotiated changes in chat. Context was fragmented across people and channels, while prioritisation decisions were not always transparent.
Solution
- A unified vehicle queue at route level.
- Automated dispatch with controlled human intervention.
- Vehicle pinning and a time-boxed editing session.
- Target ratios for direct and round-trip runs.
- An auditable history of actions and initiators.
- Role-based access for carriers.
- First-class handling of unavailable gates and other exceptions.
Core challenge: automate the standard flow without removing human control where the algorithm lacks context.
Context
One product decision affected drivers, dispatchers, carriers, warehouse teams, and the physical operation of loading gates.
A distribution yard handles vehicles with different routes, trip types, and readiness states. Before calling a vehicle, the system must evaluate more than arrival time: completed checks, route, compatible gates, trip type, and manual constraints all matter.
Vehicle journey
Arrival → preparation and tare check → queue → call → gate → operation complete.
Users
- Drivers need to understand their status, position, and expected call time.
- Dispatchers manage vehicle flow and resolve operational exceptions.
- Lead dispatchers oversee rules, operating modes, and team activity.
- Carrier operations teams track their own fleet.
- Warehouse teams need a steady, predictable flow through the gates.
The core tension was structural: drivers needed predictability, dispatchers needed flexibility, warehouses needed stable throughput, the business needed efficiency, and the system needed explicit rules.
Starting point
The manual process did not scale and left no single, reliable explanation of how decisions were made.
- Vehicle state was fragmented across the system, chat threads, and individual employees.
- Drivers could not always tell whether a request had been accepted or why another vehicle was called first.
- Dispatchers spent time synchronising context and answering recurring questions.
- Manual reordering did not reliably capture who changed the queue or why.
- Operational complexity grew with every additional vehicle, route, and gate.
The initial interface was gate-centric. It provided a high-level view of loading points, but constrained decision-making to a single piece of infrastructure.
Why FIFO was not enough
A vehicle's position depended on more than arrival time.
A vehicle might still be missing a required check, be incompatible with the available gate, follow a different route, belong to a direct or round-trip run, be pinned by a dispatcher, or wait for a gate to return to service.
The queue therefore had to be designed as a system of rules and states, not a sorted list.
Critical constraints
- Validate readiness before dispatch.
- Support multiple compatible gates for one vehicle.
- Coordinate automated and manual operating modes.
- Handle concurrent work by multiple dispatchers.
- Enforce role-based access and protect personal data.
- Retain an audit trail for every intervention.
- Safely drain an existing queue when automation is disabled.
From gates to routes
The route became the primary unit for managing vehicle flow.
As the product evolved, a gate proved too narrow a unit of control. A vehicle may be compatible with several gates, while the operational decision is made at route level.
The interface separated two levels of work: route-level monitoring and detailed control within a selected queue. Dispatchers could manage the vehicle flow as a whole instead of switching between isolated lists.
Automation with human control
The algorithm handles the standard flow; dispatchers retain control over exceptions.
In automated mode, the system calculates order from readiness, route, trip type, gate availability, and manual pins. Fully removing the operator was not viable: real-world yard operations regularly exceed the assumptions of the base algorithm.
A safe editing session
- The dispatcher explicitly enters manual mode.
- The session is limited to 20 minutes.
- Changes require confirmation.
- Individual actions can be undone.
- The system flags concurrent editing by another dispatcher.
- Control returns to the algorithm when the session ends.
Pinning a vehicle
A manual decision should survive the next automatic recalculation.
A dispatcher can pin an individual vehicle. Automation continues to manage the remaining queue without moving the pinned vehicle.
Design principle: manual intervention should be local, explicit, and reversible rather than turning the entire route into an unmanaged list.
Balancing trip types
Arrival order alone could not meet the departure plan.
The product distinguishes between direct and round-trip runs. Each route can have a target ratio that influences which vehicle the system selects next.
- The algorithm accounts for completed departures.
- The interface shows target versus actual performance.
- Manual pins retain priority.
- Dispatchers can see when the target ratio is not being met.
Configuring the target ratio
A complex operational rule became a short flow with clear validation.
The dispatcher sets the number of direct and round-trip departures. At least one type must have a non-zero value; validation appears next to the relevant field, and existing values remain available during editing.
Early versions exposed additional signals, including minimum queue position and whether a vehicle was needed to restore balance. Iteration showed that these details added noise. The main interface retained the decision-relevant metric: compliance with the target ratio.
Transparency and audit history
The system should not only make decisions; it should explain how the current state was reached.
The history records status changes, calls, confirmations, position adjustments, reserve-related actions, and the initiator of every manual intervention. Events are grouped by meaning so operators can locate the relevant episode quickly.
Why history matters: it is not a secondary log; it is a tool for resolving disputes and reviewing operational quality.
Carrier access
Operational transparency should not expose other participants' data.
Carrier operations teams can view their own vehicles and related events. Other drivers' personal data is hidden, and actions that could affect the shared queue are restricted.
This expands access to operational information while following the principle of least privilege.
When a gate becomes unavailable
Operational analytics must distinguish active processing time from unavoidable downtime.
When a gate becomes temporarily unavailable, the system records a dedicated status and pauses the loading or unloading timer. Downtime therefore does not distort the actual processing duration.
How the event is recorded
The initiator and timestamp remain available for later investigation.
If a driver reports the issue, the system can also display the distance to the gate. The event and its initiator remain available for operational review.
How the product evolved
The product evolved from a basic digital queue into a broader yard-management capability.
-
Digital queue and vehicle call to a loading gate.
-
Shift from individual gates to route-level control.
-
Manual sessions, vehicle reordering, and pinning.
-
History of statuses, calls, confirmations, and positions.
-
Carrier access with role-based restrictions.
-
Trip types, departure limits, and target ratios.
-
Gate downtime, timer pausing, and initiator tracking.
Outcome
The queue became an operating model for yard flow.
The product connects automated dispatch, manual intervention, route-level control, vehicle pinning, trip types, target ratios, audit history, role-based access, and exception handling.
What changed in the product
- Dispatch rules became explicit and system-enforced.
- Dispatchers gained a route-level view and a safe way to intervene.
- Drivers and carriers gained access to current information within their roles.
- Critical changes became traceable through the event history.
- Exceptions are handled inside the product instead of disappearing into side channels.
Evidence gap
The source material defines two measurement areas: adoption of the digital queue and vehicle time in queue. Post-launch values were not included, so I do not present unverified percentages as evidence of impact.
My contribution
As the sole designer, I maintained product coherence across several connected initiatives.
I worked with two business analysts to translate YMS rules, state dependencies, and operational constraints into product behaviour. With the Product Manager, I shaped priorities and sequencing. With engineers and QA, I worked through system states, conflicting actions, and edge cases.
Scope of ownership
- Queue information architecture.
- The shift from gate-level to route-level control.
- Coordination of automated and manual operating modes.
- Vehicle reordering and pinning flows.
- Target-ratio configuration.
- Vehicle history and auditability.
- Role-based access for carriers.
- Driver-facing mobile states.
- Operational exceptions and consistency across system states.
The project evolved over approximately seven months. My responsibility extended beyond individual screens: I kept statuses, roles, actions, and consequences consistent across the system.
Takeaways
Operational product maturity is defined less by the happy path than by the way the system handles exceptions.
Algorithms perform well in predictable conditions. Real logistics is defined by deviations: gates become unavailable, vehicles are not ready, priorities change, and several operators may work on the same queue at once.
The product therefore needs to automate the standard flow, support safe human intervention, make the current operating mode explicit, and retain an audit trail of consequences.
Next steps
- Measure the frequency and causes of manual interventions.
- Analyse deviations from target ratios.
- Break queue time down by operational stage.
- Track the frequency and duration of gate downtime.
- Measure dispatcher trust in automated vehicle selection.
In summary: Autoqueue evolved from a vehicle-calling interface into a system that combines automation, transparency, and safe human control.