Cómo incluir un software de transporte a demanda en una licitación pública

El transporte a demanda (DRT) tiene un peso cada vez mayor en las estrategias de transporte público. Ciudades, autoridades de transporte y gobiernos regionales recurren al DRT para mejorar la cobertura, conectar zonas de baja densidad, facilitar los desplazamientos de primera y última milla y ofrecer servicios de movilidad más flexibles allí donde las líneas fijas no siempre son eficientes.

Sin embargo, contratar un servicio DRT no es lo mismo que contratar una línea de autobús tradicional. Una licitación DRT bien planteada debe definir no solo los vehículos y la operación, sino también la plataforma de software, los canales de reserva, la lógica de rutas, la propiedad de los datos, los requisitos de reporting y la integración con el resto de la red de transporte público.

Este artículo explica los principales elementos que las autoridades públicas deberían tener en cuenta al preparar una licitación DRT o al incluir un software de transporte a demanda dentro de un contrato de movilidad más amplio.

Empezar por definir el problema de transporte público

Antes de especificar la tecnología, la autoridad debe definir qué se espera que resuelva el servicio DRT. El transporte a demanda puede responder a necesidades de movilidad muy distintas, y cada caso de uso puede requerir reglas operativas, funcionalidades de software e indicadores de rendimiento diferentes.

Entre los casos de uso habituales del DRT se encuentran:

• Conectar zonas rurales o de baja densidad con estaciones de tren, intercambiadores de autobús o centros urbanos
• Ofrecer transporte por la tarde, por la noche o en horas valle cuando las líneas fijas no son viables
• Sustituir o complementar líneas de autobús con poca demanda
• Mejorar el acceso de primera y última milla a la red de transporte público
• Dar servicio de transporte adaptado, movilidad accesible o transporte para colectivos específicos
• Gestionar servicios de transporte escolar, de empresa o comunitario

Un servicio rural de aproximación, por ejemplo, puede necesitar una integración sólida con los horarios de tren y puntos de recogida flexibles. Un servicio de transporte adaptado puede requerir reglas de elegibilidad, reserva asistida, vehículos accesibles para sillas de ruedas y procesos específicos de atención al cliente. Estas diferencias deben reflejarse en la licitación desde el principio.

Elegir el modelo de licitación DRT adecuado

No existe un único modelo de contratación para el transporte a demanda. La estructura adecuada depende de la capacidad interna de la autoridad, de los contratos vigentes con operadores, del contexto normativo y de la estrategia de movilidad a largo plazo.

Las autoridades públicas suelen elegir entre cuatro modelos principales de licitación:

• Licitación solo de software: la autoridad contrata la plataforma DRT y asigna la operación a los operadores de transporte existentes.
• Licitación solo de operación: la autoridad ya dispone de la tecnología o exige al operador que trabaje con una plataforma concreta.
• Licitación integrada de software y operación: el mismo adjudicatario aporta la tecnología, los vehículos, los conductores y la gestión del servicio.
• DRT dentro de una licitación multimodal: el servicio se incluye como lote o subservicio dentro de un contrato de transporte público más amplio.

Una licitación solo de software puede dar a la autoridad un mayor control sobre los datos, el diseño del servicio y su escalabilidad futura. Una licitación integrada puede reducir la complejidad de coordinación, sobre todo en organismos con recursos operativos internos limitados. En cualquier caso, la licitación debe definir con claridad las responsabilidades de la autoridad, el proveedor de software, el operador y el equipo de atención al cliente.

Definir los requisitos básicos del software DRT

La plataforma de software es clave para el éxito de un servicio de transporte a demanda. Por eso, la licitación debe incluir requisitos técnicos claros, pero permitiendo a los licitadores proponer la forma más eficaz de alcanzar los resultados del servicio.

Los requisitos habituales de un software DRT incluyen:

• App para pasajeros en iOS y Android
• Portal web de reservas
• App para conductores con guiado de ruta, información de pasajeros y actualizaciones de los viajes
• Panel de back office para despacho, monitorización y gestión del servicio
• Cálculo dinámico de rutas y viajes compartidos (ride-pooling)
• Seguimiento de vehículos en tiempo real y horas estimadas de llegada
• Reglas de reserva por zona, franja horaria, tipo de usuario o categoría de servicio
• Compatibilidad con paradas fijas, paradas virtuales y modelos puerta a puerta o esquina a esquina
• Notificaciones automáticas por app, SMS o correo electrónico
• Interfaz multilingüe y funciones de accesibilidad
• Panel de reporting y herramientas de exportación de datos

La licitación también debe explicar cómo tiene que integrarse la plataforma DRT con los sistemas de transporte público existentes. Esto puede incluir API, plataformas MaaS, planificadores de viaje, sistemas de venta de billetes, proveedores de pago o feeds GTFS-RT. Sin estos requisitos, el servicio DRT puede acabar funcionando como un sistema aislado en lugar de formar parte de la red de movilidad.

Incluir opciones de reserva para todos los usuarios

El DRT se utiliza a menudo para mejorar la accesibilidad y la inclusión. Por eso, la licitación no debería dar por hecho que todos los pasajeros reservarán a través de una app en el móvil.

Las autoridades deberían valorar si el servicio tiene que admitir:

• Reserva por app
• Reserva web
• Reserva telefónica a través de un call center
• Reserva asistida por personal público, cuidadores o coordinadores de movilidad
• Reservas recurrentes para usuarios habituales
• Flujos de reserva específicos para usuarios de silla de ruedas o personas con movilidad reducida

Esto es especialmente importante en el transporte rural, la movilidad de personas mayores, el transporte sanitario y los servicios de transporte adaptado. Una buena licitación DRT debe definir no solo la experiencia digital, sino también cómo accederán al servicio los usuarios no digitales.

Fijar indicadores de rendimiento claros

Los servicios de transporte a demanda deben medirse con KPI claros, realistas y específicos del servicio. Estos indicadores ayudan a la autoridad a supervisar el rendimiento, comparar resultados y ajustar el servicio con el tiempo.

Los KPI habituales del DRT incluyen:

• Tiempo medio de espera
• Tasa de éxito de las reservas
• Viajes de pasajeros por hora-vehículo
• Ocupación por vehículo
• Puntualidad en recogidas y llegadas
• Tiempo medio de desvío
• Tasa de no presentados (no-show)
• Coste por viaje de pasajero
• Índice de satisfacción del cliente
• Distribución de reservas entre app, web y teléfono

La licitación debe especificar con qué frecuencia deben entregarse los informes, qué datos tienen que estar disponibles en tiempo real y si la autoridad necesita acceso a los datos operativos en bruto. También es importante definir qué KPI son obligatorios desde el lanzamiento y cuáles deben servir para optimizar el servicio tras un periodo piloto inicial.

Aclarar la propiedad de los datos y el cumplimiento del RGPD

Los datos son uno de los elementos más importantes de cualquier contrato DRT. La autoridad debe definir claramente quién es el propietario de los datos operativos, cómo se puede acceder a ellos, durante cuánto tiempo se conservan y cómo pueden utilizarse en la planificación futura de la movilidad.

La licitación debe incluir cláusulas sobre:

• Cumplimiento del RGPD y protección de los datos de los pasajeros
• Propiedad de los datos de viajes, vehículos, pasajeros y rendimiento
• Acceso a datos agregados y anonimizados
• Formatos de exportación de datos y frecuencia de los informes
• Requisitos de ciberseguridad
• Portabilidad de los datos al finalizar el contrato

Esto es especialmente importante cuando el DRT forma parte de una estrategia de transporte público a largo plazo. Si el acceso a los datos no está bien definido, a la autoridad puede resultarle difícil evaluar el servicio, comparar proveedores o rediseñar la red en el futuro.

No especificar en exceso el algoritmo

Un error habitual en las licitaciones DRT es intentar definir hasta el último detalle del algoritmo de rutas. Las autoridades públicas deben especificar los resultados esperados, las reglas del servicio y los estándares de rendimiento, pero sin limitar la innovación prescribiendo exactamente cómo debe funcionar la tecnología.

Por ejemplo, la licitación puede definir tiempos máximos de espera, límites de desvío aceptados, zonas de servicio, ventanas de reserva, reglas de accesibilidad y requisitos de reporting. El licitador debe explicar entonces cómo cumplirá su software DRT esos requisitos mediante su lógica de rutas, despacho y agrupación de viajes.

Este enfoque permite a la autoridad mantener el control sobre los objetivos del servicio público y, al mismo tiempo, dar a los proveedores de tecnología la flexibilidad suficiente para proponer soluciones eficientes.

Definir el plan de implantación y soporte

Una licitación DRT no debe evaluar solo el software. También debe valorar cómo se implantará, lanzará, apoyará y mejorará el servicio tras su puesta en marcha.

Las autoridades deberían pedir a los licitadores que expliquen:

• El calendario de implantación
• La configuración de zonas, paradas, horarios y reglas de reserva
• La formación de conductores, despachadores y equipos de atención al cliente
• La comunicación con los pasajeros y el apoyo al lanzamiento
• La disponibilidad del soporte técnico
• La monitorización del servicio durante las primeras semanas de operación
• El proceso para introducir cambios después del lanzamiento

Esto es especialmente relevante en pilotos o en primeros despliegues de DRT. Incluso la mejor plataforma necesita una configuración adecuada, coordinación operativa y adopción por parte de los usuarios para dar buenos resultados.

Errores habituales que conviene evitar en una licitación DRT

Al preparar una licitación de transporte a demanda, las autoridades públicas deberían evitar varios errores frecuentes:

• Contratar software sin definir el modelo de servicio
• Centrarse solo en la app de pasajeros y olvidar el despacho, el reporting y la operación
• Olvidar la reserva telefónica o asistida para usuarios no digitales
• No definir la propiedad de los datos ni los requisitos de exportación
• Fijar desde el primer día objetivos poco realistas de tiempo de espera u ocupación
• No especificar los requisitos de accesibilidad
• No exigir la integración con los sistemas de transporte público o los planificadores de viaje
• Utilizar los mismos KPI para casos de uso DRT muy distintos
• Dejar poco claras las responsabilidades de atención al cliente
• Redactar especificaciones técnicas que limitan la innovación en lugar de definir resultados

Una licitación bien diseñada debe equilibrar claridad y flexibilidad. Debe explicar a los licitadores qué quiere conseguir la autoridad pública, qué requisitos mínimos deben cumplirse y cómo se medirá el éxito.

Cómo evaluar a los proveedores de software DRT

El proceso de evaluación debe ir más allá del precio. El transporte a demanda es un servicio operativo apoyado en software, por lo que el proveedor seleccionado debe poder demostrar capacidad técnica, experiencia en implantación y fiabilidad a largo plazo.

Algunos criterios de evaluación útiles son:

• Experiencia en servicios DRT comparables
• Calidad de las herramientas para pasajeros, conductores y back office
• Capacidades de cálculo dinámico de rutas y agrupación de viajes
• Capacidad de integración con los sistemas de movilidad existentes
• Funciones de accesibilidad e inclusión
• Capacidades de reporting y analítica
• Condiciones de propiedad y portabilidad de los datos
• Metodología de implantación
• Modelo de formación y soporte
• Escalabilidad para futuras zonas, usuarios o tipos de servicio

Así se garantiza que la autoridad no seleccione solo a un proveedor de software, sino a un socio capaz de sostener un servicio de transporte público fiable y adaptable.

Conclusión

Integrar el DRT en una licitación pública exige algo más que añadir un componente de movilidad a demanda a un contrato existente. Las autoridades necesitan definir los objetivos del servicio, elegir el modelo de contratación adecuado, especificar los requisitos de software y operación, proteger sus datos y establecer indicadores de rendimiento realistas.

Bien diseñada, una licitación DRT puede ayudar a ciudades y regiones a crear servicios de transporte público más flexibles, inclusivos y eficientes. La clave está en centrarse en los resultados, evitar dependencias técnicas innecesarias y asegurarse de que el software de transporte a demanda seleccionado pueda sostener tanto el lanzamiento como la evolución del servicio a largo plazo.

¿Estás preparando una licitación DRT? Habla con Shotl para definir los requisitos de software, operación y datos de tu servicio de transporte a demanda.