Two lorries, one bay and three versions of the plan
Imagine a site handling inbound deliveries and outbound shipments across several bays. A dispatcher moves a transport after a call from the haulier. The warehouse is still working from an earlier schedule, while gate security has the list printed that morning. The driver has arrived, but the order is not ready.
More phone calls resolve the immediate situation, but the change affects the next vehicles and the loading bay’s work. Everyone needs a shared view: what is planned, who has arrived, which goods are ready and where handling can actually begin. A booking calendar alone is not enough.
What holds up the work?
Starting point
An open slot does not mean available capacity
Loads differ in duration, equipment and requirements. Two bookings may not overlap in the calendar yet still compete for the same team or forklift.
A change reaches only one person
The haulier reports a delay, but the warehouse and gate still see the previous time. Each team makes a reasonable decision based on a different plan.
Readiness problems emerge at the bay
The vehicle has a confirmed appointment, but the documents, goods or necessary equipment are not ready. The issue is only noticed when it is already blocking operations.
One booking connects the plan with events in the yard
A booking includes the order, operation type, requirements, haulier and time window. We separately record goods readiness, arrival, the start of handling and departure. The planned time no longer stands in for the actual sequence of events.
Each role gets its own view of the same process. Dispatch manages the plan, the warehouse manages preparation and the gate manages arrivals. Changes retain an author and a reason, so the order of service can be explained.
What the new workflow could look like
Book a slot that fits the operation
Availability reflects working hours, bay capabilities and agreed constraints. An unusual load or an operation needing an additional resource may require approval from a planner.
Check readiness before arrival
The warehouse confirms that goods are prepared, while the system highlights missing data and documents. The dispatcher sees the risk before the driver appears at the gate.
Record events and direct the vehicle
Arrival does not automatically start loading. The gate registers the vehicle, and an authorised person directs it to a bay according to current availability and site rules.
Close the operation with a full history
Completion records actual timings and deviations. Late arrival, unavailable goods and technical problems have separate causes, allowing the process to be analysed without guessing.
A plan needs to accommodate delays
A late transport should not simply push every later booking back. We agree tolerance rules, early-arrival handling and slot reassignment. The system can suggest options, but decisions affecting counterparties or priorities may need a person. Simultaneous reservations for the same resource must be resolved by the system, not by whoever refreshes their screen first.
- Cancellation releases resources while preserving the booking history.
- Unbooked arrivals follow a clearly marked process.
- Taking a bay out of service highlights the operations that need replanning.
Everyone sees what they need for their work
A haulier can manage its own bookings without access to other companies’ schedules. Gate security needs vehicle identification and instructions, not the full commercial documentation. The warehouse manager sees readiness and bay workload. We deliberately agree which driver data is collected, when it is deleted and which notification channels are used. Phone messages should not require navigating a wide table.
Let us start with one part that works.
The first implementation should be limited to one site and one type of operation. A shared calendar, readiness confirmation and arrival/departure records will test the status definitions. We add automatic notifications, haulier self-booking and barrier integration only after the core rules and responsibilities are agreed.
How will we know it is better?
This is a measurement plan, not a promised result. We agree the baseline before implementation.
Waiting time and handling time
We distinguish time spent waiting in the yard from loading itself. Results are compared by operation type, bay and conditions, avoiding comparisons between fundamentally different transports.
Reasons for schedule changes
We monitor which bookings changed and why. This separates haulier delays from unavailable goods or problems with bay availability.
Quality of preparation
We check how many transports arrived without confirmed readiness and how early the gap was noticed. A full calendar does not, on its own, indicate efficient operations.
Questions worth asking
Can hauliers choose their own slots?
Yes, within the access and rules provided. Booking can account for transport type, permitted bays and operational constraints. For unusual situations, it is better to send a request to a planner than offer a slot the site cannot handle.
Do we need to integrate with the ERP and gate immediately?
No. A pilot can start with manually confirmed events in one application. Integrations are selected according to data quality and the expected benefit. We need to establish the source of each status, failure behaviour and how to avoid recording the same operation twice.
