Pliegos y recursos técnicos

Todo lo que necesitas para especificar transporte a demanda, sin nombrar a ningún proveedor

Escrito para las dos personas que leen una licitación antes de publicarla: quien redacta los requisitos y quien, desde la parte técnica o jurídica, tiene que verificarlos. Basado en licitaciones a las que hemos respondido en municipios y regiones pequeños y medianos. Todo es de libre acceso.

Biblioteca de requisitos Descarga la plantilla editable

Datos de la plataforma para tu anexo de cumplimiento

Modelo de entrega: SaaS, nativo en la nube
Alojamiento: AWS Irlanda (UE)
Certificación de la infraestructura: ISO/IEC 27001
Disponibilidad: Superior al 99,5 %
Objetivo de accesibilidad: Pautas WCAG 2.1 AA
Canales para pasajeros: iOS, Android, web
API: REST, JWT (RFC 7519)
Arquitectura: Multicliente, datos aislados
Marca: Marca blanca disponible
Hardware embarcado: Independiente del proveedor
Política medioambiental: Publicada, disponible bajo petición
Antisoborno y código ético: Publicados, disponibles bajo petición

Biblioteca de requisitos

Redacción que puedes llevar directamente a un pliego

Agrupados como se estructuran las licitaciones. Cada línea es una capacidad expresada con claridad, para que puedas exigírsela a cualquier licitador, no solo a nosotros.

Descarga todo esto como documento editable →

01Arquitectura de la plataforma

Software como servicio (SaaS), nativo en la nube, con apps de pasajeros, apps de conductores, un centro de control de operaciones, un motor de optimización y una capa de integración que comparten datos operativos en tiempo real.
Componentes modulares, de modo que puedan incorporarse nuevas funcionalidades, integraciones y configuraciones sin interrumpir un servicio en marcha.
Coexistencia de varios modelos de servicio en un mismo despliegue: rutas fijas, líneas semiflexibles y operación a demanda totalmente dinámica en distintas zonas y horarios.
Operación multicliente, en la que las credenciales dan acceso únicamente a los datos del cliente correspondiente.

02Experiencia del pasajero

Aplicaciones nativas para iOS y Android y una aplicación web, todas ellas con el proceso de reserva completo.
Opción de marca blanca: interfaz, colores, logotipos, terminología y documentos legales adaptados a la identidad de la autoridad o del operador.
Registro mediante un número de móvil verificado con validación por contraseña de un solo uso; campos adicionales (correo electrónico, fecha de nacimiento, identificación, elegibilidad) configurables en cada despliegue.
Viajes inmediatos y programados, reservas de varios viajes, trayectos de ida o de ida y vuelta, varios pasajeros en una misma reserva e indicador de accesibilidad, como el uso de silla de ruedas.
Hora estimada de recogida y de llegada, y la tarifa aplicable cuando las tarifas estén activadas, mostradas antes de que el pasajero confirme.
Planificación multimodal: el pasajero ve el trayecto completo, incluidas las conexiones con el transporte público, las paradas y las horas de salida, no solo el tramo a demanda.
Seguimiento del vehículo en tiempo real y notificaciones del viaje.

03Experiencia del conductor

Aplicaciones nativas para conductores en iOS y Android y una aplicación web, con autenticación y gestión de sesiones.
Navegación paso a paso con tráfico en directo del proveedor de rutas, con la secuencia de recogidas y bajadas actualizada a medida que cambia la operación.
Ejecución del viaje desde el lado del conductor: subida de pasajeros y gestión de no presentados, estado de pausas y turnos, y disponibilidad del vehículo que, al desactivarse, detiene de inmediato nuevas asignaciones.
Las desviaciones de ruta causadas por tráfico o incidencias se registran automáticamente y la ruta se reoptimiza.
Independencia del hardware: el operador puede aportar los dispositivos y soportes embarcados, o pedir al proveedor que incluya una tableta Android robusta recomendada y un plan de datos.

04Operación y atención al cliente

Interfaz de despacho y control basada en navegador, sin instalación local.
Roles diferenciados: cuentas de controlador que crean, consultan y cancelan reservas en nombre de un pasajero; administradores que, además, gestionan vehículos, conductores, turnos, zonas, horarios y permisos.
Acceso limitado a las zonas y operaciones para las que cada usuario está autorizado, revocable en cualquier momento por un administrador.
Estado en tiempo real de cada vehículo y cada reserva de la operación, además de consulta histórica.

05Configuración del servicio

Zonas de servicio definidas y editadas por el operador, incluida la creación, activación y desactivación de paradas virtuales, su visualización en mapa, el filtrado por estado y la exportación para informes.
Operación puerta a puerta sin paradas fijas, de la dirección de origen a la de destino: el modelo más adecuado para servicios orientados a la accesibilidad.
Horario de servicio por vehículo, por día de la semana y por tipo de solicitud, con excepciones por festivos o reducciones planificadas que prevalecen sobre el horario general.
Reglas viarias personalizadas para calles o giros prohibidos, como callejones estrechos o tramos solo bus, que el motor de rutas debe respetar.
Subzonas y restricciones de movimiento, para reservar determinadas paradas a determinados vehículos, y zonas solapadas que comparten un subconjunto de paradas.
Cambios de configuración realizados directamente por el operador, con o sin intervención del proveedor.

06Requisitos no funcionales

Disponibilidad del servicio superior al 99,5 %, sobre microservicios escalables de forma independiente tras balanceadores de carga redundantes, con el entorno de preproducción separado del de producción.
Una propuesta de viaje devuelta al pasajero en pocos segundos desde la solicitud, equilibrando el tiempo de espera con la calidad de la solución.
Un SLA de respuesta a incidencias definido, con tiempos de resolución diferenciados por gravedad entre incidencias bloqueantes y no bloqueantes.
Registro completo de eventos: movimientos de vehículos con hora y coordenadas, señales de actividad de la aplicación del conductor, pausas y cambios de turno, eventos del ciclo de vida de las reservas, usuarios registrados y registros de acceso al panel.
App de pasajeros, app de conductores y panel multilingües, con la posibilidad de añadir más idiomas durante la configuración del proyecto.
WCAG 2.1 AA como objetivo de accesibilidad, con soporte nativo de lector de pantalla para VoiceOver y TalkBack: pide a cualquier licitador, nosotros incluidos, evidencias actuales de conformidad y no una declaración de intenciones.

07Protección de datos y seguridad

Alojamiento dentro de la UE —Amazon Web Services, Irlanda— en infraestructura certificada ISO/IEC 27001.
Control de acceso basado en roles a sistemas, aplicaciones e información, con complejidad de contraseñas obligatoria y credenciales nunca almacenadas en formato legible.
Bloqueo de la cuenta tras intentos repetidos de inicio de sesión fallidos, para evitar ataques de fuerza bruta.
Aceptación expresa de las condiciones y de la política de privacidad en el registro, tanto en la app como en el panel.
Una política de privacidad editable por proyecto, para que la autoridad pueda emitir una versión acorde con la normativa local de protección de datos.
Ninguna transferencia internacional de datos sin la autorización previa del responsable del tratamiento.

08Integraciones

Una API REST abierta y documentada, con autenticación de terceros mediante tokens JWT estándar (RFC 7519) emitidos por un endpoint específico tras un intercambio seguro de credenciales.
Un sistema de webhooks, para que los sistemas de terceros reciban un aviso cuando se produzcan eventos en la plataforma —por ejemplo, la llegada de un vehículo a un punto de recogida— en lugar de consultar la API continuamente.
Una API MaaS que permita a la aplicación propia de la autoridad mostrar la disponibilidad y gestionar toda la transacción de reserva, igual que la app de pasajeros del proveedor, como parte de un trayecto multimodal más amplio.
Pago mediante una pasarela elegida por el operador o la autoridad y configurable por zona de servicio, actuando el proveedor estrictamente como puente y sin custodiar nunca fondos de los pasajeros.
Exposición de los datos necesarios para integrar un sistema de billetaje —usuarios, tarifas y precios, zonas, paradas y áreas—, con la integración con un sistema existente de cobro o validación definida una vez identificado dicho sistema.
Incidencias planificadas integradas en la cartografía y el cálculo de rutas, para que las calles afectadas se tengan en cuenta al calcular los recorridos.
Datos operativos e históricos a nivel de viaje —origen, destino, hora de solicitud, canal de solicitud, estado del pago, retrasos, tiempos de espera y a bordo— disponibles bajo petición, como informes programados y en el panel.
Exportación al almacén de datos o a las herramientas de BI del operador a través de la API o, como alternativa, mediante envío programado por FTP.

Pide esto, no aquello

Dónde las licitaciones de DRT restringen la competencia sin querer

Seis patrones que vemos una y otra vez. Cada uno ata a la autoridad a un único proveedor o descarta el modelo de servicio que realmente quería.

En lugar de«El sistema utilizará el algoritmo X para la asignación de vehículos».ExigeObjetivos de resultado: tiempo máximo de espera, desvío máximo, cobertura mínima de la zona de servicio.Nombrar un método descarta otros mejores y no es verificable en la evaluación. Los objetivos se pueden medir en la operación y exigir en el contrato.
En lugar de«Los licitadores suministrarán tabletas y soportes embarcados».ExigeCompatibilidad con dispositivos Android e iOS estándar, con el suministro de hardware como opción con precio aparte.Incluir el hardware encarece la oferta y ata la flota al ciclo de renovación de un único proveedor. Pídelo por separado si lo quieres.
En lugar de«El servicio operará entre paradas definidas».ExigeSoporte para operación con paradas, con paradas virtuales y puerta a puerta, configurable por zona.Una cláusula de solo paradas excluye discretamente el modelo puerta a puerta que los servicios accesibles y rurales suelen necesitar más adelante.
En lugar de«El proveedor facilitará informes bajo petición».ExigePropiedad de los datos a nivel de viaje por parte de la autoridad, con exportación programada por API o FTP, y el histórico completo a la salida.Un informe es una captura de pantalla; los datos son un activo. Sin una cláusula de exportación, la autoridad no puede evaluar la siguiente licitación.
En lugar de«El sistema se integrará con nuestro sistema de billetaje».ExigeUna API documentada que exponga usuarios, tarifas, zonas y paradas, más un alcance de integración concreto acordado tras la adjudicación.La integración sin definir es donde desaparecen los presupuestos. Exige que la interfaz exista; define la conexión concreta por separado.
En lugar de«La app de pasajeros será accesible».ExigeConformidad con WCAG 2.1 AA, soporte nativo de lector de pantalla e indicador de accesibilidad en el momento de reservar.«Accesible» no se puede comprobar. Estos tres requisitos sí, y un proveedor los cumple o no los cumple.

Modelos de servicio

Nombra la flexibilidad que quieres, no el vehículo que imaginas

El transporte a demanda es una escalera, no un único producto. La mayoría de las licitaciones nombran un peldaño y se quedan atascadas en él. Especifica el peldaño que necesitas en cada zona y exige que pasar de uno a otro sea un cambio de configuración, no un proyecto nuevo.

Menos flexibleRuta fijaEl vehículo sigue un recorrido predefinido, como una línea convencional.Cuando hay que mantener una línea pública reconocible.
Peldaño dosRuta flexibleSe mantiene un corredor general, con desvíos permitidos para recoger o dejar pasajeros cerca.Previsible, pero llega más allá de la línea.
Peldaño tresLanzadera de conexiónEl servicio conecta con una estación, una terminal o un intercambiador en lugar de con un destino.Primera y última milla hacia la red troncal.
Peldaño cuatroEsquina a esquinaParadas virtuales o puntos de encuentro cerca del origen y del destino, asignados por el sistema.Equilibra comodidad y eficiencia en la agrupación de viajes.
Más flexiblePuerta a puertaRecogida y bajada en direcciones concretas dentro de la zona autorizada.Pueblos, baja densidad, movilidad reducida.

Distintos peldaños pueden funcionar en el mismo despliegue, uno por zona: paradas virtuales en el centro denso, puerta a puerta en los pueblos, un corredor flexible a lo largo de la ruta troncal. Pide a los licitadores que demuestren cómo pasan una zona de un modelo a otro desde el panel de control, con el histórico del periodo anterior intacto y consultable por separado. Es la forma más rápida de distinguir una plataforma configurable de un desarrollo a medida.

Parámetros y umbrales

Las cifras que debe fijar una licitación de DRT

Son los valores que deciden si un servicio parece fiable o arbitrario. Si no se fijan, cada licitador supone los suyos y las ofertas dejan de ser comparables. Los valores de ejemplo son los que vemos funcionar en la práctica, no una recomendación para tu territorio.

Tiempo máximo de espera: 15 min; Cuánto puede esperar un pasajero entre la solicitud y la recogida. Es el factor que más pesa en la fiabilidad percibida.
Desvío máximo: +30 %; Cuánto puede alargarse un trayecto para agrupar a otro pasajero. Marca el equilibrio entre eficiencia y paciencia.
Capacidad del vehículo: 8 plazas; Plazas disponibles por vehículo, y cuántas de ellas son para sillas de ruedas.
Prioridad de accesibilidad: Prioritaria; Si las reservas con silla de ruedas se atienden con prioridad y con qué nivel de servicio.
Tiempo mínimo de transbordo: 5 min; El margen que se mantiene al alimentar un tren o un autobús, para no perder una conexión con retraso.
Tiempo de recálculo: < 5 s; Con qué rapidez debe reoptimizar el sistema tras un cambio de parámetro o una nueva solicitud durante una demostración en directo.
Recuperación ante incidencias: < 60 s; Con qué rapidez deben reasignarse los pasajeros cuando un vehículo se avería en mitad del turno.
Horario de servicio: 06:00–22:00; Horas de servicio por zona, por día de la semana y por tipo de solicitud, más las excepciones por festivos.

Quién responde de cada requisito

Una misma licitación suele abarcar a la vez horarios, billetaje y operación a demanda. Los requisitos recaen en sistemas distintos, y un licitador que responde por todos ellos o es una UTE o exagera. Indica qué corresponde a cada uno.

La plataforma a demanda: Zonas de servicio y paradas virtuales, parámetros operativos, asignación de vehículos y agrupación de viajes, guiado del conductor, supervisión en directo, KPI del servicio a demanda, app de pasajeros y notificaciones.
El sistema de planificación y horarios: Numeración y denominación de líneas, estado y aprobación de horarios, edición de tiempos de recorrido, bloques de servicio, comparación de horas de salida entre líneas, atributos oficiales de las paradas.
La propia autoridad: Los datos de costes para el análisis del coste por pasajero, el nivel de servicio exigido, la política tarifaria y el proveedor de pagos, la política de privacidad que se comunica a los pasajeros y qué KPI son contractuales.

Descarga la lista de verificación con el reparto ya hecho →

Interoperabilidad y propiedad de los datos

Las cláusulas que deciden si puedes marcharte

Una plataforma de DRT se sitúa entre tu billetaje, tu planificador de viajes, tu atención al cliente y tus informes. Si la licitación no define esas juntas, las define el adjudicatario, y la autoridad descubre el coste de salida años después.

Estos son los compromisos que asumimos, redactados como requisitos que puedes exigir a cualquier licitador.

API abierta y documentada: Documentación técnica pública, que puede compartirse con el equipo de integración de la autoridad antes de la adjudicación y no después.
Webhooks en lugar de consultas continuas: Los sistemas de terceros reciben un aviso cuando se producen eventos, así que las pantallas de información al pasajero y el CRM se mantienen al día sin saturar la API.
La app propia de la autoridad lo puede hacer todo: Una API MaaS específica permite que una aplicación de terceros muestre la disponibilidad y gestione toda la transacción de reserva, incluido el pago cuando se encarga ella misma de cobrar.
Los pagos se quedan con el proveedor del operador: El operador o la autoridad elige el proveedor de pagos, configurable por zona de servicio. Shotl actúa como puente y nunca cobra ni custodia fondos de los pasajeros.
Los datos pertenecen a la autoridad y al operador: Como titulares de los datos, pueden solicitar datos operativos e históricos en cualquier momento o recibir informes programados —normalmente semanales— para su consumo automático.
La salida es una cláusula, no una negociación: El histórico a nivel de viaje se exporta mediante la API o por FTP programado al almacén de datos o a las herramientas de BI del propio operador.
Las incidencias entran en el cálculo de rutas, no en una llamada: Las obras y los cortes planificados se integran en la cartografía para que las rutas los tengan en cuenta antes de que un conductor se los encuentre.

Para tu delegado de protección de datos

Qué cubre el anexo de privacidad

La infraestructura está alojada en Amazon Web Services en Irlanda, dentro de la UE, en infraestructura certificada ISO/IEC 27001. Control de acceso basado en roles, complejidad de contraseñas obligatoria, credenciales nunca almacenadas en formato legible y bloqueo de la cuenta tras varios inicios de sesión fallidos.

La propia política se adapta en cada proyecto, para que la autoridad y el operador puedan emitir una versión acorde con la normativa local. No se realiza ninguna transferencia internacional sin la autorización previa del responsable del tratamiento.

Las políticas corporativas que hay detrás del producto —medioambiental, código ético, antisoborno, código de conducta— se recogen en sostenibilidad y ética y están disponibles como documentos firmados.

Recogido en la política por defecto

Identificación del responsable y del encargado del tratamiento
Categorías de datos recogidos —identificadores, ubicación, historial de reservas, preferencias de uso— y si cada una es obligatoria u opcional
Las finalidades del tratamiento y la base jurídica de cada una
Las condiciones en las que los datos pueden compartirse con autoridades públicas u otros proveedores que participan en el servicio
Plazos de conservación
Derechos de los usuarios: acceso, rectificación, supresión, limitación, portabilidad y retirada del consentimiento
La posición respecto a las transferencias internacionales, que requieren la autorización previa del responsable

Límites actuales

Lo que la plataforma no hace hoy

Lo decimos aquí en lugar de que lo descubras durante la evaluación. Si alguno de estos puntos es decisivo para tu servicio, indícalo en la licitación y te responderemos directamente.

En la hoja de rutaSin mensajes de texto libre del conductor al centro de controlLas desviaciones de ruta se registran y se reoptimizan automáticamente, pero el conductor aún no puede enviar una nota escrita o una descripción de incidencia al panel. Hoy esa conversación se hace por teléfono o radio. Si es decisivo para tu operación, dínoslo y se puede priorizar para el proyecto.
Por diseñoLas reservas no se editan directamenteCambiar una hora de recogida o un destino implica cancelar y volver a crear el viaje desde el panel. Es deliberado: así cada trayecto modificado se reevalúa con las condiciones operativas del momento en lugar de heredar un plan obsoleto.