Writing a passenger information system (PIS) tender is harder than it looks, mostly because it's easy to specify what the system should display without specifying what it needs underneath to make that display trustworthy. A screen that shows the wrong arrival time is worse than no screen at all.
Start with the data source, not the display
The most common gap in a PIS tender is jumping straight to displays, at-stop screens, on-board displays, a mobile app, without specifying the real-time data feed that powers them. A passenger information system is only as reliable as the vehicle location and schedule deviation data feeding it. The tender should require the vendor to state clearly whether real-time predictions come from actual vehicle tracking (AVM/GPS) or are inferred from static schedules, since the two produce very different passenger experiences.
Require open, standard data formats
Specifying GTFS-RT (or SIRI, depending on the region) as a mandatory output format, not an optional add-on, protects the AOM's ability to publish predictions to Google Maps, Citymapper and other third-party apps without depending on a single vendor's proprietary feed. This single requirement line does more for long-term flexibility than most feature specifications combined.
Cover every channel the passenger actually uses
A complete PIS tender should specify requirements across each channel separately, since they have different technical constraints:
- At-stop and in-station displays: refresh frequency, display legibility standards, power and connectivity requirements (mobile network vs Wi-Fi vs wired), and behavior during a connectivity outage.
- On-board displays: integration with the vehicle's existing onboard equipment or need for new hardware, multilingual support if relevant.
- Mobile app or website widget: whether the vendor provides one, or whether the AOM only needs the underlying feed to plug into its own app.
- Third-party app coverage: explicit confirmation that the feed format is compatible with major routing apps without additional licensing per app.
Specify accessibility and reliability requirements explicitly
Accessibility standards (audio announcements, screen reader compatibility, visual contrast) are often assumed rather than specified, which means they get deprioritized under budget or timeline pressure unless the tender makes them a hard requirement rather than a nice-to-have. The same applies to uptime and SLA commitments: a tender should require a stated uptime percentage and a defined process for outage notification, not just a general statement of reliability.
Address data ownership and portability
Since a PIS depends on a continuous data feed, the tender should clarify who owns the historical data generated (arrival accuracy records, usage statistics) and what happens to that data and its format if the AOM changes vendor in the future. This clause rarely gets attention during procurement and becomes a real problem years later.
A practical checklist before publishing the tender
- Does the tender specify the real-time data source powering predictions, not just the display hardware?
- Is GTFS-RT (or SIRI) publication a mandatory requirement, not optional?
- Are accessibility and uptime requirements stated as measurable criteria, not general commitments?
- Is data ownership and portability addressed for a future vendor change?
Related reading: how passenger information systems connect to an operations supervision solution, why GTFS Realtime is essential for public transport, and GTFS-RT in practice, from GPS to the passenger's screen.
Drafting a PIS tender and want feedback on your technical requirements before publishing it? Pysae's team can help make sure the data layer underneath is specified correctly.