Case Studies | SaaS B2B

Turning scattered booking requests into structured taxi journeys

PoC - Automated Taxi Bookings

About

A SaaS B2B business working with Cloud Combinator on AWS. The client is anonymised at their request.

Challenge

The challenge had three focus areas, all centred on the moment a booking request first lands with the client.

Many formats, one meaning

The same underlying booking can arrive as an email, an Excel spreadsheet, a Word document or a scanned PDF run sheet. Each format presents the information differently, so any solution has to read all of them and resolve them to one shared understanding of what a journey is, rather than being tuned to a single template.

Detail that cannot be dropped

An usable booking record is more than a pickup and a destination. It needs the journey date, the customer and their contact details, every pickup and drop-off location with the individuals involved, pickup and return times, passenger counts, and any special requirements such as wheelchair access or multiple stops. Missing any one of these fields at intake creates real operational risk downstream.

Structure the dispatch systems can trust

Extracted detail is only valuable if it comes out in a predictable shape. The output had to be a single consistent structured record for every journey, including repeated bookings listed separately, so that it could be handed cleanly to the systems that schedule and dispatch vehicles.

Solution

At the centre of the proof of concept is a large language model driven by a carefully written extraction instruction. Each incoming document, whatever its format, is passed to the model, which reads it in context and pulls out every distinct taxi journey it contains, treating repeated bookings as separate journeys rather than merging them.

Source formats unified: email, Excel, Word and PDF

Journey fields extracted per booking into one schema

By the numbers:

4 - Source formats unified: email, Excel, Word and PDF
12 - Journey fields extracted per booking into one schema

Changes

The proof of concept did what it set out to do. Running the client's own sample documents through the pipeline, the model reliably read every format we tested and produced consistent, structured journey records from each of them, demonstrating that AI-led intake is a workable path to removing the manual reading step.

Format coverage proven — Emails, Excel schedules, Word proformas and printed PDF run sheets were all read by the same pipeline, without a separate template for each.
Complete journey capture — Each booking was resolved to a full set of operational fields, with repeated bookings kept as separate journeys and missing details flagged rather than invented.
Machine-ready output — Every document produced a single structured JSON record, giving the client's output in a shape that downstream dispatch and scheduling tools can consume directly.
Passenger care built in — The model added a support suggestion for each journey, showing the approach can capture duty-of-care detail alongside logistics.

With the core extraction proven across every format the client handles, the natural next step is to harden the pipeline into a production intake service, connect it directly to the dispatch systems and validate accuracy at full daily volume. The proof of concept gives the client the evidence base to make that decision with confidence.