Web App
Manifest AI: dall'email al gestionale, senza ricopiare nulla
Piattaforma che trasforma i manifest turistici ricevuti via email, in testo libero, in ordini di trasferimento strutturati, validati e pronti per il gestionale.
-
email di manifest processate
-
ordini generati
-
endpoint REST
-
esempi verificati a mano
In sintesi
In breve
- Manifest AI legge le email dei manifest di trasferimento e le converte in ordini strutturati, pronti da importare nel gestionale del tour operator.
- Un modello linguistico interpreta il testo descrittivo, mentre orari di pickup, validazioni e regole di business restano affidati a codice deterministico.
- Un insieme di esempi verificati a mano misura l'accuratezza: il modello scelto estrae correttamente il 90,6% dei campi.
- Se il servizio AI non risponde, l'estrazione ricade automaticamente su un motore a regole invece di fermarsi.
- In produzione: 8.655 blocchi servizio estratti da 379 email, backend FastAPI e frontend Next.js su Azure.
Qual era il problema
Un tour operator riceve via email i manifest dei trasferimenti: testo non strutturato, centinaia di blocchi per messaggio. Ogni blocco è una prenotazione (passeggeri, hotel, volo, veicolo, orari) scritta in inglese discorsivo, con formati incoerenti e informazioni sparse fra campi diversi.
Un operatore doveva leggere ogni blocco, capire di che servizio si trattasse, calcolare a mano l’orario di pickup in base al volo e all’aeroporto, e ricopiare tutto nel gestionale. Lavoro lento e ripetitivo, su dati dove un orario sbagliato significa un cliente lasciato a terra.
Email, servizi, ordini: tre stadi ispezionabili
La pipeline segue il percorso naturale del dato. Le email arrivano da una casella monitorata e vengono salvate integre; il corpo viene spezzato nei singoli blocchi servizio, riconoscendo nuove prenotazioni, modifiche e cancellazioni; ogni blocco diventa un ordine strutturato di circa 25 campi, con orario di pickup calcolato, richieste speciali rilevate e veicolo validato.
Ogni stadio è ispezionabile e correggibile, e l’operatore resta sempre l’ultimo ad approvare. Solo a quel punto l’ordine viene tradotto nel formato del gestionale di destinazione e inviato via API.
L'AI dove serve interpretare, le regole dove serve esattezza
La scelta architetturale centrale è non far fare al modello linguistico le cose che devono essere esatte. Il modello interpreta i campi descrittivi (passeggeri, veicolo, hotel, voli, commenti), dove le varianti linguistiche sono infinite, seguendo uno schema JSON generato dal modello dati dell’ordine.
Tutto ciò che deve essere esatto resta a codice deterministico: l’orario di pickup, le richieste speciali come seggiolini e sedie a rotelle, la coerenza fra veicolo e numero di passeggeri, le note operative per località. Il servizio più frequente, il trasferimento in partenza, è estratto interamente con espressioni regolari: formato stabile e volumi alti, dove il deterministico è più veloce, gratuito e ripetibile. E se il servizio AI non risponde, l’estrazione ricade su un motore a regole invece di fermarsi.
Il calcolo dell'orario di pickup
Non è una funzione di intelligenza artificiale, ed è proprio questo il punto. L’orario si ricava da una gerarchia esplicita di fonti: prima quello già confermato dal fornitore, poi quello confermato con il cliente, poi quello indicato dall’operatore, e solo in mancanza di tutti un calcolo automatico, dall’orario del volo o del treno meno il tempo di anticipo configurato, con riserva sugli orari di apertura dell’aeroporto.
Un indicatore distingue sempre l’orario dichiarato da quello calcolato, così l’operatore sa di cosa fidarsi. Le regole cambiano con il tipo di servizio (in partenza si calcola a ritroso dal volo, in arrivo l’orario è quello dell’atterraggio) e sono dati in tabella, modificabili dall’interfaccia: 39 configurazioni attive su 17 aeroporti.
Misurare se l'AI sta funzionando
Dentro l’applicazione c’è un insieme di esempi reali con l’output corretto verificato e approvato a mano. Serve a tre cose: come esempi nel prompt di estrazione, come test di regressione dopo ogni modifica alla pipeline, e come banco di prova per confrontare i modelli.
È così che è stato scelto il modello: su Groq, openai/gpt-oss-120b estrae correttamente il 90,6% dei campi contro l’84,7% di llama-3.3-70b, a costo inferiore. Il modello si cambia da una variabile d’ambiente, quindi si torna indietro senza un nuovo rilascio.
Le regole del mestiere, messe in codice
Molto del valore sta nelle regole di dominio. I trasferimenti verso Capri e Ischia vengono divisi automaticamente in tratte, traghetto più terra, con il motivo dello split tracciato; Venezia ha le sue regole per water taxi e servizi senza accompagnatore; alcune località generano da sole la nota per il fornitore, come l’attesa di trenta minuti dopo l’atterraggio a Fiumicino o il punto d’incontro a Roma Termini.
Le cancellazioni riconoscono lo schema della riprenotazione, con un abbinamento che non distrugge mai dati.
Com'è costruito
Backend in Python con FastAPI, SQLAlchemy 2.0 tipizzato e Pydantic v2, su Azure SQL con 20 migrazioni versionate. È la seconda versione: la prima era in Flask ed è stata riscritta mentre il sistema era già in produzione.
Frontend in Next.js 15, React e TypeScript con Tailwind CSS: 28 pagine applicative e modalità scura su tutta l’interfaccia. Autenticazione JWT con ruoli e permessi in tabella, allegati su Azure Blob Storage, rilascio su Azure Static Web Apps e App Service con GitHub Actions.
Il pacchetto
Cosa è stato consegnato
- Architettura dell'applicazione
- Backend FastAPI con 106 endpoint REST
- Frontend Next.js con 28 pagine applicative
- Pipeline di estrazione ibrida AI e regole
- Riscrittura del backend da Flask a FastAPI
- Rilascio su Azure con GitHub Actions
In dettaglio
Scheda tecnica
- Piattaforma: Web application su Azure
- Anno: 2025
- Stato: In produzione
- Tecnologie: Python, FastAPI, Next.js, TypeScript, Azure, LLM, SQLAlchemy, Web App, Automazione
Gli screenshot vengono dall’ambiente di produzione: sono sfocati il marchio del cliente e tutti i dati personali. Numeri rilevati il 20 settembre 2026.
Parliamone
Ti serve un software così?
Se hai un processo che oggi gestisci a mano e vorresti automatizzare, raccontamelo: capiamo insieme se ha senso costruirci sopra uno strumento.
