Should Transport Authorities trust AI to talk to passengers?
AI can help passengers find information, but an Authority remains responsible when an answer is wrong.
People search for
In this article
A passenger asking an app whether their ticket is valid, whether a bus is still running or how to claim a refund wants an answer, not a demonstration of new technology. If the answer is wrong, it is unlikely to matter whether it came from an Operator, an Authority website or a chatbot supplied by a Vendor.
Air Canada provides a cautionary example from outside the sector. In 2024, the British Columbia Civil Resolution Tribunal found that Air Canada had negligently misrepresented its bereavement-fare process through a chatbot on its website. The chatbot said that a passenger could apply for the fare retrospectively, while the linked policy page said the opposite. The Tribunal's decision is not a statement of UK law, but the practical point applies: an organisation cannot expect a customer to work out which of its digital channels is telling the truth.
In this context, an AI chatbot will often be a large language model (LLM). The term can hide a basic limitation. An LLM produces a plausible response from the information and instructions available to it. It does not independently establish whether a temporary fare rule, diversion or service cancellation is correct.
Start with the passenger task
The hard questions are often ordinary. Can a young person use this ticket on the connecting service? Does a day ticket still cover the replacement bus? Which stop should a passenger use after a road closure? A helpful answer requires more than a timetable. It may also require a current fare policy, ticket acceptance between Operators, a temporary instruction from the Control Room or the exact service the passenger is using.
Tests of language models against public-transport data suggest that they can handle some straightforward look-ups, while questions spanning several datasets remain harder. This warrants caution, not rejection. A live network brings complications that a small test dataset does not capture, including late changes, incomplete vehicle information and local exceptions agreed between different Operators.
An Authority should start with a narrow use case instead of launching an assistant expected to answer every question. It could help passengers find a published accessibility policy or explain how to submit lost-property details. When it cannot find an approved answer, it should pass a fare query, a compensation question or an unconfirmed disruption report to the right team. It should tell passengers when information is being checked rather than make a confident guess that sends someone to the wrong stop.
Treat the information as a controlled service
Before asking a Supplier to build a chatbot, identify the source for each answer that matters. For fare and ticketing questions, this means a named policy owner, a current version, an agreed publication route and a process for temporary changes. For disruption information, distinguish between a scheduled service, a live vehicle position and an approved passenger message. They are separate information types that change at different speeds.
A new digital channel can expose data issues that were previously separate. A concessionary-ticket rule may be correct in the policy document but absent from the app. An Operator may have a diversion recorded in its operational system before an Authority channel has been updated. A chatbot can make such gaps more visible, but it does not resolve them.
The contract and acceptance process should cover these issues. Ask the Supplier to show the answers produced for real passenger scenarios, including stale data, a service that crosses Operator boundaries and a question for which no approved answer exists. Keep a record of the source used, the answer given and the point at which a case was handed to a person. The Authority also needs a process to correct a misleading answer quickly and decide whether similar passengers should be contacted.
OneContact can capture, route, track and resolve passenger enquiries, feedback, complaints, compliments and lost-property cases across a network. It provides a route for issues a digital assistant cannot resolve, provided the Authority has agreed who owns the case and what information the receiving team can see. It does not remove the need to maintain the underlying fare, service and disruption information.
Test a chatbot by whether a passenger can obtain a reliable answer to a defined task and whether the Authority can see what happened when they could not.
Useful questions
Use these questions to set the scope, specification and acceptance evidence for an AI passenger-information service.
- Which passenger questions will the service answer automatically, and which must be passed to an Authority or Operator team?
- For each high-risk answer, who owns the source information, who checks that it is current and who authorises an urgent change?
- Has the proposed service been tested with current fare rules, cross-Operator journeys, diversions and deliberately incomplete information?
- What record will the Authority receive of each reply, its source and any handover, and how will it correct an incorrect answer?
- Does the contract set out response times and responsibility if an answer causes a passenger to miss a service, buy the wrong ticket or make a complaint?
More on Customer Service & Contact
