Failed first deliveries start in the address notes field

The problem

Small local delivery operators, such as independent courier firms, florists, bakeries and restaurants running their own drivers, lose real money on failed or slow first attempts. The driver reaches the geocoded point, which is often a street centroid or the front of a large complex. The actual entrance is round the back, the gate needs a code, and the customer wrote "blue door, ring twice, not before 9" in a free-text field the driver skims at a red light.

Each miss costs a phone call, minutes idling at the kerb, sometimes a second trip, and a customer who now doubts the business. Across a day, that time adds up to fewer stops per driver.

Route optimization tools solve sequencing well. They treat the address as an input, not as something the system should learn. Whatever a driver figures out at a tricky building tends to stay in that driver's head and leaves when they do.

Constraints

• Budget: the operator pays per seat for existing dispatch software and will not replace it, so this has to sit beside it.
• Skills: no in-house engineer. Setup must be a CSV export or a webhook, not an integration project.
• Data: delivery notes are messy, multilingual and inconsistent. Driver GPS is noisy near tall buildings.
• Regulation: customer phone numbers and access codes are personal data. Texting customers needs a lawful basis and an opt-out.
• Trust: drivers will ignore a tool that is wrong twice. Gate codes must never be shown to the wrong person or invented.

System design

The core is an address memory keyed by a normalized address plus unit.

• Ingest: orders arrive by webhook or CSV. Deterministic code normalizes the address and geocodes it with a standard provider.
• Note extraction: an LLM reads the free-text note and fills a fixed schema: entrance_hint, access_code, time_window, contact_preference, hazards. Output is validated against the schema, and every extracted field must quote a span of the original note. If the span does not exist in the text, the field is dropped. The model never fills a field from general knowledge.
• Drop-off learning: when a driver marks a delivery complete, plain code records the GPS fix and an optional photo. After repeated consistent fixes, that point replaces the geocode for future orders. This is clustering and thresholds, no model needed.
• Pre-dispatch check: rules flag orders with no learned point, a low-confidence geocode, or a note that mentions a code without one present. Flagged orders get a short clarification text. An LLM may phrase the message and parse the reply back into the same schema, with the same span rule.
• Driver view: a single card per stop with the learned pin, the structured hints, and the access code revealed only within a set distance of the stop.

Routing, geofencing, thresholds and permissions stay deterministic. The model only turns language into fields and fields into language.

Trade-offs

It does not optimize routes, so the operator keeps two tools. That is acceptable because the value is in the last fifty metres, and competing with mature routers would waste the build.

Learned points take several deliveries to settle, so one-off addresses gain little beyond note extraction. Dropping unsupported fields means some useful hints are lost. I prefer a missing hint to a confident wrong one, because one fabricated gate code costs more trust than many blanks.

What I would build first

A CSV in, card out version for one operator. Upload the day's orders, run note extraction with the span check, and render a printable or mobile stop card per order. Add a single completion button that captures the GPS fix.

Skip texting and clustering in the first week. Measure two things against the previous weeks: driver calls to customers per stop and first-attempt failures. If both move, the address memory is worth building out.

Treat every completed delivery as a labelled example of where the door really is, and let the model only translate notes into fields it can quote.