Up to now the system has quietly assumed customers say exactly what the database expects. They don't. Someone books "the London train" — but there are several London stations, and the database wants a specific one. This part fixes that small, constant friction.
The problem it solves
People describe places the way people do, not the way a database does. They name a city when the system wants a station. They say "near Manchester". They don't know — and shouldn't have to know — the station code. If the agent just passes that straight through, the search fails or, worse, books the wrong thing.
There's also a quieter win hiding here. I already know where each customer lives, because it's on their profile. So I can default their departure station sensibly instead of asking every single time.
How it works: a mapping, not magic
This is deliberately not clever. It's a curated mapping from the places customers actually type to the stations the system knows, plus a default departure station derived from the customer's address on file. No IP geolocation, no guessing — I have the address, so I use it.
"the London train" → resolve against known stations → London Euston
customer address → default departure station → pre-filled, editableThe point is to do the obvious resolution before the Ticket Agent runs its tools, so the booking operation gets a real station, not a vague phrase. When it's genuinely ambiguous, the agent asks — it doesn't quietly pick one and hope.
The mapping and the lookup are in the open-source repo. It's a small file doing an unglamorous job, which is exactly why it works.
Next in the series
That's the whole system built — two specialists, a coordinator, and the location handling. Next I do the part most tutorials skip: testing it, and proving it actually behaves before it goes anywhere near a customer.
Building AI that meets customers where they are — plain language, real data — is what I do at twentytwotensors. Get in touch.