Six portals and a phone line
Tomorrow's loads are planned. Now the transport office has to book them in. One retailer's depots use a web booking system. A wholesaler wants an email with the purchase order numbers and pallet count. A foodservice distributor's depot books by phone, and the line is engaged. Each booking comes back with a reference and a time that has to reach the haulier and the despatch team.
Somewhere between the portals, the emails and the whiteboard, a load goes out without a valid booking, sits outside the depot for three hours, and misses its slot.
Why booking is so fiddly
The bookings themselves are necessary. The problem is that the information lives in too many places. The orders are in your ERP, the pallet counts come from despatch, the slots are in each depot's system, and the haulier needs all of it in one message.
- Every depot has its own booking method and lead time.
- Pallet counts change after the booking is made.
- Booking references are copied onto paperwork by hand.
- Hauliers are told slot times in separate emails.
- Rebookings after a delay are not always passed on.
What a missed slot costs
A delivery refused or held for hours. Waiting time charged by the haulier. A redelivery the next day, which eats into the product's remaining life. Service level marks with the customer. And the transport office spends its afternoon rebooking instead of planning.
The booking view we build
- Orders needing delivery are read from your ERP or order system, grouped into loads by depot and date.
- Each depot's booking method and lead time is recorded, and the view shows which loads need booking, and by when.
- Where a depot's booking system has an API or accepts email requests, the request is prepared automatically for a person to send. Where it is a portal, the details to enter are laid out ready to copy.
- The booking reference and slot time are recorded against the load, and the delivery note and pallet labels carry them.
- Hauliers get a single daily schedule per vehicle with every slot, reference and pallet count, and any later change is sent as an update.
- Loads without a confirmed booking, and bookings where the pallet count has changed since, are flagged before the vehicle leaves.
| Depot type | Booking method | How it is handled |
|---|---|---|
| Retailer RDC | Web booking system | Details laid out, reference recorded |
| Wholesaler depot | Email request | Request drafted from the load |
| Foodservice depot | Phone | Call list with details, reference recorded |
| Customer with API | System to system | Booked directly where allowed |
A transport office that can see everything
One screen shows every load, its booking status and its slot. Hauliers get one clear schedule. Despatch knows the order to load vehicles. When a slot is missed, the rebooking and the haulier update happen together. And over time, you can see which depots cause the most rebooking, which is useful in customer conversations.
Customer services benefit when a retailer or wholesaler asks where a delivery is. The booking, the slot, the haulier and the vehicle are all on the load record, so the answer is a lookup rather than a round of phone calls to the transport office and the haulier's traffic desk.
Cover is easier too. The booking knowledge that lived with one transport clerk, which depot needs how much notice and which one wants the purchase order number in the subject line, is written down where anyone can use it.
Is this your transport office?
- Slots are booked in several portals and by phone every day.
- Booking references are copied onto paperwork by hand.
- Hauliers get slot times in separate emails.
- Loads have arrived without a valid booking.
- Only one person knows each depot's booking rules.