Are we benchmarking bus digital experience against the wrong thing?
Being ahead of a neighbouring Authority offers useful context. It is a poor test of whether a passenger can complete a journey without avoidable effort.
People search for
In this article
When an Authority asks how its digital passenger experience compares, the answer is often that it is ahead of a neighbouring Authority or most of the sector on open data. Both may be true. Neither says much about the journey a passenger is trying to make.
A local comparison can show what is realistic within a similar funding settlement, contract model or market. It becomes a problem when it is the only comparison. Several Authorities may be dealing with fragmented fare products, incomplete real-time feeds and separately commissioned customer channels. Being marginally ahead of that group can still leave passengers doing unnecessary work.
Start with the passenger task
A passenger task is usually the most useful unit of comparison. Can someone find the right stop, judge whether a late-running bus is still worth waiting for, buy the appropriate fare or resolve a payment problem without being passed between an Authority, an Operator and a ticketing Supplier?
Before identifying a gap against “best practice”, an Authority should measure its own service. Select a small number of high-volume or high-consequence tasks and establish what happens now. Compare predicted arrivals with actual arrivals. Record when a ticket purchase requires an account, a fare rule or contact with customer support. Distinguish a contact answered first time from one that is transferred or reopened.
Those measures are not interchangeable and should not be collapsed into a single digital-experience score. A service can have an attractive journey planner and still make a simple refund disproportionately difficult. The baseline exposes that distinction and lets the Authority judge a proposed change.
Compare the operating choice, not the country
International examples help when they reveal an operating choice that might apply locally. The choice must be visible in a live public-facing service and tested against local fares, data quality, contract terms and non-digital access.
| Operating choice | Published example | The lesson to test locally |
|---|---|---|
| Daily fare capping for eligible short-term tickets | Prague's PID Lítačka app | The app calculates a daily cap as eligible tickets are activated, so the passenger does not have to decide at the first trip whether a day ticket will prove cheaper. An Authority must establish whether its fare rules and ticketing estate can recognise qualifying journeys consistently. |
| A contract payment linked to reliability | Transport for London's Quality Incentive Contracts | A contract can make reliability a commercial matter alongside operational reporting. The difficult work is agreeing the measure, what is outside an Operator's control and how disputes over the underlying data are handled. |
| Digital delay certificates by route and time period | JR East | A passenger can obtain a standardised record of a delay. The certificate describes the maximum delay for the route and period rather than proving an individual journey. That limitation is part of the service design, not a footnote to ignore. |
Identify the decision behind each visible feature. Prague's arrangement leaves the system to calculate the value of repeated travel. Transport for London's arrangement decides which performance merits payment. JR East gives passengers a clear, bounded record of disruption.
This moves the discussion beyond the question of which region has the best app. It focuses on fare policy, data ownership, payment rules, customer-service hand-offs and the decisions an Authority can influence.
Keep the comparison direct
Do not set targets against benchmarks until the local evidence is sound. If predicted bus times are available only for some Operators or routes, a headline accuracy figure may conceal the gaps a passenger notices. If an Operator resolves a ticketing query after the Authority's contact centre has passed it on, a first-contact measure must expose that hand-off. Authorities should adopt a first-time fix policy and consider the passenger experience of multiple hand-offs.
Apply the same care when comparing services with banking, retail or food-delivery apps. These apps shape passengers' expectations of immediate confirmation, clear payment records and useful notifications. Public transport has different constraints: a missed connection, a regulated concessionary fare or a vehicle without connectivity cannot be designed away. The question is whether those constraints explain the friction or have become familiar to the organisations involved.
A focused benchmark can show whether a proven mechanism has the local prerequisites it needs. Choose one passenger task and establish the evidence. The change may concern an information feed or contract schedule rather than a major platform procurement.
Useful questions
Before commissioning a comparison or responding to a Supplier's benchmark, an Authority needs answers to the following questions:
- Which passenger task are we benchmarking and what local evidence tells us that it matters?
- Can we show the present performance, including the routes, fare products or customer channels that the measure excludes?
- What specific policy, data, contract or technical decision made the external example work?
- Which party would own the data, cost and passenger communication if we adopted the mechanism locally?
- Would the proposed change still help a passenger who cannot or prefers not to use a smartphone?
More on Digital Passenger Experience
