The Delivery Day Still Runs on One Person’s Memory

In most FMCG delivery operations, the decision that determines the entire day — which orders go on which truck, in which order — is made by one experienced person with a whiteboard and thirty years of knowing which driver can handle which area. It works, until it doesn’t. Here’s how delivery order assignment, route optimisation and electronic proof of delivery actually fail, and why the difference between a routing engine that works here and one that doesn’t comes down to local constraints.

1. The delivery day: three decisions that determine everything

Direct store delivery for FMCG compresses an enormous amount of judgement into a few hours before dawn. Orders close — increasingly captured automatically from WhatsApp rather than re-keyed overnight — stock is confirmed, and someone has to convert a list of delivery orders into a set of loaded vehicles with a workable sequence — before the first truck leaves the yard.

Everything that goes right or wrong in the following twelve hours traces back to three decisions.

2. Where FMCG delivery operations actually break

The assignment depends on one person

Ask a distribution manager who assigns delivery orders to vehicles and the answer is almost always a name. One supervisor, usually long-serving, who knows which driver copes with the narrow lanes in the old town, which vehicle fits under the loading bay at a particular hypermarket, which customer will reject a delivery after 11am, and which driver should not be sent to a specific account again.

That knowledge is genuinely valuable. It is also entirely undocumented, unauditable and unavailable when that person is on leave, ill, or leaves the company. Operations that run this way discover their exposure on the worst possible day — and typically describe the resulting week as chaotic without connecting it to the fact that a single point of failure had been in place for years.

The tell: if the daily assignment cannot be reproduced by anyone else in the building using written rules, the business does not have a process. It has a dependency.

The driver re-plans the route

A sequence is issued. What actually happens on the road is a different sequence. Drivers reorder for reasons that are entirely rational from where they sit: do the easy drops first, leave the difficult customer until last, arrange the day so the final stop is near home, avoid the outlet where unloading takes an hour.

Individually these are small adjustments. Collectively they produce a systematic pattern — the same customers are consistently served late, and they are usually the ones who complain, which is precisely why drivers avoid them. The operation has no visibility into any of it, so the pattern is invisible until it becomes an account at risk.

Nobody can say where anything is

The customer service desk receives a call at 11am asking where a delivery is. There is no answer available, because the truck’s position, the sequence progress and the expected arrival time exist only in the driver’s phone — if at all. The desk promises to call back, calls the driver, relays an estimate, and the whole exchange consumes more staff time than the delivery is worth.

Proof of delivery arrives days after the dispute

Paper delivery notes come back to the office with the vehicle, get sorted, and are filed. When a customer disputes a quantity two weeks later, someone goes looking. Sometimes the note is found and illegible; sometimes the signature is a scribble that proves nothing; sometimes short-delivered items were noted in pen on a copy nobody kept. In each case the outcome is the same — a credit note issued to end the argument.

3. Decision one: delivery order to fleet assignment

Assignment is not a packing problem. Fitting cases into a vehicle is arithmetic. Deciding which delivery orders belong on which vehicle, driven by whom, is a constraint problem — and the constraints are the reason the experienced supervisor exists.

Automated assignment changes three things beyond speed:

• The knowledge is captured. Rules that lived with one supervisor become configuration the business owns. Leave, illness and resignation stop being operational events.
• Load balancing becomes visible. Manual assignment tends to overload the reliable driver and underuse the rest, because the supervisor optimises for certainty rather than utilisation. A system sees the whole fleet at once.
• Late changes stop being catastrophic. A credit hold released at 6:30am, an urgent order, a vehicle breakdown — all of these mean a manual plan must be redone by hand under time pressure. Reassignment becomes a recalculation instead.

4. Decision two: route optimisation that survives contact with reality

Route optimisation has a reputation problem in this region, and it is largely deserved. Many operations have tried a routing engine, found the output unusable, and gone back to the supervisor’s sequence. The reason is almost always the same: the engine optimised for distance and time in a way that ignored the constraints that actually govern the day.

A route that is twelve percent shorter but arrives at a hypermarket after its goods-in window has closed is not an optimised route. It is a failed delivery with better mileage.

The constraints that decide whether a route is real

This is where Interact’s routing differs from a generic optimisation engine. The model is built to carry the constraints that actually apply in this market, not a simplified abstraction of them.

Constraint	What it looks like in practice	What happens when it is ignored
Store receiving hours	Goods-in windows that differ by chain, by store and by day; outlets that close over lunch; back-door access restricted to a specific period	Vehicle arrives, is refused, returns tomorrow — full cost, no revenue
Product temperature	Frozen, chilled and ambient on one vehicle; compartment capacity; sequencing to limit door-open time and total exposure on chilled stops	Temperature excursion, rejected or unsellable stock, compliance exposure
Road and access constraints	Lorry restrictions by class and hour, weight and height limits, one-way systems, narrow inner-city lanes, loading bay dimensions at the outlet	A route that cannot physically be driven, quietly abandoned by the driver
Changing priorities	Urgent orders after cut-off, a credit hold released mid-morning, a promotional delivery that must land before store opening, a VIP account escalation	Manual replanning under time pressure, or the change simply not being made
Driver and vehicle pairing	Licence class, familiarity with a territory, customers who require a specific handling approach, shift and hours limits	Slower service, avoidable disputes, safety and compliance risk

Why this is the differentiator: any routing engine can shorten a path between points. The question that decides whether the output gets used is whether it can express that this hypermarket takes deliveries only between six and eleven, that the chilled drop must come early, that a three-tonne vehicle cannot enter that street before nine, and that the order released from credit hold at 06:40 has to be inserted without breaking any of the above. A plan that cannot hold those rules will be overridden by the driver — and then nobody is following any plan at all.

Replanning during the day

A plan made at 5am is a forecast. Traffic, a breakdown, a rejected delivery, an urgent insertion — each one invalidates part of it. The practical requirement is not a perfect morning plan but the ability to recalculate the remainder of a route mid-day, push the revision to the driver, and update the expected arrival times that customer service is quoting. Without that, the operation reverts to phone calls and improvisation by mid-morning.

5. Decision three: electronic proof of delivery

ePOD is often positioned as a paperwork improvement. It is more accurately the point at which the delivery operation becomes measurable at all — because until delivery is captured as structured data, none of the preceding decisions can be evaluated.

The operational effects are direct:

• Disputes end faster and more often in your favour. A timestamped photo and signature against a specific delivery line replaces an argument about what a paper note said.
• Billing accelerates. Confirmed delivery triggers invoicing the same day rather than after the paperwork returns and is keyed.
• Short deliveries and returns are captured at source, with reason codes, so credits are raised correctly rather than negotiated later.
• Customer service can answer the question. Live sequence progress and expected arrival times mean the desk stops calling drivers and stops calling customers back.
• Planning improves continuously, because actual service duration by outlet is measured rather than assumed.

6. The executive view: the delivery operation, live

7. What Interact brings to DSD and logistics

8. Where to start

Delivery operations rarely benefit from changing all three decisions at once, and the sequencing is fairly consistent across businesses.

• Start with ePOD if disputes and slow billing are the visible pain. It is the least disruptive change, requires no replanning of anything, and immediately produces the actual service-time data everything else depends on.
• Start with assignment if one person is the bottleneck. Documenting the rules is valuable even before automating them — and it is the single largest reduction in key-person risk available to the operation.
• Add routing once you have real service times. Optimisation built on measured durations rather than estimates produces plans drivers will actually follow, which is the whole point.
• Measure plan adherence from day one. If drivers are departing from the sequence, the plan is wrong or the constraints are incomplete. That number tells you which.

---

Interact Technology builds cloud SaaS field and delivery execution software for consumer goods, distribution and service businesses — AI-driven route intelligence and direct store delivery, electronic proof of delivery, mobile field sales and merchandising, and consolidated management dashboards, integrated with your existing ERP, WMS and CRM.