What happens to the ticketing app once nobody needs to buy a ticket?
When contactless payment and fare capping remove much of the need to buy before travelling, an Authority’s app still has work to do: it should help passengers use the network, understand their travel and resolve problems.
People search for
In this article
Authorities should examine how many tickets are bought without an app and decide what the app is for. Once passengers can tap the same contactless card or mobile device, travel and receive the correct daily or weekly cap, buying a ticket is no longer the app’s main purpose. The app’s role then changes.
The app should help passengers understand the network, check what happened on a journey and get help when a payment or journey does not go as expected. Specifications can overlook these tasks when they still treat the app chiefly as a digital ticket machine.
The account still needs looking after
Account-based ticketing is useful because the fare calculation and travel record sit in the back office rather than on a ticket held by the passenger. The card or phone is the identifier, not the ticket itself.
That changes the app design brief for an Authority. The account view should show the journeys and charges a passenger is entitled to see. It should explain the status of a cap in terms the passenger can act on and direct them to the right support route when something looks wrong. A cap is a fare rule, so the app must reflect the actual rules on eligible travel, payment media and the relevant day or week. A vague progress bar can create more calls than it prevents.
The other part of the job is helping passengers make journeys. A passenger should be able to find a stop, see departure and disruption information, and plan across the Operators that serve the Authority’s network. An Authority-branded app that covers only part of the network forces passengers to use a different app to see the next bus. Where real-time information is supplied, the Authority should be clear about which data feeds the app uses, how delays or cancellations are represented and who investigates persistent errors.
Put the passenger tasks into the specification
An Authority can provide these functions without commissioning a bespoke ‘super-app’. It must specify the passenger tasks that matter and set out how they work in wireframes. This should form part of the technical specification for the procured development agency. During procurement, the Authority can ask Managed Ticketing Suppliers to demonstrate a journey search, a live departure, a capped day of travel and the route a passenger takes when a card payment needs investigation. The tender technical evaluation should assess these demonstrations.
For a public-facing Authority app, accessibility must be treated as a delivery requirement. Government guidance says public-sector websites and mobile apps should meet WCAG 2.2 AA and publish an accessibility statement, subject to the limited legal qualifications that apply. These requirements should appear in the tender, acceptance tests and release process, not only in a design assurance document.
Usage data needs a practical purpose. The Authority should agree which aggregate information it needs: failed journey searches, unavailable departures, payment-help demand, app versions, and the volume and causes of reported defects. The service specification should define the data fields, frequency, quality checks and treatment of personal data. A Supplier dashboard may help, but it does not replace the information the Authority needs to manage the passenger offer.
This article does not cover customer services or account preferences. OneContact addresses those functions by connecting the Transport App and website to a secure, customer-centric CRM. It captures, routes, tracks and resolves passenger interactions through a defined workflow. This gives Authorities and Operators clearer oversight of service quality and fulfilment, and helps them handle customer contacts consistently.
We also offer a design and specification service for a branded app. The service covers UX design, the technical specification, and support with procurement and the contract. It forms one part of the overall ticketing solution and technical specification for Managed Ticketing Supplier service requirements.
Useful questions
These questions help distinguish a passenger app requirement from a feature list.
- Who owns the ticketing and customer functions, and how will they create a unified proposition?
- Once a passenger does not need to buy a ticket before travelling, what useful task will bring them back to the app?
- Can the Managed Ticketing Supplier demonstrate the journey history and cap information using the Authority’s actual fare rules and payment media, including the suggested wording used when the final charge is still being calculated?
- Does the app show live departures and disruption information across every contracted Operator, and who is responsible for correcting inaccurate data?
- What accessibility evidence will the Authority require at launch and after a significant release, beyond a Supplier declaration?
- Which app, account and service-performance data will the Authority receive, in what form and who will review it?
More on Ticketing & Payment Technology
Ticketing & Payment TechnologyArticleHow does the ticketing service join up the passenger app and the payment reporting?Ticketing & Payment TechnologyArticleWhat do ITSO, open-loop and concessionary ticketing and other terms mean?
Franchising & Procurement StrategyArticleHow does an Optimised Enhanced Partnership join up the customer experience?