Come includere un software di trasporto a chiamata in una gara pubblica

Il trasporto a chiamata (DRT) sta assumendo un ruolo sempre più importante nelle strategie di trasporto pubblico. Città, agenzie per la mobilità e amministrazioni regionali ricorrono al DRT per migliorare la copertura, collegare le aree a bassa densità, favorire gli spostamenti di primo e ultimo miglio e offrire servizi di mobilità più flessibili dove le linee fisse non sempre sono efficienti.

Tuttavia, affidare un servizio DRT è diverso dall'affidare una linea di autobus tradizionale. Una gara DRT efficace deve definire non solo i veicoli e l'esercizio, ma anche la piattaforma software, i canali di prenotazione, la logica di instradamento, la proprietà dei dati, i requisiti di reportistica e l'integrazione con il resto della rete di trasporto pubblico.

Questo articolo illustra i principali elementi che le autorità pubbliche dovrebbero considerare quando preparano una gara DRT o includono un software di trasporto a chiamata all'interno di un contratto di mobilità più ampio.

Partire dalla definizione del problema di trasporto pubblico

Prima di specificare la tecnologia, l'ente dovrebbe definire che cosa ci si aspetta che il servizio DRT risolva. Il trasporto a chiamata può rispondere a esigenze di mobilità molto diverse e ogni caso d'uso può richiedere regole operative, funzionalità software e indicatori di prestazione differenti.

Tra i casi d'uso più comuni del DRT rientrano:

• Collegare aree rurali o a bassa densità con stazioni ferroviarie, nodi di interscambio degli autobus o centri urbani
• Offrire trasporto serale, notturno o nelle fasce di morbida, quando le linee fisse non sono sostenibili
• Sostituire o integrare linee di autobus con pochi passeggeri
• Migliorare l'accesso di primo e ultimo miglio alla rete di trasporto pubblico
• Supportare servizi di trasporto per persone con disabilità, mobilità accessibile o trasporto per specifiche categorie di utenti
• Gestire servizi di trasporto scolastico, aziendale o di comunità

Un servizio rurale di adduzione, per esempio, può richiedere una forte integrazione con gli orari dei treni e punti di raccolta flessibili. Un servizio per persone con disabilità può richiedere regole di idoneità, prenotazione assistita, veicoli accessibili alle sedie a rotelle e processi specifici di assistenza clienti. Queste differenze dovrebbero essere riflesse nella gara fin dall'inizio.

Scegliere il modello di gara DRT più adatto

Non esiste un unico modello di affidamento per il trasporto a chiamata. La struttura più adatta dipende dalle capacità interne dell'ente, dai contratti in essere con gli operatori, dal contesto normativo e dalla strategia di mobilità di lungo periodo.

Le autorità pubbliche scelgono in genere tra quattro modelli di gara principali:

• Gara per il solo software: l'ente acquista la piattaforma DRT e affida l'esercizio agli operatori di trasporto esistenti.
• Gara per il solo esercizio: l'ente dispone già della tecnologia o richiede all'operatore di lavorare con una piattaforma specifica.
• Gara integrata software ed esercizio: lo stesso aggiudicatario fornisce la tecnologia, i veicoli, gli autisti e la gestione del servizio.
• DRT all'interno di una gara multimodale: il servizio viene incluso come lotto o sottoservizio all'interno di un contratto di trasporto pubblico più ampio.

Una gara per il solo software può garantire all'ente un maggiore controllo sui dati, sulla progettazione del servizio e sulla scalabilità futura. Una gara integrata può ridurre la complessità di coordinamento, soprattutto per gli enti con risorse operative interne limitate. In entrambi i casi, la gara dovrebbe definire chiaramente le responsabilità tra ente, fornitore del software, operatore e team di assistenza clienti.

Definire i requisiti essenziali del software DRT

La piattaforma software è centrale per il successo di un servizio di trasporto a chiamata. Per questo la gara dovrebbe includere requisiti tecnici chiari, lasciando comunque ai concorrenti la possibilità di proporre il modo più efficace per raggiungere i risultati del servizio.

I requisiti tipici di un software DRT comprendono:

• App per i passeggeri per iOS e Android
• Portale web di prenotazione
• App per gli autisti con navigazione, informazioni sui passeggeri e aggiornamenti sulle corse
• Dashboard di back office per dispatching, monitoraggio e gestione del servizio
• Instradamento dinamico e funzionalità di ride pooling
• Localizzazione dei veicoli in tempo reale e orari di arrivo stimati
• Regole di prenotazione per zona, fascia oraria, tipologia di utente o categoria di servizio
• Supporto a fermate fisse, fermate virtuali e modelli porta a porta o da incrocio a incrocio
• Notifiche automatiche tramite app, SMS o e-mail
• Interfaccia multilingue e funzionalità di accessibilità
• Dashboard di reportistica e strumenti di esportazione dei dati

La gara dovrebbe inoltre spiegare come la piattaforma DRT debba integrarsi con i sistemi di trasporto pubblico esistenti. Ciò può includere API, piattaforme MaaS, travel planner, sistemi di bigliettazione, fornitori di pagamento o feed GTFS-RT. Senza questi requisiti, il servizio DRT rischia di funzionare come un sistema separato anziché diventare parte della rete di mobilità.

Prevedere opzioni di prenotazione per tutti gli utenti

Il DRT viene spesso utilizzato per migliorare l'accessibilità e l'inclusione. Per questo motivo, la gara non dovrebbe dare per scontato che tutti i passeggeri prenotino tramite un'app per smartphone.

Gli enti dovrebbero valutare se il servizio debba supportare:

• Prenotazione tramite app
• Prenotazione web
• Prenotazione telefonica tramite call center
• Prenotazione assistita da parte di dipendenti pubblici, caregiver o coordinatori della mobilità
• Prenotazioni ricorrenti per gli utenti abituali
• Flussi di prenotazione specifici per utenti in sedia a rotelle o passeggeri a mobilità ridotta

Questo aspetto è particolarmente importante per il trasporto rurale, la mobilità degli anziani, il trasporto legato ai servizi sanitari e i servizi per persone con disabilità. Una buona gara DRT dovrebbe definire non solo l'esperienza digitale, ma anche il modo in cui gli utenti non digitali potranno accedere al servizio.

Stabilire indicatori di prestazione chiari

I servizi di trasporto a chiamata dovrebbero essere misurati attraverso KPI chiari, realistici e specifici per il servizio. Questi indicatori aiutano l'ente a monitorare le prestazioni, confrontare i risultati e adattare il servizio nel tempo.

I KPI più comuni del DRT includono:

• Tempo medio di attesa
• Tasso di successo delle prenotazioni
• Corse passeggero per ora-veicolo
• Occupazione per veicolo
• Puntualità di salita e discesa
• Tempo medio di allungamento del percorso
• Tasso di mancata presentazione (no-show)
• Costo per corsa passeggero
• Indice di soddisfazione dei clienti
• Ripartizione delle prenotazioni tra app, web e telefono

La gara dovrebbe specificare con quale frequenza devono essere consegnati i report, quali dati devono essere disponibili in tempo reale e se l'ente richiede l'accesso ai dati operativi grezzi. È importante anche definire quali KPI sono obbligatori fin dall'avvio e quali devono servire a ottimizzare il servizio dopo un periodo pilota iniziale.

Chiarire la proprietà dei dati e la conformità al GDPR

I dati sono uno degli elementi più importanti di qualsiasi contratto DRT. L'ente dovrebbe definire chiaramente chi è il proprietario dei dati operativi, come vi si può accedere, per quanto tempo vengono conservati e come possono essere utilizzati per la pianificazione futura della mobilità.

La gara dovrebbe includere clausole relative a:

• Conformità al GDPR e protezione dei dati dei passeggeri
• Proprietà dei dati su corse, veicoli, passeggeri e prestazioni
• Accesso a dati aggregati e anonimizzati
• Formati di esportazione dei dati e frequenza dei report
• Requisiti di cybersicurezza
• Portabilità dei dati alla scadenza del contratto

Ciò è particolarmente importante quando il DRT fa parte di una strategia di trasporto pubblico di lungo periodo. Se l'accesso ai dati non è definito con chiarezza, l'ente potrebbe avere difficoltà a valutare il servizio, confrontare i fornitori o riprogettare la rete in futuro.

Evitare di specificare troppo l'algoritmo

Un errore frequente nelle gare DRT è voler definire ogni dettaglio dell'algoritmo di instradamento. Le autorità pubbliche dovrebbero specificare i risultati attesi, le regole del servizio e gli standard di prestazione, evitando però di limitare l'innovazione prescrivendo esattamente come debba funzionare la tecnologia.

Per esempio, la gara può definire i tempi massimi di attesa, i limiti accettati di allungamento del percorso, le zone di servizio, le finestre di prenotazione, le regole di accessibilità e i requisiti di reportistica. Il concorrente dovrebbe poi spiegare in che modo il proprio software DRT soddisferà tali requisiti attraverso la sua logica di instradamento, dispatching e raggruppamento delle corse.

Questo approccio permette all'ente di mantenere il controllo sugli obiettivi del servizio pubblico, lasciando al contempo ai fornitori di tecnologia la flessibilità necessaria per proporre soluzioni efficienti.

Definire il piano di implementazione e supporto

Una gara DRT non dovrebbe valutare soltanto il software. Dovrebbe valutare anche come il servizio verrà implementato, avviato, supportato e migliorato dopo la messa in esercizio.

Gli enti dovrebbero chiedere ai concorrenti di illustrare:

• Il cronoprogramma di implementazione
• La configurazione di zone, fermate, orari e regole di prenotazione
• La formazione di autisti, operatori di centrale e team di assistenza clienti
• La comunicazione ai passeggeri e il supporto al lancio
• La disponibilità dell'assistenza tecnica
• Il monitoraggio del servizio nelle prime settimane di esercizio
• La procedura per apportare modifiche dopo il lancio

Questo è particolarmente rilevante per i progetti pilota o per le prime attivazioni DRT. Anche la migliore piattaforma richiede una configurazione adeguata, coordinamento operativo e adozione da parte degli utenti per funzionare bene.

Errori comuni da evitare in una gara DRT

Nella preparazione di una gara per il trasporto a chiamata, le autorità pubbliche dovrebbero evitare alcuni errori frequenti:

• Acquistare il software senza definire il modello di servizio
• Concentrarsi solo sull'app per i passeggeri trascurando dispatching, reportistica ed esercizio
• Dimenticare la prenotazione telefonica o assistita per gli utenti non digitali
• Non definire la proprietà dei dati e i requisiti di esportazione
• Fissare fin dal primo giorno obiettivi irrealistici di tempo di attesa o di occupazione
• Non specificare i requisiti di accessibilità
• Non richiedere l'integrazione con i sistemi di trasporto pubblico o con i travel planner
• Utilizzare gli stessi KPI per casi d'uso DRT molto diversi
• Lasciare poco chiare le responsabilità dell'assistenza clienti
• Redigere specifiche tecniche che limitano l'innovazione invece di definire i risultati

Una gara ben progettata dovrebbe bilanciare chiarezza e flessibilità. Dovrebbe indicare ai concorrenti che cosa l'autorità pubblica vuole ottenere, quali requisiti minimi devono essere soddisfatti e come verrà misurato il successo.

Come valutare i fornitori di software DRT

Il processo di valutazione dovrebbe andare oltre il prezzo. Il trasporto a chiamata è un servizio operativo supportato da un software, quindi il fornitore selezionato deve essere in grado di dimostrare capacità tecniche, esperienza di implementazione e affidabilità nel lungo periodo.

Tra i criteri di valutazione utili rientrano:

• Esperienza in servizi DRT comparabili
• Qualità degli strumenti per passeggeri, autisti e back office
• Capacità di instradamento dinamico e raggruppamento delle corse
• Capacità di integrazione con i sistemi di mobilità esistenti
• Funzionalità di accessibilità e inclusione
• Capacità di reportistica e analisi dei dati
• Condizioni di proprietà e portabilità dei dati
• Metodologia di implementazione
• Modello di formazione e supporto
• Scalabilità per future zone, utenti o tipologie di servizio

In questo modo l'ente non seleziona semplicemente un fornitore di software, ma un partner in grado di sostenere un servizio di trasporto pubblico affidabile e adattabile.

Conclusione

Integrare il DRT in una gara pubblica richiede qualcosa di più che aggiungere una componente di mobilità on demand a un contratto esistente. Gli enti devono definire gli obiettivi del servizio, scegliere il modello di affidamento più adatto, specificare i requisiti software e operativi, tutelare i propri dati e stabilire indicatori di prestazione realistici.

Se progettata correttamente, una gara DRT può aiutare città e regioni a creare servizi di trasporto pubblico più flessibili, inclusivi ed efficienti. La chiave è concentrarsi sui risultati, evitare vincoli tecnologici non necessari e assicurarsi che il software di trasporto a chiamata selezionato possa sostenere sia il lancio sia l'evoluzione del servizio nel lungo periodo.

Stai preparando una gara DRT? Parla con Shotl per definire i requisiti software, operativi e sui dati del tuo servizio di trasporto a chiamata.