Turning a manual booking desk into an automated order pipeline

The challenge

The operator sold a service that was easy to describe and difficult to quote. A customer wanted a vehicle from one place to another, at a time that depended on a flight that might be delayed, at a price that depended on route, vehicle class, time of day and season.

Every enquiry arrived as free text — email, web form, messaging app, in more than one language. A member of staff read it, worked out the route, looked up a price, checked availability, wrote back, and then re-entered the whole thing into the commerce system once the customer agreed.

It worked. It also meant that the number of bookings the business could take in a day was set by how many enquiries a person could read, and that every booking was delayed by however long it took someone to get to it.

The engineering problem

The interesting part was not "use AI to read the emails". It was that the process contained two categories of work with completely different tolerance for error, and they had been sitting in the same person's head.

Interpreting a customer's message is fuzzy. Pricing a journey, creating an order, and taking a payment are not: those must be exactly right, every time, and must be auditable afterwards.

A single AI system doing all of it would have been a good demonstration and a bad business system. The design problem was to draw the line between the two — and to make sure that everything downstream of that line was deterministic, testable and reversible.

The approach

We split the pipeline at the point where interpretation ends and commitment begins.

Ahead of the line, a language model extracts structure from whatever the customer sent: origin, destination, date and time, passenger and luggage counts, vehicle requirements, flight number if there is one. It produces a structured record and a confidence signal, and it is allowed to be unsure.

Behind the line, everything is ordinary deterministic software. Pricing is a lookup against a maintained rate structure, not a model output. Order creation, payment links and confirmations are code paths with tests. Nothing that touches money is generated.

Between the two sits a review surface. High-confidence, well-formed requests flow straight through. Anything ambiguous, unusual or high-value stops and waits for a person — with the extracted structure pre-filled so the human step is a check rather than a re-entry.

The solution

The delivered system runs as a pipeline rather than a request-response API, which matters because the inputs are unreliable in ways nobody controls.

Flight lookups, for instance, depend on third-party data that goes down. Rather than failing a booking when a provider is unavailable, the system uses a provider chain with a documented fallback order and caches aggressively, so a provider outage degrades enrichment rather than blocking confirmations.

Every stage writes to an operational record that is visible to the team, so a booking that stalls is visible as a stalled booking rather than as silence. Downstream, orders are synchronised into the operations tooling the business already used, because replacing tools people are fluent in is a cost with no benefit.

Technology

• LLM-based extraction with structured output and confidence thresholds
• Deterministic pricing and order creation against the existing commerce platform
• Provider fallback chain for third-party flight data, with caching and rate-limit handling
• Event-driven synchronisation into operational tooling
• Idempotent handlers and replay, so a retry cannot create a duplicate order

Business value

The constraint moved. Confirmations stopped being limited by a person's reading speed, and the routine majority of bookings began completing without anyone touching them. The team's work shifted to the cases that genuinely needed judgement — unusual requests, high-value bookings, and exceptions — which is where their knowledge was worth the most.

We are not publishing throughput or conversion figures here. The operator has them; they are commercially sensitive, and a number we cannot show you the derivation of is not evidence of anything.

Key learnings

Draw the line between fuzzy and exact early, and defend it. Almost every design argument on this project resolved by asking which side of that line a step belonged on.

Design the failure path first. The provider fallback chain was not a refinement; it was the thing that made the system trustworthy enough to leave unattended.

Pre-fill the human step instead of removing it. The review surface was more valuable than full automation would have been. It made the system safe to launch early, and the review queue turned out to be an excellent source of information about what the model still got wrong.