Preloader
Drag
Dashboard di Manifest AI con ordini, conversione e qualita dei dati
Web App

Manifest AI: from the email to the back office, with nothing retyped

A platform that turns tourist transfer manifests arriving by email, as free text, into structured transfer orders, validated and ready for the back office.

Get in touch

  • manifest emails processed

  • orders generated

  • REST endpoints

  • hand-checked examples

In summary

In brief

  • Manifest AI reads transfer manifest emails and converts them into structured orders, ready to import into the tour operator's back office.
  • A language model interprets the descriptive text, while pickup times, validation and business rules stay with deterministic code.
  • A set of hand-verified examples measures the accuracy: the chosen model extracts 90.6% of fields correctly.
  • If the AI service does not respond, extraction falls back automatically to a rules engine instead of stopping.
  • In production: 8,655 service blocks extracted from 379 emails, FastAPI back end and Next.js front end on Azure.

What the problem was

A tour operator receives transfer manifests by email: unstructured text, hundreds of blocks per message. Each block is a booking (passengers, hotel, flight, vehicle, times) written in conversational English, with inconsistent formats and information scattered across different fields.

An operator had to read every block, work out which service it was, calculate the pickup time by hand from the flight and the airport, and retype everything into the back office. Slow, repetitive work, on data where a wrong time means a customer left standing.

Guida integrata con il flusso da email a servizi a ordini

Emails, services, orders: three inspectable stages

The pipeline follows the natural path of the data. Emails arrive from a monitored mailbox and are stored intact; the body gets broken into individual service blocks, recognising new bookings, amendments and cancellations; each block becomes a structured order of around 25 fields, with the pickup time calculated, special requests detected and the vehicle validated.

Every stage can be inspected and corrected, and the operator is always the last to approve. Only at that point does the order get translated into the destination system’s format and sent over its API.

AI where interpretation is needed, rules where exactness is

The central architectural choice is not letting the language model do the things that have to be exact. The model interprets the descriptive fields (passengers, vehicle, hotel, flights, comments), where the linguistic variants are endless, following a JSON schema generated from the order’s data model.

Everything that has to be exact stays with deterministic code: the pickup time, special requests such as child seats and wheelchairs, the consistency between vehicle and passenger count, the operational notes by location. The most frequent service, the outbound transfer, is extracted entirely with regular expressions: stable format and high volume, where deterministic code is faster, free and repeatable. And if the AI service does not respond, extraction falls back to a rules engine instead of stopping.

Blocco di testo grezzo di un manifest affiancato ai campi estratti automaticamente
Configurazione delle regole di calcolo dell orario di pickup per aeroporti e stazioni

Calculating the pickup time

This is not an artificial intelligence feature, and that is precisely the point. The time is derived from an explicit hierarchy of sources: first the one already confirmed by the supplier, then the one confirmed with the customer, then the one given by the operator, and only in the absence of all of those an automatic calculation, from the flight or train time minus the configured lead time, with an allowance for the airport’s opening hours.

An indicator always distinguishes a stated time from a calculated one, so the operator knows what to trust. The rules change with the type of service (outbound is calculated backwards from the flight, inbound uses the landing time) and they are data held in a table, editable from the interface: 39 active configurations across 17 airports.

Measuring whether the AI is working

Inside the application there is a set of real examples with the correct output verified and approved by hand. It serves three purposes: as examples in the extraction prompt, as a regression test after every change to the pipeline, and as a bench for comparing models.

That is how the model was chosen: on Groq, openai/gpt-oss-120b extracts 90.6% of fields correctly against 84.7% for llama-3.3-70b, at a lower cost. The model is changed from an environment variable, so going back does not need a new release.

Dataset di esempi verificati usato per misurare l accuratezza dell estrazione

The rules of the trade, put into code

Much of the value sits in the domain rules. Transfers to Capri and Ischia get split automatically into legs, ferry plus land, with the reason for the split recorded; Venice has its own rules for water taxis and services without an escort; some locations generate the note for the supplier by themselves, such as the thirty-minute wait after landing at Fiumicino or the meeting point at Roma Termini.

Cancellations recognise the rebooking pattern, with a matching process that never destroys data.

How it is built

Back end in Python with FastAPI, typed SQLAlchemy 2.0 and Pydantic v2, on Azure SQL with 20 versioned migrations. This is the second version: the first was in Flask and was rewritten while the system was already in production.

Front end in Next.js 15, React and TypeScript with Tailwind CSS: 28 application pages and dark mode across the whole interface. JWT authentication with roles and permissions held in a table, attachments on Azure Blob Storage, release to Azure Static Web Apps and App Service with GitHub Actions.

Dashboard di Manifest AI con azioni rapide e distribuzione degli ordini
The package

What was delivered

  • Application architecture
  • FastAPI back end with 106 REST endpoints
  • Next.js front end with 28 application pages
  • Hybrid AI and rules extraction pipeline
  • Back end rewritten from Flask to FastAPI
  • Release to Azure with GitHub Actions
In detail

Technical details

  • Platform: Web application on Azure
  • Year: 2025
  • Status: In production
  • Technologies: Python, FastAPI, Next.js, TypeScript, Azure, LLM, SQLAlchemy, Web App, Automation

The screenshots come from the production environment: the client’s brand and all personal data are blurred. Figures recorded on 20 September 2026.

Let's talk

Do you need software like this?

If you have a process you handle by hand today and would like to automate, tell me about it: we work out together whether it makes sense to build a tool on top of it.

Need something similar? This project is an example of AI automation. The first meeting and the quote are free: write to me and we will talk it through.