Dispatch software is an exceptions list, not a map

At two in the afternoon, the dispatcher at a delivery company in Santo Domingo is not looking at the map. The map is fine: twenty-odd dots moving across the Distrito Nacional. What they are looking at is the short list of things going wrong: a van stuck on the Kennedy, a customer who was not home, a driver who has been on the road for nearly five hours.

Most dispatch software is sold with the map as the hero. It demos well. But a map shows everything that is normal, and normal is exactly what a dispatcher does not need to see. The job is the exceptions, and the software either puts them first or makes someone hunt for them.

What the screen is actually for

We built a sample dispatch interface under /demos to show the shape of this kind of system. Every name and number in it is invented. The layout is the argument: the exceptions panel sits beside the map, not under it, and each item carries the action that resolves it.

WITHOUT

• Map as the main screen
• Late orders found by scrolling
• Status shown only as a colour
• Exceptions sorted out by phone

WITH

• Exceptions listed beside the map
• Breach risk raised before it happens
• Status with the reason and new ETA
• One next action on every exception

An exception is only useful if it says what to do. "Late" is information. "Forty-one minutes past a 13:00 to 15:00 window, three stops affected, reschedule or reassign" is a decision someone can make in five seconds.

What has to be right underneath

• Delivery windows as data, not notes. The window the customer agreed to is what a breach is measured against, so it has to live on the order, not in a comment.
• Addresses that work in the DR. Plenty of deliveries are found by reference, next to the pharmacy or behind the colmado, so the order needs a reference field and a phone number the driver can call, not only a pin on a map.
• Proof of delivery that survives a weak signal. A photo and a timestamp captured on the phone and uploaded when the connection comes back, instead of a button that fails in a parking lot.
• Cash on delivery reconciled per driver. If drivers collect cash, the day closes with each driver's total checked against their completed stops, or money goes missing quietly.
• Driving hours tracked by the system. A break that is coming due should show up as an exception before it becomes a problem, not after.

None of this is exotic. These are the reasons a spreadsheet and a WhatsApp group stop working somewhere around the tenth vehicle, and they are what separates a real dispatch system from a tracking map with a login.

When you do not need one yet

With three or four vehicles and a dispatcher who knows every driver, a shared sheet and a group chat are honest tools. Buy or build dispatch software when exceptions start getting lost between messages, when at five o'clock nobody can say which orders failed and why, or when the cash does not match the stops at the end of the week.

When that point arrives, judge any option by its exceptions screen first and its map last. The map is the easy part.