Delivery bookings in a spreadsheet: what breaks at twenty deliveries a day

A spreadsheet for planning deliveries, in Excel for example, is enough as long as there are a few deliveries a day and one person keeps the plan. At twenty deliveries the plan starts to drift away from what is happening at the gate: the spreadsheet doesn’t know about a vehicle that has already arrived, doesn’t stop two bookings for the same dock and doesn’t tell the carrier or the driver about a change. On top of that, abandoned bookings stay in it until the end of the day, and the handling history disappears the first time someone overwrites the file.

The spreadsheet doesn’t know the vehicle has arrived

The plan says the delivery is at ten. The lorry has been standing at the gate since half past eight, and the warehouse finds out from a phone call from the gatehouse. The spreadsheet has no way of knowing, because nobody enters arrivals in it.

The difference lies between the plan and the actual state. A spreadsheet holds only the plan, while a delivery booking system keeps both in the same place, because the entry is created at the gate from the booking and stays linked to it.

Two bookings for the same dock at the same time

A booking in a spreadsheet is an entry in a cell. Nothing stops two people from entering two deliveries for the same dock at the same time, especially when they are working on a copy of the file. The conflict comes to light in the morning at the dock, when the only way left to resolve it is a queue.

A dock change doesn’t reach the driver

Moving a delivery from dock three to dock five is one correction in the spreadsheet and two phone calls outside it: to the carrier and to the driver. Someone usually makes the first call; the second usually doesn’t happen. That is the most common reason a driver ends up waiting at the wrong dock, even though everyone in the chain did their part and nobody feels to blame.

Nobody is responsible for abandoned bookings

A delivery that didn’t turn up stays in the spreadsheet until the end of the day and blocks the slot. It gets deleted by whoever notices it, which often means nobody, so after two weeks the schedule is full and the docks stand empty.

Handling history disappears when the file is overwritten

The question “how long did unloading take last month” needs data the spreadsheet doesn’t collect, because it is used for planning and doesn’t record how deliveries actually went. Last week’s version has often been overwritten, and last month’s sits in a file with a date in its name.

When a delivery planning spreadsheet is enough

A tool that works doesn’t need replacing. A spreadsheet is enough when all four of these conditions hold at once:

1. there are no more than a few deliveries a day,
2. one person keeps the plan and the same person answers the phone,
3. the carriers are regulars and there are only a few of them,
4. nobody asks about handling history.

When any of them stops being true, the spreadsheet still works, but it takes up time elsewhere: on the phone and at the gate.

What switching from a spreadsheet to a system won’t fix

A delivery booking system won’t add docks. When there are more deliveries than the site can physically handle, the schedule will show it, but the problem won’t go away. Nor will the system make carriers punctual: it shows who failed to turn up, and the conversation with the carrier is yours to have.

The system won’t take organisational decisions for the site either. Handling unbooked deliveries only after the booked ones is your rule, and it isn’t something you set in the system.

Questions and answers

See also: How to organise time slots at your loading docks · ‘What time should I be there?’ calls: how to stop taking them · No-show bookings: how to stop a vehicle that won’t come from blocking a dock