Delivery address — where the rider needs to be

A diner finishes choosing dinner, taps the cart, and lands on the field that decides whether the food gets to them in eighteen minutes or in fifty. The delivery-address block is small — one search box, one optional note line — but the data behind it is the difference between the rider opens a map and drives there and the rider phones the venue from the wrong street. This page is about what that field captures, when it appears, and what every other part of the system does with the result.

This page is for two readers. If you’re the owner, “Why this page exists” is for you. If you’re the operator dispatching tonight’s deliveries, jump to “What happens behind the scenes”.

Why this page exists

The fastest way to lose a delivery customer is to deliver to the wrong building. The second-fastest is to keep them on the phone while the rider works out which of three via Roma 12 candidates is the right one. Free-text address fields produce both failures with depressing regularity — a diner typing on a phone at 8pm misspells the street, omits the postcode, capitalises bangkok like a robot, types the apartment number as a sentence. The operator squints at the WhatsApp message and copy-pastes into a map app, the map app’s autocomplete misreads the typo, the rider drives to a via Roma in the wrong neighbourhood.

The address field replaces all of that. The diner starts typing, an autocomplete suggests the correct full address with postcode and neighbourhood, the diner taps the right one, the system geocodes it on the spot, the WhatsApp message that arrives at the venue already contains the formatted address and a tappable map link. The operator never copy-pastes; the rider taps the link and drives. Two failure modes — wrong building, slow dispatch — gone.

The other reason this page exists is repeat business. A diner who orders twice doesn’t want to retype their address twice. Signed-in diners get their last ten addresses as one-tap chips above the search box, scoped to their account, available at every venue they order from. The second order is faster than the first; the third is faster still.

The rule

The address field is part of the cart, appears only when the venue has online ordering on and the order is going to a rider (not pickup, not dine-in), captures a typed-and-validated street with latitude and longitude, and rides on the order all the way to the WhatsApp message the operator reads — already formatted, already mapped, already actionable.

When the field appears

The cart only renders the delivery-address block under two conditions. Online ordering is on for the venue. That’s the master switch in Admin → Settings → Online ordering; if it’s off, the cart drawer never opens for any diner regardless of what’s in it. The order channel is delivery. Pickup orders don’t need an address — the diner walks in. Dine-in orders don’t need an address — the diner is already there. Only the rider-dispatch path needs the field, and only there does it appear.

If both conditions are true, the diner sees the block at the top of the checkout drawer, labelled Delivery address, with the search box waiting for the first three characters of a street name.

What the diner types

The search box accepts free typing. After three characters, suggestions appear, biased toward the venue’s country if you set one on Admin → Settings → Address. A diner near the venue gets local suggestions; a diner travelling abroad ordering from your branch sees suggestions in the country they’re in.

The diner taps one suggestion. The system fetches the full structured address (street, neighbourhood, city, postcode, country, plus latitude and longitude) from the address-lookup service and shows the picked address in a small green card: the formatted line on top, a link reading Open in Google Maps under it. Tapping the link opens the map pin in whichever map app the diner’s phone defaults to.

Below the picked card sits a small grey textarea for apartment, floor, gate code, delivery notes. This is the field the diner uses for “Building B, third floor, ring buzzer 3A” or “leave with the doorman” or “the white gate, not the blue one”. The note is optional — most diners skip it for a building they live in alone, fill it for an apartment block, fill it heavily for a gated complex.

A signed-in diner with previously-used addresses sees a row of one-tap chips above the search box, each labelled with the address’s short name (Home, Office, or just the street). Tapping a chip skips the search entirely — the address is filled in, the diner moves on. The chips are scoped to the diner’s account, not to the device or the venue, so a diner who ordered from venue A last week and orders from venue B this week sees the same chips. The chip list keeps the last ten addresses; the eleventh evicts the oldest.

If the diner picks the same address twice, the second pick overwrites the first instead of stacking duplicates. Anna doesn’t end up with three Home chips that all point at the same flat.

What happens behind the scenes

The diner’s browser never talks to the address-lookup service directly. Every keystroke goes through the system’s own address endpoint, which forwards to the lookup service using one shared key the diner never sees. The venue doesn’t have to set up an address-lookup account, the diner’s browser never holds a key, and the venue’s address quota is shared across every venue on the platform — no per-venue setup, no per-venue billing.

When the diner taps a suggestion, the system runs two calls in sequence — one for the autocomplete (to fetch the suggestion list) and one for the details (to resolve the suggestion’s place ID into the full structured address with coordinates). The diner sees the green card appear; the operator’s outbound order already carries the formatted line and the latitude/longitude.

On the order itself, the system stores a snapshot of the address: the formatted line, the latitude and longitude, a pre-baked map URL, the place ID for any later lookup, and any apartment/note text. The snapshot doesn’t change if the diner later edits or deletes the saved address in their account — the order keeps the address it had when it was sent. The operator never sees a stale or shifted address on an old order.

When the WhatsApp message is composed, the address goes on its own line under the line items, followed by the map URL on the next line, followed by any note in parentheses. The mobile WhatsApp app turns the URL into a tappable link automatically; the operator’s phone opens the pin in their default map app.

For signed-in diners, the address also saves to the diner’s account in the same write — a separate mutation tucks it onto the customer record. Anonymous diners (the ones who didn’t sign in) skip the save; their address only ever rides on the one order they just sent.

Worked example

It’s Tuesday at 8:14pm. Anna lives two streets away from your venue and has eaten there once before, in person, last month. She opens your venue’s public menu, taps a Margherita (€11), taps Add to cart, taps the floating cart button. The drawer opens.

She’s not signed in, so no saved-address chips show. Under Delivery address she starts typing — “via Ro…” — and the search box shows three suggestions: Via Roma 12, Khlong Toei, Bangkok / Via Roma 12, Centro, Milano / Via Roma 12, Trastevere, Roma. She taps the first one. The green card appears: Via Roma 12, Khlong Toei, Bangkok 10110 with an Open in Google Maps link. She types “Building B, 3rd floor, ring buzzer 3A” in the small grey box. She fills her name and phone, taps the Send order via WhatsApp button.

The venue’s WhatsApp buzzes a second later. The message reads:

Hello, I'd like to order:
• Pizza Margherita ×1 — €11

Total: €11
Name: Anna
Phone: +66 81 234 5678

Delivery to: Via Roma 12, Khlong Toei, Bangkok 10110
https://www.google.com/maps/?q=13.738,100.566
(Building B, 3rd floor, ring buzzer 3A)

View order: https://menu.iosteria.com/o/m1abc2…

Marco the operator reads the message at the pass, taps the map link, the pin opens in his phone’s map app, he forwards it to the rider on standby in the kitchen. Eighteen minutes later the rider rings Anna’s buzzer. No phone-tag, no “which apartment”, no second message asking for the gate code. The whole exchange between order and doorbell was a typed street, a tapped suggestion, and one button.

A week later Anna orders again. This time she signs in first, finishing the email-code flow she skipped last week. The cart’s saved-address chip row appears with one chip — the Via Roma 12 she used last week. She taps the chip, the address fills, the note is still there. Send order via WhatsApp, the rider arrives in seventeen minutes. The second order is faster than the first. The next time she travels for work and orders from a sibling venue in Milano, her Via Roma 12, Khlong Toei chip still sits above the search box — she ignores it, types her hotel name, picks the right suggestion, the new address joins her chip list. One typed street, four orders in three months, no retype.

Online vs in-venue — the per-category visibility rule that decides whether a diner outside the venue can reach the cart at all; the delivery-address field only appears on the path the cart opens up
Modifiers — the per-item customisations the diner picks — the picker the diner hits before the cart; modifiers carry through to the order alongside the address
How the AI thinks about your menu — the AI doesn’t use the delivery address for menu recommendations, but it does use the diner’s order history (which now includes a clean address per order) to recognise repeat customers
Where your information lives — the delivery address snapshot lives on the order; the saved address chips live on the diner’s account; the venue’s default country lives on the venue’s settings — three rooms, one user flow