Plecs i recursos tècnics

Tot el que necessites per especificar transport a demanda, sense esmentar cap proveïdor

Escrit per a les dues persones que llegeixen una licitació abans que es publiqui: el tècnic que redacta els requisits i el revisor tècnic o jurídic que els ha de verificar. Extret de licitacions que hem respost en municipis i regions petits i mitjans. Res d’aquí requereix registre.

Biblioteca de requisits Obtén la plantilla editable

Dades de la plataforma per al teu annex de compliment

Model de prestació: SaaS, nativa al núvol
Allotjament: AWS Irlanda (UE)
Certificació de la infraestructura: ISO/IEC 27001
Disponibilitat: Superior al 99,5 %
Objectiu d’accessibilitat: Pautes WCAG 2.1 AA
Canals per al passatger: iOS, Android, web
API: REST, JWT (RFC 7519)
Arquitectura de clients: Multiclient, amb dades aïllades
Marca: Marca blanca disponible
Maquinari embarcat: Independent del proveïdor
Política ambiental: Publicada, disponible a petició
Antisuborn i codi ètic: Publicats, disponibles a petició

Biblioteca de requisits

Redacció que pots incorporar a un plec

Agrupats tal com s’estructuren les licitacions. Cada línia és una capacitat formulada amb claredat, perquè la puguis exigir a qualsevol licitador, no només a nosaltres.

Obtén tot això en un document editable →

01Arquitectura de la plataforma

Programari com a servei (SaaS), natiu al núvol, amb apps per a passatgers, apps per a conductors, un centre de control d’operacions, un motor d’optimització i una capa d’integració que comparteixen dades operatives en temps real.
Components modulars, de manera que es puguin introduir noves funcionalitats, integracions i configuracions sense interrompre un servei en funcionament.
Diversos models de servei coexistint en un mateix desplegament: rutes fixes, línies semiflexibles i operació a demanda totalment dinàmica en diferents zones i horaris.
Operació multiclient, en què les credencials només donen accés a les dades del client corresponent.

02Experiència del passatger

Aplicacions natives per a iOS i Android i una aplicació web, totes amb el procés de reserva complet.
Opció de marca blanca: interfície, colors, logotips, terminologia i documents legals adaptats a la identitat de l’autoritat o de l’operador.
Registre mitjançant un número de mòbil verificat amb validació per contrasenya d’un sol ús; camps addicionals (correu electrònic, data de naixement, identificació, elegibilitat) configurables per desplegament.
Viatges immediats i programats, reserves de diversos viatges, anada o anada i tornada, diversos passatgers en una sola reserva i un indicador d’accessibilitat, com ara l’ús de cadira de rodes.
Hora estimada de recollida i d’arribada, i la tarifa aplicable quan les tarifes estan activades, mostrades abans que el passatger confirmi.
Planificació multimodal: el passatger veu el trajecte complet, incloses les connexions amb el transport públic, les parades i les hores de sortida, no només el tram a demanda.
Seguiment del vehicle en temps real i notificacions del viatge.

03Experiència del conductor

Aplicacions natives per a conductors a iOS i Android i una aplicació web, amb autenticació i gestió de sessions.
Navegació pas a pas amb el trànsit en directe del proveïdor de rutes, i la seqüència de recollides i baixades actualitzada a mesura que canvia l’operació.
Execució del viatge per part del conductor: gestió de la pujada de passatgers i dels no presentats, estat de pauses i torns, i disponibilitat del vehicle que, en desactivar-la, atura immediatament les noves assignacions.
Les desviacions de ruta causades pel trànsit o per incidències es registren automàticament i la ruta es torna a optimitzar.
Independent del maquinari: l’operador pot aportar els dispositius i suports embarcats, o demanar al proveïdor que inclogui una tauleta Android robusta recomanada i un pla de dades.

04Operacions i atenció al client

Interfície d’assignació i control basada en el navegador, sense instal·lació local.
Rols diferenciats: comptes de controlador que creen, consulten i cancel·len reserves en nom d’un passatger; administradors que, a més, gestionen vehicles, conductors, torns, zones, horaris i permisos.
Accés limitat a les zones i operacions per a les quals cada usuari està autoritzat, revocable en qualsevol moment per un administrador.
Estat en temps real de cada vehicle i de cada reserva de tota l’operació, a més de consulta històrica.

05Configuració del servei

Zones de servei definides i editades per l’operador, incloent-hi la creació, activació i desactivació de parades virtuals, la visualització al mapa, el filtratge per estat i l’exportació per a informes.
Operació porta a porta sense parades fixes, des de l’adreça d’origen fins a l’adreça de destinació: el model més adequat per a serveis orientats a l’accessibilitat.
Horaris de servei per vehicle, per dia de la setmana i per tipus de sol·licitud, amb excepcions per a festius o reduccions planificades que tenen prioritat sobre l’horari general.
Regles de carrer personalitzades per a carrers o girs prohibits, com ara carrers estrets o trams exclusius per a autobusos, que el motor de rutes ha de respectar.
Subzones i restriccions de desplaçament, perquè determinades parades es puguin reservar per a determinats vehicles, i zones superposades que comparteixin un subconjunt de parades.
Canvis de configuració fets directament per l’operador, amb intervenció del proveïdor o sense.

06Requisits no funcionals

Disponibilitat del servei superior al 99,5 %, sobre microserveis escalables de manera independent darrere d’equilibradors de càrrega redundants, amb l’entorn de proves separat del de producció.
Una proposta de viatge retornada al passatger en pocs segons després de la sol·licitud, equilibrant el temps d’espera amb la qualitat de la solució.
Un SLA de resposta a incidències definit, amb temps de resolució diferenciats per gravetat entre incidències bloquejants i no bloquejants.
Registre complet d’esdeveniments: moviments dels vehicles amb hora i coordenades, senyals de vida de l’aplicació del conductor, pauses i canvis de torn, esdeveniments del cicle de vida de les reserves, usuaris registrats i registres d’accés al tauler.
App del passatger, app del conductor i tauler multiidioma, amb la possibilitat d’afegir més idiomes durant la configuració del projecte.
WCAG 2.1 AA com a objectiu d’accessibilitat, amb compatibilitat nativa amb els lectors de pantalla VoiceOver i TalkBack: demana a qualsevol licitador, inclosos nosaltres, proves de conformitat actuals i no una declaració d’intencions.

07Protecció de dades i seguretat

Allotjament dins de la UE —Amazon Web Services, Irlanda— en una infraestructura certificada ISO/IEC 27001.
Control d’accés basat en rols a sistemes, aplicacions i informació, amb complexitat de contrasenyes obligatòria i credencials que mai no s’emmagatzemen en format llegible.
Suspensió del compte després de diversos intents d’inici de sessió fallits, per evitar atacs de força bruta.
Acceptació explícita dels termes i de la política de privadesa en el registre, tant a l’app com al tauler.
Una política de privadesa editable per projecte, perquè l’autoritat pugui emetre una versió d’acord amb la normativa local de protecció de dades.
Cap transferència internacional de dades sense l’autorització prèvia del responsable del tractament.

08Integracions

Una API REST oberta i documentada, amb autenticació de tercers mitjançant tokens JWT estàndard (RFC 7519) emesos per un endpoint dedicat després d’un intercanvi segur de credencials.
Un sistema de webhooks, perquè els sistemes de tercers rebin avisos quan es produeixen esdeveniments a la plataforma —per exemple, l’arribada d’un vehicle a un punt de recollida— en lloc de consultar l’API periòdicament.
Una API de MaaS que permeti a l’aplicació pròpia de l’autoritat mostrar la disponibilitat i gestionar tota la transacció de reserva, com l’app del passatger del proveïdor, com a part d’un trajecte multimodal més ampli.
Pagament mitjançant una passarel·la triada per l’operador o l’autoritat i configurable per zona de servei, en què el proveïdor actua estrictament com a pont i mai no custodia fons dels passatgers.
Exposició de les dades necessàries per integrar un sistema de venda de bitllets —usuaris, tarifes i preus, zones, parades i àrees—, amb la integració amb un sistema de cobrament o validació existent definida un cop identificat aquest sistema.
Incidències planificades integrades a la cartografia i al càlcul de rutes, perquè els carrers afectats es tinguin en compte quan es calculen les rutes.
Dades operatives i històriques per viatge —origen, destinació, hora de la sol·licitud, canal de la sol·licitud, estat del pagament, retards, temps d’espera i a bord— disponibles a petició, com a informes programats i al tauler.
Exportació al magatzem de dades o a les eines de BI de l’operador mitjançant l’API o, com a alternativa, per lliurament FTP programat.

Especifica això, no allò

On les licitacions de transport a demanda restringeixen el mercat sense voler

Sis patrons que veiem sovint. Cadascun lliga l’autoritat a un sol proveïdor o descarta el model de servei que de fet volia.

En lloc de«El sistema utilitzarà l’algorisme X per a l’assignació de vehicles.»ExigeixObjectius de resultat: temps d’espera màxim, desviació màxima, cobertura mínima de la zona de servei.Imposar un mètode n’exclou de millors i no es pot verificar en l’avaluació. Els objectius es poden mesurar en operació i fer complir en el contracte.
En lloc de«Els licitadors subministraran tauletes i suports per als vehicles.»ExigeixCompatibilitat amb dispositius Android i iOS estàndard, amb el subministrament de maquinari com a opció amb preu.Incloure el maquinari encareix l’oferta i lliga la flota al cicle de renovació d’un sol proveïdor. Si el vols, demana’l a part.
En lloc de«El servei funcionarà entre parades definides.»ExigeixSuport per a operació amb parades, amb parades virtuals i porta a porta, configurable per zona.Una clàusula només de parades exclou discretament el model porta a porta que els serveis accessibles i rurals solen necessitar més endavant.
En lloc de«El proveïdor facilitarà informes a petició.»ExigeixPropietat de les dades per viatge per part de l’autoritat, amb exportació programada per API o FTP i l’historial complet en finalitzar el contracte.Un informe és una captura de pantalla; les dades són un actiu. Sense una clàusula d’exportació, l’autoritat no pot avaluar la licitació següent.
En lloc de«El sistema s’integrarà amb el nostre sistema de venda de bitllets.»ExigeixUna API documentada que exposi usuaris, tarifes, zones i parades, més un abast d’integració concret acordat després de l’adjudicació.La integració sense definir és on desapareixen els pressupostos. Exigeix que la interfície existeixi; defineix la connexió concreta a part.
En lloc de«L’app del passatger serà accessible.»ExigeixConformitat amb WCAG 2.1 AA, compatibilitat nativa amb lectors de pantalla i un indicador d’accessibilitat en el moment de reservar.«Accessible» no es pot comprovar. Aquests tres requisits sí, i un proveïdor els compleix o no.

Models de servei

Defineix la flexibilitat que vols, no el vehicle que t’imagines

El transport a demanda és una escala, no un producte únic. La majoria de licitacions en defineixen un graó i s’hi queden encallades. Especifica el graó que necessites per zona i exigeix que passar d’un graó a un altre sigui un canvi de configuració, no un projecte nou.

El menys flexibleRuta fixaEl vehicle segueix un recorregut predefinit, com una línia convencional.Quan cal preservar una línia pública reconeixible.
Segon graóRuta flexibleEs manté un corredor general, amb desviacions permeses per recollir o deixar passatgers a prop.Previsible, però arriba més enllà de la línia.
Tercer graóAlimentadorEl servei connecta amb una estació, una terminal o un intercanviador en lloc d’una destinació.Primera i última milla fins a la xarxa troncal.
Quart graóDe cantonada a cantonadaParades virtuals o punts de trobada propers a l’origen i a la destinació, assignats pel sistema.Equilibra la comoditat amb l’eficiència de l’agrupació.
El més flexiblePorta a portaRecollida i baixada en adreces concretes dins de la zona autoritzada.Pobles, baixa densitat, mobilitat reduïda.

Diferents graons poden funcionar en un mateix desplegament, un per zona: parades virtuals al centre dens, porta a porta als pobles, un corredor flexible al llarg de la ruta troncal. Demana als licitadors que demostrin com canvien una zona d’un model a un altre des del tauler de control, amb l’historial del període anterior intacte i consultable per separat. És la manera més ràpida de distingir una plataforma configurable d’un desenvolupament a mida.

Paràmetres i llindars

Les xifres que hauria d’indicar una licitació de transport a demanda

Són els valors que decideixen si un servei sembla fiable o arbitrari. Si no s’indiquen, cada licitador en suposa els seus i les ofertes deixen de ser comparables. Els valors d’exemple són els que veiem funcionar a la pràctica, no una recomanació per a la teva zona.

Temps d’espera màxim: 15 min; Quant temps pot esperar un passatger entre la sol·licitud i la recollida. El factor que més pesa en la percepció de fiabilitat.
Desviació màxima: +30 %; Quant es pot allargar un trajecte per agrupar-hi un altre passatger. Fixa l’equilibri entre eficiència i paciència.
Capacitat del vehicle: 8 pax; Places disponibles per vehicle i quantes són per a cadira de rodes.
Prioritat d’accessibilitat: Prioritària; Si les reserves amb cadira de rodes es gestionen amb prioritat, i amb quin nivell de servei.
Temps mínim de transbordament: 5 min; El marge que es reserva en alimentar un tren o un bus, perquè no es perdi una connexió amb retard.
Resposta de recàlcul: < 5 s; Amb quina rapidesa s’ha de tornar a optimitzar el sistema després d’un canvi de paràmetre o d’una nova sol·licitud durant una demostració en directe.
Recuperació davant incidències: < 60 s; Amb quina rapidesa s’han de reassignar els passatgers quan un vehicle s’avaria a mig torn.
Franja de funcionament: 06:00–22:00; Hores de servei per zona, per dia de la setmana i per tipus de sol·licitud, més les excepcions per festius.

Qui és responsable de cada requisit

Una sola licitació sovint inclou alhora la planificació d’horaris, la venda de bitllets i l’operació a demanda. Els requisits recauen en sistemes diferents, i un licitador que respon per tots és o bé un consorci o bé exagera. Indica quin és quin.

La plataforma a demanda: Zones de servei i parades virtuals, paràmetres operatius, assignació de vehicles i agrupació, guiatge del conductor, supervisió en directe, KPI del servei a demanda, app del passatger i notificacions.
El sistema de planificació i horaris: Numeració i denominació de línies, estat i aprovació d’horaris, edició de temps de recorregut, blocs de serveis, comparació d’hores de sortida entre línies, atributs oficials de les parades.
La mateixa autoritat: Dades de costos per a l’anàlisi del cost per passatger, el nivell de servei que cal assolir, la política tarifària i el proveïdor de pagaments, la política de privadesa adreçada als passatgers i quins KPI són contractuals.

Obtén la llista de comprovació amb el repartiment ja fet →

Interoperabilitat i propietat de les dades

Les clàusules que decideixen si pots marxar

Una plataforma de transport a demanda se situa entre la teva venda de bitllets, el teu planificador de trajectes, la teva atenció al client i els teus informes. Si la licitació no defineix aquestes juntures, les defineix el licitador guanyador, i l’autoritat descobreix el cost de sortida anys després.

Aquests són els compromisos que assumim, redactats com a requisits que pots imposar a qualsevol licitador.

API oberta i documentada: Documentació tècnica pública, que es pot compartir amb l’equip d’integració de l’autoritat abans de l’adjudicació i no després.
Webhooks en lloc de consultes periòdiques: Els sistemes de tercers reben avisos quan es produeixen esdeveniments, de manera que les pantalles d’informació al passatger i el CRM es mantenen al dia sense saturar l’API.
L’app de l’autoritat ho pot fer tot: Una API de MaaS dedicada permet que una aplicació de tercers mostri la disponibilitat i gestioni tota la transacció de reserva, inclòs el pagament quan és ella mateixa qui el gestiona.
Els pagaments es queden amb el proveïdor de l’operador: L’operador o l’autoritat tria el proveïdor de pagaments, configurable per zona de servei. Shotl fa de pont i mai no cobra ni custodia fons dels passatgers.
Les dades són de l’autoritat i de l’operador: Com a propietaris de les dades, poden sol·licitar dades operatives i històriques en qualsevol moment, o rebre informes programats —normalment setmanals— per al consum automàtic.
La sortida és una clàusula, no una negociació: L’historial per viatge s’exporta mitjançant l’API o per FTP programat al magatzem de dades o a les eines de BI de l’operador.
Les incidències entren al càlcul de rutes, no en una trucada: Les obres i els talls planificats s’integren a la cartografia perquè les rutes els tinguin en compte abans que un conductor s’hi trobi.

Per al teu delegat de protecció de dades

Què inclou l’annex de privadesa

La infraestructura s’allotja a Amazon Web Services a Irlanda, dins de la UE, en una infraestructura certificada ISO/IEC 27001. Control d’accés basat en rols, complexitat de contrasenyes obligatòria, credencials que mai no s’emmagatzemen en format llegible i suspensió del compte després de diversos inicis de sessió fallits.

La política s’adapta a cada projecte, perquè l’autoritat i l’operador puguin emetre una versió d’acord amb la normativa local. No es fa cap transferència internacional sense l’autorització prèvia del responsable del tractament.

Les polítiques corporatives que hi ha darrere del producte —ambiental, codi ètic, antisuborn, codi de conducta— s’expliquen a sostenibilitat i ètica i estan disponibles com a documents signats.

Inclòs a la política per defecte

Identificació del responsable i de l’encarregat del tractament
Categories de dades recollides —identificadors, ubicació, historial de reserves, preferències d’ús— i si cadascuna és obligatòria o opcional
Les finalitats del tractament i la base jurídica de cadascuna
Les condicions en què les dades es poden compartir amb autoritats públiques o amb altres proveïdors que intervenen en el servei
Terminis de conservació
Drets de l’usuari: accés, rectificació, supressió, limitació, portabilitat i retirada del consentiment
La posició sobre les transferències internacionals, que requereixen l’autorització prèvia del responsable

Limitacions actuals

Què no fa avui la plataforma

Ho diem aquí en lloc que ho descobreixis durant l’avaluació. Si alguna d’aquestes limitacions és decisiva per al teu servei, indica-ho a la licitació i et respondrem directament.

Al full de rutaSense missatges de text lliure del conductor al centre de controlLes desviacions de ruta es registren i es tornen a optimitzar automàticament, però un conductor encara no pot enviar una nota escrita ni una descripció d’incidència al tauler. Avui aquesta conversa es fa per telèfon o per ràdio. Si és decisiu per a la teva operació, digues-ho i es pot prioritzar per al projecte.
Per dissenyLes reserves no s’editen directamentCanviar una hora de recollida o una destinació vol dir cancel·lar el viatge i tornar-lo a crear des del tauler. És deliberat: així cada trajecte modificat es torna a avaluar segons les condicions operatives del moment, en lloc d’heretar un pla obsolet.