Capitolati e risorse tecniche

Tutto ciò che serve per specificare il trasporto a chiamata — senza nominare un fornitore

Scritto per le due persone che leggono una gara prima che venga pubblicata: chi redige i requisiti e il revisore tecnico o legale che deve verificarli. Tratto dalle gare a cui abbiamo risposto in comuni e regioni di piccole e medie dimensioni. Niente qui richiede una registrazione.

Libreria di requisiti Scarica il modello modificabile

Dati della piattaforma per il tuo allegato di conformità

Modello di fornitura: SaaS, cloud-native
Hosting: AWS Irlanda (UE)
Certificazione dell’infrastruttura: ISO/IEC 27001
Disponibilità: Superiore al 99,5%
Obiettivo di accessibilità: Linee guida WCAG 2.1 AA
Canali per i passeggeri: iOS, Android, web
API: REST, JWT (RFC 7519)
Tenancy: Multi-tenant, dati isolati
Marchio: White label disponibile
Hardware di bordo: Indipendente dal fornitore
Politica ambientale: Pubblicata, su richiesta
Anticorruzione e codice etico: Pubblicati, su richiesta

Libreria di requisiti

Testi da riportare direttamente in un capitolato

Raggruppati come sono strutturate le gare. Ogni riga è una funzionalità descritta in modo semplice, così puoi richiederla a qualsiasi concorrente — non solo a noi.

Scarica tutto come documento modificabile →

01Architettura della piattaforma

Software-as-a-Service, cloud-native, con app per i passeggeri, app per gli autisti, una centrale operativa, un motore di ottimizzazione e un livello di integrazione che condividono i dati operativi in tempo reale.
Componenti modulari, così che nuove funzionalità, integrazioni e configurazioni si possano introdurre senza interrompere un servizio in esercizio.
Più modelli di servizio coesistenti in un’unica installazione — percorsi fissi, linee semi-flessibili ed esercizio a chiamata completamente dinamico in aree e orari diversi.
Funzionamento multi-tenant, in cui le credenziali danno accesso solo ai dati del cliente corrispondente.

02Esperienza del passeggero

Applicazioni native iOS e Android più un’applicazione web, tutte in grado di coprire l’intero processo di prenotazione.
Opzione white label: interfaccia, colori, loghi, terminologia e documenti legali adattati all’identità dell’ente o dell’operatore.
Registrazione tramite numero di cellulare verificato con convalida tramite password monouso; campi aggiuntivi (e-mail, data di nascita, documento di identità, requisiti di idoneità) configurabili per installazione.
Corse immediate e programmate, prenotazioni multiple, corse di sola andata o di andata e ritorno, più passeggeri in una sola prenotazione e un indicatore di accessibilità, ad esempio per l’uso della sedia a rotelle.
Orario stimato di prelievo e di arrivo, e tariffa applicabile dove le tariffe sono attive, mostrati prima che il passeggero confermi.
Pianificazione multimodale: il passeggero vede il viaggio completo, comprese coincidenze con il trasporto pubblico, fermate e orari di partenza, non solo la tratta a chiamata.
Posizione del veicolo in tempo reale e notifiche sul viaggio.

03Esperienza dell’autista

Applicazioni native iOS e Android per gli autisti più un’applicazione web, con autenticazione e gestione della sessione.
Navigazione passo passo con il traffico in tempo reale del fornitore di routing, con la sequenza di prelievi e discese aggiornata al variare dell’esercizio.
Esecuzione della corsa lato autista: gestione delle salite e dei passeggeri assenti, stato di pausa e di turno, e disponibilità del veicolo che, se impostata, blocca subito nuove assegnazioni.
Le deviazioni dal percorso dovute a traffico o incidenti vengono registrate automaticamente e il percorso viene riottimizzato.
Indipendente dall’hardware: l’operatore può fornire i dispositivi e i supporti di bordo, oppure chiedere al fornitore di includere un tablet Android rugged consigliato e un piano dati.

04Esercizio e assistenza clienti

Interfaccia di assegnazione e controllo basata su browser, senza installazione locale.
Ruoli differenziati: account di controllo che creano, visualizzano e annullano prenotazioni per conto del passeggero; amministratori che gestiscono inoltre veicoli, autisti, turni, aree, orari e permessi.
Accesso limitato alle aree e alle operazioni per cui ciascun utente è autorizzato, revocabile in qualsiasi momento da un amministratore.
Stato in tempo reale di ogni veicolo e prenotazione dell’intero servizio, oltre alla consultazione dello storico.

05Configurazione del servizio

Aree di servizio definite e modificate dall’operatore, con creazione, attivazione e disattivazione di fermate virtuali, visualizzazione su mappa, filtro per stato ed esportazione per i report.
Esercizio porta a porta senza fermate fisse, dall’indirizzo di origine all’indirizzo di destinazione — il modello più adatto ai servizi orientati all’accessibilità.
Orari di servizio per veicolo, per giorno della settimana e per tipo di richiesta, con eccezioni per festivi o riduzioni programmate che prevalgono sull’orario generale.
Regole stradali personalizzate per vie o svolte vietate, come strade strette o tratti riservati ai bus, che il motore di routing deve rispettare.
Sottoaree e restrizioni di movimento, così che alcune fermate possano essere riservate a determinati veicoli, e aree sovrapposte che condividono un sottoinsieme di fermate.
Modifiche di configurazione eseguite direttamente dall’operatore, con o senza intervento del fornitore.

06Requisiti non funzionali

Disponibilità del servizio superiore al 99,5%, su microservizi scalabili in modo indipendente dietro bilanciatori di carico ridondanti, con l’ambiente di staging separato da quello di produzione.
Una proposta di viaggio restituita al passeggero entro pochi secondi dalla richiesta, bilanciando tempo di attesa e qualità della soluzione.
Uno SLA di risposta agli incidenti definito, con tempi di risoluzione differenziati per gravità tra incidenti bloccanti e non bloccanti.
Registrazione completa degli eventi: movimenti dei veicoli con orario e coordinate, heartbeat dell’app autista, pause e cambi turno, eventi del ciclo di vita delle prenotazioni, utenti registrati e log di accesso alla dashboard.
App passeggeri, app autisti e dashboard multilingue, con la possibilità di aggiungere altre lingue durante la configurazione del progetto.
WCAG 2.1 AA come obiettivo di accessibilità, con supporto nativo ai lettori di schermo VoiceOver e TalkBack — chiedi a ogni concorrente, noi compresi, prove di conformità aggiornate e non una semplice intenzione.

07Protezione dei dati e sicurezza

Hosting nell’UE — Amazon Web Services, Irlanda — su infrastruttura certificata ISO/IEC 27001.
Controllo degli accessi basato sui ruoli a sistemi, applicazioni e informazioni, con complessità delle password obbligatoria e credenziali mai memorizzate in forma leggibile.
Sospensione dell’account dopo ripetuti tentativi di accesso falliti, per prevenire attacchi a forza bruta.
Accettazione esplicita dei termini e dell’informativa privacy alla registrazione, sia nell’app sia nella dashboard.
Un’informativa privacy modificabile per progetto, così che l’ente possa emetterne una versione conforme alla normativa locale sulla protezione dei dati.
Nessun trasferimento internazionale di dati senza la previa autorizzazione del titolare del trattamento.

08Integrazioni

Un’API REST aperta e documentata, con autenticazione di terzi tramite token JWT standard (RFC 7519) emessi da un endpoint dedicato dopo uno scambio sicuro di credenziali.
Un sistema di webhook, così che i sistemi di terzi vengano avvisati quando si verificano eventi sulla piattaforma — ad esempio un veicolo che arriva a un punto di prelievo — invece di interrogare l’API.
Un’API MaaS che consenta all’app dell’ente di mostrare la disponibilità e gestire l’intera transazione di prenotazione, replicando l’app passeggeri del fornitore, all’interno di un viaggio multimodale più ampio.
Pagamento tramite un gateway scelto dall’operatore o dall’ente e configurabile per area di servizio, con il fornitore che agisce esclusivamente da ponte e non detiene mai i fondi dei passeggeri.
Esposizione dei dati necessari a integrare un sistema di bigliettazione — utenti, tariffe e prezzi, zone, fermate e aree — con l’integrazione a un sistema di bigliettazione o validazione esistente definita una volta identificato tale sistema.
Interruzioni programmate integrate nella cartografia e nel routing, così che le vie interessate siano considerate nel calcolo dei percorsi.
Dati operativi e storici a livello di singola corsa — origine, destinazione, orario e canale della richiesta, stato del pagamento, ritardi, tempi di attesa e a bordo — disponibili su richiesta, come report programmati e nella dashboard.
Esportazione verso il data warehouse o gli strumenti di BI dell’operatore tramite API o, in alternativa, con consegna programmata via FTP.

Specifica questo, non quello

Dove le gare DRT restringono involontariamente la concorrenza

Sei schemi che vediamo ripetersi. Ognuno vincola l’ente a un solo fornitore oppure esclude il modello di servizio che voleva davvero.

Invece di«Il sistema deve utilizzare l’algoritmo X per l’assegnazione dei veicoli.»RichiediObiettivi di risultato: tempo di attesa massimo, deviazione massima, copertura minima dell’area di servizio.Imporre un metodo esclude quelli migliori ed è inverificabile in sede di valutazione. Gli obiettivi si possono misurare in esercizio e far rispettare nel contratto.
Invece di«I concorrenti devono fornire tablet e supporti di bordo.»RichiediCompatibilità con dispositivi Android e iOS standard, con la fornitura di hardware come opzione quotata a parte.Includere l’hardware gonfia l’offerta e lega la flotta al ciclo di sostituzione di un solo fornitore. Se lo vuoi, chiedilo a parte.
Invece di«Il servizio deve operare tra fermate definite.»RichiediSupporto all’esercizio con fermate fisse, fermate virtuali e porta a porta, configurabile per area.Una clausola solo-fermate esclude silenziosamente il modello porta a porta di cui i servizi accessibili e rurali di solito hanno bisogno in seguito.
Invece di«Il fornitore deve fornire report su richiesta.»RichiediProprietà dell’ente sui dati a livello di singola corsa, con esportazione programmata via API o FTP e storico completo all’uscita.Un report è una fotografia; i dati sono un patrimonio. Senza una clausola di esportazione l’ente non può valutare la gara successiva.
Invece di«Il sistema deve integrarsi con la nostra bigliettazione.»RichiediUn’API documentata che esponga utenti, tariffe, zone e fermate, più un perimetro di integrazione definito e concordato dopo l’aggiudicazione.È nelle integrazioni non definite che i budget spariscono. Richiedi che l’interfaccia esista; definisci a parte il collegamento specifico.
Invece di«L’app per i passeggeri deve essere accessibile.»RichiediConformità WCAG 2.1 AA, supporto nativo ai lettori di schermo e un indicatore di accessibilità al momento della prenotazione.«Accessibile» non è verificabile. Questi tre requisiti sì, e un fornitore o li soddisfa o no.

Modelli di servizio

Indica la flessibilità che vuoi, non il veicolo che immagini

Il trasporto a chiamata è una scala, non un singolo prodotto. La maggior parte delle gare indica un solo gradino e ci resta bloccata. Specifica il gradino che ti serve per ogni area — e richiedi che passare da un gradino all’altro sia una modifica di configurazione, non un nuovo progetto.

Il meno flessibilePercorso fissoIl veicolo segue un percorso predefinito, come una linea tradizionale.Quando va mantenuta una linea pubblica riconoscibile.
Secondo gradinoPercorso flessibileSi mantiene un corridoio generale, con deviazioni consentite per prelevare o far scendere nelle vicinanze.Prevedibile, ma raggiunge zone oltre la linea.
Terzo gradinoAdduzioneIl servizio porta a una stazione, un terminal o un nodo di interscambio anziché a una destinazione.Primo e ultimo miglio verso la rete principale.
Quarto gradinoDa incrocio a incrocioFermate virtuali o punti di incontro vicini a origine e destinazione, assegnati dal sistema.Bilancia comodità ed efficienza del raggruppamento.
Il più flessibilePorta a portaPrelievo e discesa a indirizzi specifici all’interno dell’area autorizzata.Frazioni, bassa densità, mobilità ridotta.

Gradini diversi possono convivere nella stessa installazione, uno per area — fermate virtuali nel centro denso, porta a porta nelle frazioni, un corridoio flessibile lungo la direttrice principale. Chiedi ai concorrenti di dimostrare il passaggio di un’area da un modello all’altro dal pannello di controllo, con lo storico del periodo precedente intatto e rendicontabile separatamente. È il modo più rapido per distinguere una piattaforma configurabile da uno sviluppo su misura.

Parametri e soglie

I numeri che una gara DRT dovrebbe indicare

Sono i valori che decidono se un servizio appare affidabile o arbitrario. Se non vengono indicati, ogni concorrente assume i propri — e le offerte diventano incomparabili. I valori di esempio sono quelli che vediamo funzionare nella pratica, non una raccomandazione per la tua area.

Tempo di attesa massimo: 15 min; Quanto può attendere un passeggero tra la richiesta e il prelievo. Il fattore che più di ogni altro determina l’affidabilità percepita.
Deviazione massima: +30%; Di quanto si può allungare un viaggio per raggruppare un altro passeggero. Stabilisce il compromesso tra efficienza e pazienza.
Capienza del veicolo: 8 pax; Posti disponibili per veicolo, e quanti di questi sono postazioni per sedia a rotelle.
Priorità per l’accessibilità: Priorità; Se le prenotazioni con sedia a rotelle vengono gestite con priorità, e rispetto a quale livello di servizio.
Tempo minimo di coincidenza: 5 min; Il margine mantenuto quando si porta a un treno o a un bus, così che una coincidenza in ritardo non venga persa.
Tempo di ricalcolo: < 5 s; Quanto rapidamente il sistema deve riottimizzare dopo una modifica dei parametri o una nuova richiesta durante una dimostrazione dal vivo.
Ripristino in caso di guasto: < 60 s; Quanto rapidamente i passeggeri devono essere riassegnati quando un veicolo si guasta durante il turno.
Fascia di servizio: 06:00–22:00; Orari di servizio per area, per giorno della settimana e per tipo di richiesta, più le eccezioni per i festivi.

Chi è responsabile di quale requisito

Una singola gara spesso copre insieme pianificazione degli orari, bigliettazione ed esercizio a chiamata. I requisiti ricadono su sistemi diversi, e un concorrente che risponde per tutti è o un raggruppamento o sta esagerando. Specifica cosa spetta a chi.

La piattaforma a chiamata: Aree di servizio e fermate virtuali, parametri operativi, assegnazione dei veicoli e raggruppamento delle corse, guida dell’autista, supervisione in tempo reale, KPI del servizio a chiamata, app passeggeri e notifiche.
Il sistema di pianificazione e orari: Numerazione e denominazione delle linee, stato e approvazione degli orari, modifica dei tempi di percorrenza, turni macchina, confronto degli orari di partenza tra linee, attributi ufficiali delle fermate.
L’ente stesso: Dati di costo per l’analisi del costo per passeggero, livello di servizio da garantire, politica tariffaria e fornitore dei pagamenti, informativa privacy rivolta ai passeggeri, e quali KPI sono contrattuali.

Scarica la checklist con la suddivisione già fatta →

Interoperabilità e proprietà dei dati

Le clausole che decidono se puoi andartene

Una piattaforma DRT sta tra la tua bigliettazione, il tuo travel planner, la tua assistenza clienti e la tua reportistica. Se la gara non definisce questi punti di contatto, li definisce il concorrente che vince — e l’ente scopre il costo dell’uscita anni dopo.

Questi sono gli impegni che prendiamo, scritti come requisiti che puoi imporre a qualsiasi concorrente.

API aperta e documentata: Documentazione tecnica pubblica, condivisibile con il team di integrazione dell’ente prima dell’aggiudicazione e non dopo.
Webhook invece del polling: I sistemi di terzi vengono avvisati quando si verificano gli eventi, così pannelli informativi e CRM restano aggiornati senza sovraccaricare l’API.
L’app dell’ente può fare tutto: Un’API MaaS dedicata permette a un’applicazione di terzi di mostrare la disponibilità e gestire l’intera transazione di prenotazione, pagamento compreso quando lo gestisce direttamente.
I pagamenti restano al fornitore dell’operatore: L’operatore o l’ente sceglie il fornitore dei pagamenti, configurabile per area di servizio. Shotl fa da ponte e non incassa né detiene mai i fondi dei passeggeri.
I dati appartengono all’ente e all’operatore: In quanto proprietari dei dati, possono richiedere in qualsiasi momento dati operativi e storici, o ricevere report programmati — di solito settimanali — per l’elaborazione automatica.
L’uscita è una clausola, non una trattativa: Lo storico a livello di singola corsa si esporta tramite API o FTP programmato verso il data warehouse o gli strumenti di BI dell’operatore.
Le interruzioni entrano nel routing, non in una telefonata: Lavori programmati e chiusure sono integrati nella cartografia, così i percorsi ne tengono conto prima che un autista li incontri.

Per il tuo responsabile della protezione dei dati

Cosa copre l’allegato sulla privacy

L’infrastruttura è ospitata su Amazon Web Services in Irlanda, nell’UE, su infrastruttura certificata ISO/IEC 27001. Controllo degli accessi basato sui ruoli, complessità delle password obbligatoria, credenziali mai memorizzate in forma leggibile e sospensione dell’account dopo ripetuti accessi falliti.

L’informativa stessa si adatta a ogni progetto, così che l’ente e l’operatore possano emetterne una versione conforme alla normativa locale. Nessun trasferimento internazionale avviene senza la previa autorizzazione del titolare del trattamento.

Le politiche aziendali alla base del prodotto — politica ambientale, codice etico, anticorruzione, codice di condotta — sono illustrate in sostenibilità ed etica e disponibili come documenti firmati.

Trattato nell’informativa standard

Identificazione del titolare e del responsabile del trattamento
Categorie di dati raccolti — identificativi, posizione, storico delle prenotazioni, preferenze d’uso — e se ciascuna è obbligatoria o facoltativa
Le finalità del trattamento e la base giuridica di ciascuna
Le condizioni alle quali i dati possono essere condivisi con autorità pubbliche o altri fornitori coinvolti nel servizio
Tempi di conservazione
Diritti dell’utente: accesso, rettifica, cancellazione, limitazione, portabilità e revoca del consenso
La posizione sui trasferimenti internazionali, che richiedono la previa autorizzazione del titolare

Limiti attuali

Cosa la piattaforma oggi non fa

Li dichiariamo qui invece di farli scoprire in sede di valutazione. Se uno di questi è decisivo per il tuo servizio, indicalo nella gara e risponderemo direttamente.

In roadmapNessun messaggio di testo libero dall’autista alla centraleLe deviazioni dal percorso vengono registrate e riottimizzate automaticamente, ma un autista non può ancora inviare una nota scritta o la descrizione di un incidente alla dashboard. Oggi questa comunicazione avviene per telefono o via radio. Se è decisiva per il tuo esercizio, indicalo e potrà avere priorità nel progetto.
Per scelta progettualeLe prenotazioni non si modificano direttamenteCambiare un orario di prelievo o una destinazione significa annullare e ricreare la corsa dalla dashboard. È voluto: ogni viaggio modificato viene così rivalutato rispetto alle condizioni operative attuali invece di ereditare un piano superato.