Turning emergency orders into planned deliveries

A fuel distributor ran deliveries across several regional branches. It had no ongoing relationship with most of its customers. The only time it heard from them was when they called because they needed gas. The number routed to a dispatcher, who took the order on the phone and decided on the fly where it fit into a truck already out on the road.

That process worked. It was also the constraint on the entire operation. The company could not know who was about to run out, could not reach them before they did, and could not plan around an order until the phone rang. Every urgent call risked pulling a truck off its route on a detour nobody had planned.

We built them a loyalty program that runs on WhatsApp and gives the company a two-way line to its customers for the first time. The interesting part was not the rewards or the routing engine. It was deciding which constraints were real.

A note for readers in the United States, where WhatsApp is a personal messaging app and rarely a serious business channel. Across much of Latin America it is the opposite. It is how customers expect to reach a business, and increasingly how businesses reach them. The company’s website detected a visitor’s location and handed them to the WhatsApp number for their nearest branch. What was missing was a reason for customers to stay in that conversation between orders, and a way for the company to use it.

What the problem actually was

Not route optimization. Routing was the visible half. The expensive half was that almost every order arrived as a surprise.

A customer who calls because the tank is empty has no flexibility. The delivery has to happen today, often within hours, wherever the truck happens to be. The same customer contacted two days earlier could be served on a day the truck was already in their neighborhood. The difference between those two deliveries is not the gas. It is whether the company knew in time.

Once customers could message the company through WhatsApp, they wrote the way people write. Lowercase, no accents, no address format, no volume unless you ask. A message saying the restaurant is out of gas and needs some before lunch service contains a customer, a neighborhood, a service type, an implied volume and a hard deadline, none of them labeled. The system has to read that the way a dispatcher would.

Which constraints turned out to be real?

Five, and none of them were in the original brief.

Rewards cannot be discounts. The price of gas in the region is capped by a regulator, so a loyalty program cannot hand back cash or cut the price. Points had to be redeemable for service instead: safety inspections, hose and regulator replacements, small top-ups, priority delivery windows and tank cleaning. Things that cost the company capacity rather than margin, and that customers genuinely value.

The truck cannot be filled. A tanker with a nominal capacity has a lower working capacity, because the product expands and the vessel needs vapor space. Every load calculation runs against the lower number. A system that plans against nominal capacity produces routes that cannot legally be driven.

Delivery windows are not preferences. Some stops close at a fixed time. One was a nursery school. Ignoring windows produced a route that was measurably shorter and visibly tidier on the map, and it arrived at the nursery ninety minutes after it closed. The tidier map was the non-compliant one.

The shortest route is not always the permitted one. Hazardous materials carriers are required to choose routes on safety grounds and avoid population centers where a bypass exists. An engine that minimizes time will route straight through one. That is not an inefficiency, it is a compliance failure, and no amount of optimization quality compensates for it.

Customer data is personal data. Addresses, tank readings and order histories identify people and their homes. The system was built and tested on synthetic records, and customer records live in a proper database rather than in chat threads.

What we built

Five pieces, with a person at the end of them.

A loyalty program on WhatsApp. Customers join through WhatsApp and earn points, much like airline miles, that they redeem for the services above. For most customers it is the first reason to keep a conversation with the company open between orders.

Knowing who is running low. The system estimates when each customer will need their next refill from their order history and tank GPS readings, and places every account on a refill cycle from up to date to at risk. The at-risk accounts become a worklist instead of tomorrow’s emergency calls. An operations panel shows the program as a whole: where accounts sit in their cycle, who needs contacting, how points are being redeemed and the liability they represent, and how members compare with customers outside the program.

Reaching out first, and confirming the time. Because the communication runs both ways, the company messages customers before they run low, offers a delivery, and confirms a time so someone is home when the truck arrives. A delivery that would have been an emergency becomes a planned stop.

Interpretation. A WhatsApp message arrives as free text. The system extracts the customer, the location, the service type, the estimated volume and the urgency, and separately lists what a dispatcher would still need to ask before confirming. That last output matters more than the first. A system that knows what it is missing can ask; a system that guesses produces a confident wrong answer.

Sequencing. The order is inserted into the route already in progress, with completed stops locked. Load is checked against working capacity, arrival times against delivery windows, and the whole thing against the length of the shift. A full solve runs in roughly forty milliseconds, a re-solve in under five. The customer receives a confirmation with an actual delivery time, derived from the route, rather than an acknowledgement.

Why does it price a bad order instead of refusing it?

Because refusing removes a decision that belongs to a person.

This was the design question that mattered most. Consider an order that fits the truck comfortably but sits well off the day’s route. In our worked example it added well under a mile of driving if it fell on the corridor the truck was already covering, and about ten and a half miles, thirty-three minutes of shift and sixty times the fuel cost if it did not. Both orders fit. One is cheap and one is expensive, and nothing about the tank tells you which.

The system does not decline the expensive one. It tells the dispatcher what the detour costs and asks whether to send it today or first thing tomorrow.

The loyalty program is how the operation avoids facing that choice in the first place. The customer who would have become an expensive detour tomorrow is contacted today and booked onto a stop the truck was already making.

How does it compare with a good dispatcher?

Closely on distance. The real difference is in the delivery windows.

Our first baseline sequenced deliveries in the order they were received. Against that, the optimizer saved thirty-six percent. We set that number aside, because no dispatcher actually works that way.

So we compared it against how experienced dispatchers do plan: deliveries grouped by zone and sequenced quickly, and the same grouped by zone and sequenced carefully.

Approach	Distance	Shift ends	Windows missed
Order received	136.6 mi	7:32 PM	1
By zone, hurried	109.2 mi	5:43 PM	2
By zone, careful	82.6 mi	3:59 PM	1
Optimized	82.1 mi	4:04 PM	0

Against a hurried manual route, the engine saves nearly twenty-five percent. Against a careful one, it saves 0.6 percent. We built the interface to show that as a range rather than the flattering end of it.

The durable claim is the last column. Every manual approach misses at least one delivery window. The optimized route misses none. A percentage does not survive meeting a good dispatcher. Catching the window they miss, at eleven in the morning when a new order lands and they are doing three other things, does.

This is the same argument we make about what to automate first in a logistics operation: the honest version of a claim outlasts the impressive one.

What comes next?

The first version covers the loyalty program, refill prediction, WhatsApp intake and route sequencing. Compliance is the next phase, and we scoped it from the start rather than leaving it to be discovered: route risk screening against population centers, validating that each delivery falls inside the routes a permit actually authorizes, checking that an assigned vehicle is registered, inspected and insured, pre-trip inspection as a gate on dispatch, and incident reporting against a regulatory clock.

We put that list in front of the client before they asked for it. A buyer who discovers a gap on their own stops believing the parts that work. It is the same reasoning that puts human review and audit trails into a system at design time rather than after it is running.

The interpretation and routing run live on every request. The route comparison above was measured on a modeled day of deliveries, so the next step is calibrating it against a week of real dispatch data from one branch, turning a modeled number into a measured one.

We can walk you through the system live on a call. The part worth seeing is what it does with a message nobody prepared for, including one you make up while watching.

If your business mostly hears from customers when something has already gone wrong, that is the same problem in different clothing. Tell us what it is.